As you probably all know by now, I have joined ISIS Papyrus a while ago and last week i was reading the Papyrus Objects Developer Guide again and suddenly lightning hit me and the question raised can this actually be done in Java and if so, how [...]]]> I challenge the Java Hackers, read on….

As you probably all know by now, I have joined ISIS Papyrus a while ago and last week i was reading the Papyrus Objects Developer Guide again and suddenly lightning hit me and the question raised can this actually be done in Java and if so, how and how easy?

Be aware, reading further could put you in a depression but on the otherhand the real Hacker will find it a challenge. Are you the Hacker?

From the ISIS Papyrus Objects manual for Developers: Classes are the definitions of objects and their behavior designed by the Developer. Classes are required to define general properties of objects derived from these classes, namely attributes, methods, states, and child/parent reference definitions. All classes reside exclusively in the Repository. The object tree in the Repository reflects the inheritance chain. As child objects of a class reflect an inheritance relationship it inherits all properties (methods, attributes, states, state transitions, and parent/child relationships).

Big deal and obvious you may think. But did you noticed the fact that we talk here also about states, state transitions and parent/child relationships.

Papyrus has full support for those concepts without any line of programming. Besides this there is full support for Security (role, policy, privilege), Version control (you can even view the versions and each instance knows to what version it belongs). But more on that maybe later.

I would like to see and explained Java Implementations that cover the UML implementation of State Machine, Parent/Child and Constraints (OCL) as this is all standard in Papyrus Objects and does not require programming at all.

Hackers, show me a simple application simulating for example a traffic light with some attributes and methods that have been constrained as well the state transition itself. You would be a super hacker if you also implement security.

Need inspiration for your Java Hack? Read some parts of our ISIS Objects Manual for Developers and start Hacking. I am waiting for your solutions and i am sure other Hackers will comment on them so that at the end the best solution will be available to be compared to Papyrus Objects. SUCCESS

Authorization Concepts

In Papyrus Objects, authorization is established through Roles, Privileges, and Policies that give Users the authorization appropriate for their tasks. This structure allows the Security Administrator to precisely control access to objects, whatever the User’s needs are.

The Role/Policy concept used in Papyrus Objects is modelled after the CORBA standard of Role Based Access Control (RBAC). Since users are not assigned permissions directly, but only acquire them through their Role (or Roles), management of individual user rights becomes a matter of simply assigning the appropriate Role(s) to the user, which simplifies common operations such as adding a user, or changing a user’s department. The Policy controls the visibility and thus complex filtering for presentation into frames is not necessary if the Policies are well set.

Access to objects (and usually also their visibility) is granted by policies, i.e. the user must be using a Role that is referenced by any of the Policies defined on the object, to access it.

Access to attributes and methods of objects is granted by Privileges, i.e. the user must be using a Role with the required privilege. In addition this Role must also be referenced by any of the Policies defined on the object.

State Machine

A state machine consists of states and their state transitions, which define the life cycle of an object. Conditions can be defined, thus certain actions can only be applied to an object if it is currently in an appropriate state (e.g. Task in state “Completed” cannot be processed). The fields of the state machine in Papyrus Objects are similar to UML (Unified Modeling Language). The “state machine view” is a frame of the Class Editor and displays the whole state machine in a flow chart. It can be used as a graphical editor similar to the UML Case tools. The state machine lists the states that an instance can have, and the Transitions between those states. Therefore it defines the object’s behavior:

• What kind of information (event) is sent to other objects.
• Which methods are available within the current state.
• Which event sent by a program triggers a state transit

The state change of an object can be:

• user driven
• driven by events
• driven by messages

A State Change has Entry, Exit, and Do Events (actions).

Child/Parent References

Via child and parent references the relationship between parent and child objects can be defined. A child reference can be used to define which type of object may be added to the object via a parent reference it is possible to defined to which type of object the object may be added.

Constraints

Constraint fields are used to define whether access to or modifications on a part of an object is granted. This way it is possible to define conditions which decide that a state transition for instance may not be executed under certain circumstances or an attribute cannot be changed in a certain state. If the expression in a constraint field evaluates to TRUE (or the field is left blank) the respective part of the object may be accessed or modified. If a constraints field evaluates to a number, then any number other than zero is true, and zero is false.

