Enhancing the OPF Repository

• By Brian Henderson-Sellers
• October 5, 2001

It is always encouraging to hear of and read about new ideas that will help software developers in their daily, challenging jobs. The question is then how to incorporate these new ideas into existing methodologies and processes to make them truly effective in a commercial, rather than a research, environment. If the methodology being used is "set in stone," then this is virtually impossible and the process must stagnate. Today, there is much talk of adaptable and flexible methodological approaches to software construction. When using the OPEN Process Framework (OPF), its built-in flexibility derives from the fact that it is defined first by a metamodel and then instances of that metamodel are made available to the end user (the software development community) in the form of a repository of available process components.

Figure 1 depicts these two aspects of the OPF: the metamodel is officially at the "M2" level (using OMG terminology) this is the purview of methodologists—not users—and the repository which contains all the process components from which the end user, usually the process engineer within the development organization, can construct, modify, and tailor an organization-specific or project-specific process (at the M1 level).

Figure 1. A personalized OO development process is created from a class repository of process components using supplied construction guidelines. These are all created as instances of metalevel elements in the OPF metamodel.

The methodologist's first responsibility is to create, quality check, and validate the metamodel from where the repository instances are created. He/she should then also provide a significant set of instances in the repository for ease of use by the user (in the development organization). However, the examples of work products, work units, producers, and so on in the repository are not necessarily a complete set. Inevitably, as we learn more, new instances will be identified. These are then easily added to the repository so long as they are instances of one class in the metamodel. Thus, the OPF approach permits extension by virtue of additions to the set of repository process components. While these are generally created by the methodologists, it is also perfectly possible (at some loss of standardization) for the user to add their own process components to the repository. Extensions to the OPF metamodel itself are also easily accomplished, although these are usually rare and probably best left to the methodologist community, rather than done by the development/user community.

Thus, additional elements such as new Tasks and Techniques can easily be added to supplement the existing process components in the OPF repository. In the last two columns,^1,2 I have shown how this is easily accomplished by using two new areas of software development: components and web applications. In this column, I continue this trend of identifying new or enhanced repository elements by looking at a variety of issues, including timelines, pair programming, and robustness analysis. The selected Tasks and Techniques are fairly new to the OPF, although documented and discussed by their original authors. Here they are described only briefly, merely as examples to show the ease with which the OPF repository can be enhanced.

TIMELINES
Timelines come from the post-implementation review or "retrospective" approach of Kerth.³ We can introduce these ideas into OPEN in two ways: as a Technique: Timelines together with a Task: Identify Important Events.

(Technique) Timeline: In a workshop environment, commission one wall and cover it with butcher's paper (or something similar). Draw a line and label it with equal times across the full duration of the project recently completed. As part of a post-implementation review, the developers will be meeting with the workshop facilitator (from outside the organization ideally) in order to evaluate the experience they have just had with the project. The idea is to document the good and bad parts of the project in order to learn for the future. Rather than just document all events, individuals are asked to list the one or two major events that made for project success and the one or two major events that caused or could have caused project failure. These events are then added to the timeline and a composite pattern emerges as each individual team member makes their contribution.

(Task) Identify Important Events: This task is enacted as part of a post-implementation review i.e., after the completion of the project. It should be applied with two distinct foci—initially, the participants identify important events in the past. Using a timeline, they identify (usually within the post-implementation review) any important events that had a negative or positive impact on the progress of the project that they have just undertaken. Sometimes, this may have aspects of brainstorming in the sense that initially all ideas offered from the workshop participants are accepted as valid. Only later is there an analysis of the real impact of each individually identified event and a consensus reached as to the need to keep it on the timeline. The result is a timeline throughout the project on which agreed important events are highlighted that determined its success or failure. Typically one might see events such as:

• developers went on a really good training course;
• lead developer was seriously ill;
• third party vendor failed to deliver software;
• third party vendor delivered software early; or
• a backhoe cut optical fibre network, disrupting the communication between members of the distributed team for three days.

Secondly, the Task: Identify Important Events might use the lessons of the past to forecast the future. What have we learned and can we agree on the future? For instance, should we never have only one lead developer; or always requisition components from the very reliable Vendor B.

SWOT ANALYSIS
SWOT stands for Strengths, Weaknesses, Opportunities, and Threats. SWOT analysis is a well known management technique which can usefully be adopted as an OPEN Technique. A 2 x 2 matrix is constructed in order to depict the answers to these four question areas. To complete the boxes, detailed questions such as the following should be posed and answered.

Strengths (do not be modest, but do be realistic)

• What are your advantages?
• What do you do well?

Weaknesses (evaluated from both an internal and external perspective)