The following sections of a class / template definition contain constraint fields:

• Object start (Constraints)
• State (Send Modification Event if)
• State Transitions (Change trigger, Guard)
• Attribute (Constraints, View constraints, and Edit constraints)
• Method (Pre constraints and Post constraints)
• Child and Parent References (Constraints, View constraints, and Edit constraints)

Privileges

To define which group of users should be able to call a method or view / edit an attribute, select the related Privilege(s) in the field “Privileges” of the method or “View Privileges” or “Edit Privileges” of the attribute. ISIS provides the following predefined Privileges, which are defined in the Privileges object below the Storage folder “Storage / System Collection”:

$_Developer … Create / modify classes and templates
$_Administrator … Create / Modify templates
$_Security Administrator … Manages access rights
$_User … End user, cannot create / modify classes and templates, not all methods available.
$_Guest … End user with very limited rights for viewing.
$_Licence Administrator … Administrates product authorizations
$_System Administrator … General administration (e.g. creation of Client Nodes, import of transfer files, etc.)
$_Supervisor … System supervisor for the select of objects, which should generate an audit trail (with System Supervisor Role) or privileged end user for release tasks.

No it was not (yet) the news on ISIS Papyrus, neither was it the fact I almost won the Pullitzer price (I have first to write sensible things)

read on…

It has all to do with a catching title (like this one) and of course an interesting topic like Offshore, Productivity but [...]]]> Curious?

No it was not (yet) the news on ISIS Papyrus, neither was it the fact I almost won the Pullitzer price (I have first to write sensible things)

read on…

It has all to do with a catching title (like this one) and of course an interesting topic like Offshore, Productivity but above all Technology Stuff. Ben and Allard write nice pieces see for example “The parable of the light bulb changing” that are highly educational but there is only one champion when it comes to new stuff which is Jettro. Man what is that man productive and good in sharing his knowledge.

Give him an applaus and reward him with more than 1000 visitors on one day. Check out his articles on howto wire Java and Adobe Flex together.

I am still wondering why anyone would put some much effort in this hardcoding programming while you could do the same and more with less effort using the ISIS Papyrus Platform.

As Butler said in their upcoming Technology Audit Report “In Butler Group’s opinion, the ISIS Papyrus Platform provides a real solution to a real problem. The problem is that organisations are caught up in implementing what they view as diverse systems; when, in fact, they are part of a total ecosystem (or at least should be seen as such). Once these systems or solutions are implemented there comes a need to integrate them to provide both the real value and to reduce management costs.”

But yes I know, I was myself a die hard Java Developer and I know its fun to code, but if its the best for the organization I am not so sure anymore.

But lets start with the Analysts and their magic 8-bal that has shown them that Lean Software Development will become the hit of [...]]]> This blog item I have dedicated to zoom in on Bugs, a specific type of Waste (muda which is Toyta lexicon) aka DEFECTS as they have a huge effect on Productivity.

But lets start with the Analysts and their magic 8-bal that has shown them that Lean Software Development will become the hit of 2009.

Bloated applications, platforms and architectures slow application development and make QUALITY CONTROL and everyday usage time-consuming and nonproductive, said Forrester Research principal analyst John R. Rymer. Forrester’s newly-published report, Lean Software is Agile, Fit-to-Purpose, and Efficient, lays out how software got so fat, costly and inefficient; the evidence that IT organizations are moving to lean software; the challenges involved in lightweight software development; and strategies for joining the movement.

There is a lot to say about Lean Software Development as I already mentioned in my blog item on the REAL cost of Offshore .

The best you can do is to read the book of Mary and Tom Poppendieck and of course The Toyota Way. The XP, Scrum and even some RUP adepts under the readers they know that it is all about being Agile (whatever it means).

“Agile development is independent of any technical platform or development approach “It’s a method. What’s neat about this is that people are delivering application features sometimes every two weeks or each month. Rather than deliver the big-bang project after years of work, they’re delivering applications in increments. They’re working in an incremental fashion to deliver features over time, providing value quickly and continue to add value. That’s a way to modulate your costs, to spread your costs and investment over a period of time.”

And Yes, it`s not easy to break through old habits as I know by experience that companies are really good in adopting RUP and then transform this iterative methodology into a Waterfall approach.

What have DEFECTS to do with AGILE development and Offshore?

Partly taken from Yourdon Report on a presentation that Michael Mah(QSM) gave at the New York City SPIN group.

Assume, for the moment, that you’ve got a software development project where the end-users (or customers, stakeholders) and the developers (i.e., programmers, architects, database designers, business analysts, QA personnel, etc.) are all working in company X, local. And imagine that you have another software development project, of equivalent size and complexity, where the end-users are in company X, but the development team is located in an offshore outsourcing company on the other side of the world (e.g., China, India, Singapore, eastern Europe, etc.) Why is it that software metrics (from QSM) are showing that project #2 will have approximately 2.8 times as many software defects as project #1?

Precisely because the end-users and the developers are not “co-located” (in contrast to many of the “agile” or XP development projects, where a “customer proxy,” or end-user representative, is literally sitting in the same office cubicles, alongside the programmers), communication problems escalate. Despite the tools, the world, is not flat: you can’t just assume that software developers can be sprinkled randomly around the globe, where they’ll participate in a complex software development effort with no problems at all.

The second reason for the higher defect rate is because offshore outsourcing firms typically offer an essentially unlimited number of technical personnel at a lower labor rate, many firms think they can achieve faster delivery schedules by hiring larger teams of offshore developers than they would if they staffed the project locally – and yet still save money. Which I have explained in my previous article on “The REAL cost of Offshore” is wrong. Thus, if the firm had previously staffed a project with 10 “expensive” local programmers, they figure they can hire 20 “cheap” Indian programmers, and still save money – while (in theory) cutting the schedule in half, because they’re blissfully unaware of Brooks’ Law .

Aside from the schedule issue, it’s a known fact (but pity enough not to everyone) that software defects are strongly correlated to the number of “lines of communication” between the developers on the team; and that number increases combinatorially (i.e., N*(N-1)/2) as the size of the team increases (this is a variation on Conway’s Law , first articulated by computer programmer Melvin Conway in 1968, which says that the structure of a system is isomorphic to the structure of the organization that builds it). Hence, the number of defects in a software system increases in a manner proportional to the square of the number of developers; and as a result, he says, offshore projects are more likely to deliver buggy software.

There is a lot more to tell about core metrics needed to measure, compare and predict productivity but let me stick to the topic of Defects.

On an average, we introduce and detect 0.4 Defects (without Unit test defects) for every Staff day (including training, project management, requirements writing, testing, documentation, etc.) of effort I.o. in a medium project (10 people, 6 months) we can expect more than 500 defects!

You can find these research figures e.g. at the different SPIN presentations or use the QSM Slim tooling. But there is more, it also a known fact that the longer a Defect is in the system the more it cost (time, money, risk) to repair it. A defect inserted while writing Requirements but discovered during Acceptance test can cause a lot of rework as it can have also its influence on other parts of the system and sometimes even the architecture.

Cumulative Defect Density (defect per kloc) versus actual found Defects is an important metric to avoid the big bang on Defects in the last stage of the project. You all know by experience what management decides. First we have to make overtime, then the project team size increases, both resulting in even a higher defect density. Testers are not getting enough time to test, which leads to another important metric, defect turnaround time (time needed to change the state of a defect). More and more fixes are not being able to test and then the inevitable happens, either the project is released with bugs or it is cancelled.

A lot of defects can already being found through reviews lowering the Cost of Quality as Testing is more costly, but there is an optimum to find. But as we all know, reviewing requirements is not easy and I advocate here the Test Driven Approach. You should write Test Scenarios based on the requirements and whenever you encounter a discussion on Testing/Reviewing most likely the Project manager / Customer complaining about the extra cost then there is only one answer to give.

“If its not worth Testing, it`s not worth Developing“`which leads actually to the biggest saver in your project as the Standish Group once has estimated that 55% of the software features are hardly or not used by its users. Another point for Agile techniques, by focusing on the most important requirements first.

This conclude my view and experience on Software Development in general and more specific on what are the most important reasons why projects hardly live up to the expectations of the stakeholders.

So two inspirational moments to do so:

I will not go into cultural differences, intellectual differences, communication issues (human and technical), time and distance issues, etc.

Lets simplify it by stating that it adds WASTE to the Development Process but we [...]]]> This blog I wrote to share some of my insights on Distributed Software Development (Offshore, Nearshore, Rightshore, GRIDSHORE, whatevershore).

I will not go into cultural differences, intellectual differences, communication issues (human and technical), time and distance issues, etc.

Lets simplify it by stating that it adds WASTE to the Development Process but we don`t know how much as it depends on the situation, location experience, people involved, and so on.