• What could be improved?
• What is done badly?
• What should be avoided?

Opportunities

• Where are the good chances facing you?
• What are the interesting trends?

Note that interesting opportunities may arise from many areas such as changes in technology and in markets, both locally and globally, changes in government policy that might affect your domain, changes in social patterns, demographic profiles, lifestyle changes, and local events.

Threats

• What obstacles do you face?
• What is your competition doing?
• Are there new competitors?
• Are the required specifications for your job, your products or your services changing?
• Is changing technology threatening your position?
• Do you have a bad debt or cash-flow problem?

Strengths and Weaknesses are internal factors, in contrast to Threats and Opportunities that refer to the domain external to you and your organization.

SWOT analysis can be applied to many areas of software development; for instance in web site development for marketing strategies, strategic links for the organization, and Web site design. Its main aim is to highlight key issues and to facilitate a strategic approach.

GAP ANALYSIS
Gap analysis is a general technique taken into the OPF Repository that can also be usefully applied in building OO and component-based systems. When using gap analysis (sometimes called "needs analysis"), you evaluate the trade-offs between what you have and what you would like to ideally have. This sometimes underpins the notion of sufficing—accepting something because it is "close enough." In gap analysis, you try to evaluate the difference between the expectation and reality more quantitatively so that you can compare options. Other characteristics might also impinge on the decision making process in addition to the technical comparison—for instance costs, ease of future upgrading, or ease of replacement by an alternative component in the future.

PAIR PROGRAMMING
With the advent of Extreme Programming, (XP)⁴ postdating the publication of the original OPEN Process Specification,⁵ it is often asked whether OPEN and XP can be made compatible. The answer is simple. Yes, just about everything in XP already exists in the OPF Repository—with one major exception, that we hereby rectify by adding the Technique of pair programming into the Repository.

Pair programming is an excellent idea for ensuring good quality code. Apparently doubling the investment in people to create code, it is clear from recent studies⁶ that two people collaboratively working on a single design or piece of code leads to higher quality software and improved overall productivity.

Two people at one keyboard means that one is typing/coding and the other reviewing, thinking, advising, and mentoring. The two roles are frequently reversed so that the two people have equal investments and responsibilities. They also share the ownership.

The technique is found to identify many defects immediately and thus eliminate them from the design or code. Since defects in delivered code are well known to be extremely expensive to correct, the overall productivity and quality of the delivered software must consequently rise. Peers put pressure on each other to enhance their performance; it is noted⁶ that the driver of the pair is less likely to spend time on the telephone or Web surfing with a partner awaiting them. And, finally, programmer satisfaction seems also to increase. Williams et al.⁶ report a 96% increase; although these authors also note that when a partner is found to be troublesome, for example with a high ego, serious difficulties can arise.

ROBUSTNESS ANALYSIS
Robustness analysis is a technique originating in Object-Oriented Software Engineering⁷ although not by that name, and subsequently lost. Resurrected by Rosenberg in the Iconix method,⁸ it seems highly apposite to propose it also for use as a Technique in OPEN.

Robustness analysis provides a link between use cases and sequence diagrams; between the what (the "analysis") and the how (the "design"). Without robustness analysis there is no obvious way of identifying objects used in sequence diagrams directly from the use cases (in that there are no explicit objects since their focus is on describing functionality) and thus ensuring that there is a compatibility between the two. Robustness analysis is also useful for checking the validity of a use case as well as ensuring their completeness in toto. Finally, robustness analysis is useful in identifying other missing classes in the analysis.

In the original use of robustness analysis,⁷ the developer starts with the use case and from this is assisted in identifying appropriate classes which can then be classified, for example, into Jacobson's trio of boundary, entity, and control classes. In the Iconix process,^8,9 robustness analysis is used to integrate use case modeling, domain modeling, and user interface modeling, with all three done in parallel and iteratively.

A robustness diagram depicts these three types of objects with arrows connecting them. However, these arrows do not represent message passing, as they would on a sequence diagram, but rather logical associations. These can be either unidirectional or bidirectional, but the arrowhead style is arbitrary. The ways that objects can be connected in a robustness diagram follow four rules⁸ based on the separation of concerns:

1. actors outside the system can only be associated with boundary objects;
2. boundary objects can only be linked to control objects (and actors—see the first rule);
3. entity objects can only be linked to control objects; and
4. control objects can be linked to entity objects, boundary objects, and other control objects—but not to actors.

Overall, Rosenberg and Scott⁸ recommend a small number (two through five, possibly as many as 10) of control objects for each use case.

Commencing with the use case, a textual document, textual analysis will reveal some candidate (or "first-guess") objects. Document these as either boundary, entity, or control objects. Then, start to link these objects using the rules given listed earlier, and in doing so, evaluate whether or not all alternative courses are covered; whether all functions are correctly identified; and where the data comes from. This may well lead to the identification of brand new classes, not visible or even implicit in the problem statement of the use case. The technique iterates between the robustness diagram and the use cases until all classes have been discovered and the consistency of the overall design verified.

Once we have these "objects" in a draft class model, sequence diagrams can be tentatively drawn with each object at the head of a timeline, as normal. The robustness diagram is not meant to be an end work product, maintained forever, but merely as a stepping stone to move from the functional world of use cases to an OO world where classes interact and are depicted using class diagrams, collaboration diagrams, and sequence diagrams.

INTELLIGENT AGENT IDENTIFICATION
Intelligent agent-based systems have been investigated in research laboratories for many years, but are only now poised to enter commercial reality.¹⁰ As a precursor to more extended support for intelligent agents, we have introduced into the OPF a new Technique named "Intelligent agent identification" to mirror the existing Technique—CIRT identification as well as similar techniques discussed recently¹¹ for the identification and use of likely components.

Identification of agents is in some ways an extension of "finding the objects." Agents are autonomous entities that have many similarities to objects. A major difference is that whereas an object receiving a request for service must deliver that service, an agent is empowered to say "no." Agents play roles with responsibilities. These responsibilities are not only equivalent to those for objects (responsibilities for doing, knowing, and enforcing) but also towards achieving organizational goals.¹⁰ They closely mimic the behavior of people and their decision making strategies than can objects. Consequently, there is a greater emphasis on the roles that are played by agents. Each role is defined by four attributes: responsibilities, permissions, motivations, and protocols.¹² Roles are already well-supported in OPEN.

SUMMARY AND CONCLUSIONS
The OPF Repository contains instances of the classes in the OPF metamodel. It is these instances—rather than the metamodel architecture—that is of interest to process engineers and users of an OPEN process instance, that is a specially constructed and tailored version of OPEN exactly appropriate to the individual demands of the current project.

As our knowledge of system development using objects and components (and in the future intelligent agents) grows, so too does the need for methodological support. This is readily offered in the OPEN Process Framework by the addition of elements into the repository from which the process is created. In this column, I have reviewed a number of more recent additions to this repository. In particular, I have introduced to the OPEN community tasks and techniques to support Timelines, SWOT analysis, Gap analysis, Robustness analysis, and Intelligent agent identification.

Acknowledgements
I wish to thank Jeff Kantor and Dan Rawsthorne for their comments on an earlier version of this column. This is Contribution No. 01/11 of the Centre for Object Technology Applications and Research (COTAR).

References

1. Henderson-Sellers, B."Adding CBD to OPEN," Journal of Object-Oriented Programming, 13(12): 24–28, April 2001.
2. Henderson-Sellers, B., B. Haire, and D. Lowe. "Adding Web Support to OPEN," Journal of Object-Oriented Programming, 14(3): 34–38, Aug./Sept. 2001.
3. Kerth, N.L. Project Retrospectives: A Handbook for Team Reviews, Dorset House, New York, 2001.
4. Beck, K. Extreme Programming Explained, Addison–Wesley, Reading, MA, 2000.
5. Graham, I., B. Henderson-Sellers, and H. Younessi. The OPEN Process Specification, Addison–Wesley Longman Ltd., London, UK, 1997.
6. Williams, L., R. R. Kessler, W. Cunningham, and R. Jeffries. "Strengthening the Case for Pair Programming," pp.19–25, IEEE Software, July/Aug. 2000.
7. Jacobson, I., M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach, Addison–Wesley, Reading, MA, 1992.
8. Rosenberg, D. and K. Scott. Use Case Driven Object Modeling with UML: A Practical Approach, p. 165, Addison–Wesley, Reading, MA, 1999.
9. Rosenberg, D. and K. Scott. Applying Use Case Driven Object Modeling With UML: An Annotated E-commerce Example, p. 176, Addison–Wesley, Reading, MA, 2001
10. Jennings, N. "Agent of change," Application Development Advisor, 5(3): 6, 2001.
11. Henderson-Sellers, B. "An OPEN Process for Component-Based Development," (Chapter 23), Component-Based Software Engineering: Putting the Pieces Together, Eds. G.T. Heineman and W. Councill, Addison–Wesley, Reading, MA, 2001.
12. Wooldridge, M., N. R. Jennings, and D. Kinny. "The Gaia Methodology for Agent-Oriented Analysis and Design," Journal of Autonomous Agents and Multi-Agent Systems, pp. 3, 285–312, 2000.