WASTE is an important concept to understand as it is by far the biggest influence factor in reducing time-to-market and cost reduction. Lean Software Development is a translation of lean manufacturing principles and practices to the software development domain and focusses on removing WASTE. Adapted from the Toyota Production System, a pro-lean subculture is emerging from within the Agile community. Everything not adding value to the Customer is considered to be waste. This includes:

• unnecessary code and functionality
• bugs
• delay in the software development process
• unclear requirements
• bureaucracy
• slow internal communication

The term Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck.

I hear you saying, what about Productivity? Productivity in economics refers to measures of output from production processes, per unit of input. Labor productivity, for example, is typically measured as a ratio of output per labor-hour, an input. Its known that there can be an enormous difference in productivity between one developer and the other. Also the development language and tools they use can make a difference. Again, I will not go into the discussion if Cobol, RPG, C##, Java, Ruby is more productive than the other, neither I will state in this article my opinion on architectures like SOA.

What is important to grasp is that Productivity depends on the team size. Adding people to a team does not have a lineair posive effect on the duration (it has sometimes a negative effect) and it has certainly not a positive effect on Productivity as the input (labor hours) increases and the waste (waiting time) too.

Brooks has written about it in his book the Mythical Man Month. Everyone knows the famous example “one women can get a baby in 9 months, 9 women can not get a baby in one month“. But why are planners still not taking this into consideration. In short “If one bricklayer can do a wall in 100 days and two can do it in 50 days the productivity remains the same (nothing said about the cost as salary can differ) but its unlikely that 10 bricklayers can do it in 10 days“. The SLIM tool of QSM used by a lot of companies can show nicely this effect. I did a lot of estimations, planning and collecting data in the past working for the big consulting firms and just to illustrate the effect I have included a screenshot of my spreadsheet tool.

If you take a project of 1000 Function Points, then the optimum in duration and effort would be around a duration of 10,2 month with 6 FTE resulting in 8531 hours. The same project (1000 FP) but now done in 9 Months (what is 1,2 month you would say) will take 11,8 FTE on average and cost 14586 hours which is almost double the hours. One remedy would be splitting the project into two projects but the architecture should allow this. If you where able to split the project in a project of say 400 FP and 600 FP then you would see that with 400 FP it will take 2,9 FTE, 5,7 months and 1852 hours. The project of 600 FP will take 7,6 month with 4,5 FTE and cost 4769 hours. With some parallel development (if possible) we can meet the deadline of 9 Months and it will cost around the same as before.

Estimation of work is not equal to planning. A certain task say writing a use case, analyze a use case, design, code, test, deploy can be estimated (although not easy as re-use of existing classes comes into play). Planning although is arranging the tasks in the right order taking into consideration the dependencies on resources and other tasks. Planning of tasks takes most of the times place in the form of batches (writing requirements, analyze requirements, design, etc.) which is a form of WASTE.

So what has this to do with the REAL Cost of Offshoring? The message I want everyone to understand is that introducing WASTE but not adjusting the duration will have a dramatical negative effect on the Productivity. And not understanding this up-front will cost only more as the natural reaction when not meeting deadlines is to add more people to the project. I also noticed in the past that the local (expensive) resources are longer needed on the project too making the business case for going Offshore completely worthless.

Is there a way to overcome this? Yes, one way is to eliminate WASTE as much as possible by bringing more work Offshore (Analysis, Design, Test) and bring the local knowledge also Offshore (communication will improve a lot by doing this). But even more important, be aware of WASTE, try to eliminate it and adjust the planning (longer duration or decrease functionality) and release more often and in shorter cycles (agile).

the statement below.

“The optimist sees opportunity in every danger;

the pessimist sees danger in every Opportunity“

And the realist?