OPEN and RUP: How Do They Compare?

• By Gary Collins, Brian Henderson-Sellers, I. Graham
• July 13, 2001

In a recent column,¹ we discussed some of the rationale behind a tailorable process framework as compared to an object-oriented process supplied "out of the box." In addition, we showed how different existing OO processes, both elaborative and translative, could be generated from the single-process framework known as Object-oriented Process, Environment, and Notation (OPEN).² Since there is increasing interest in one specific example of an elaborative methodology (Rational Unified Process [RUP]³) as well as in the flexibility offered by the OPEN Process Framework (OPF) approach, in this month's column we directly compare these two third-generation approaches to OO- and component-based development (CBD).

TAILORABILITY
First, we must remind ourselves what is meant by "tailorability." An important requirement from industry in the context of the adoption of an OO process is the extent to which the process can be modified or "tailored" to industry needs. Tailorability can have many guises, as we discussed earlier,¹ but falls into one of these two broad categories:

1. The user may start with a framework, probably defined by a metamodel, then populate that framework in a bottom-up manner (see Fig. 1). This gives a finely tuned process for specific organizational needs. It costs effort in the creation of the process from the process framework but has the distinct advantage of a 100% fit with organizational or project-specific requirements.
2. The user may start with an instance of the metamodel, sold as a pretailored product by the vendor (who has also done all the selection of items with which to populate the framework). Further tailoring by the customer is strictly limited (see Fig. 2). And when it is Web-enabled, as in RUP, it is even more difficult for these changes to be maintained in a manner compatible with future releases of the product.⁴ Tailoring is said to be mainly achieved by timeline dilation or by the omission of some of the prepackaged elements, which may be specific techniques, deliverables, or workflows such as business modeling.

OPEN falls into the first category and can be called a tailorable framework. Its instances, tailored for specific organizations or domains, might be called OPEN instances or OPEN variants (see Fig. 7 of "Tailoring Process-Focused OO Methods"¹)—some specific examples were discussed in "Instantiating the Process Metamodel."⁵ OPEN's framework approach also supports extensibility of the framework itself, and hence process improvement, leading an organization towards CMM Level 5.

RUP, on the other hand, is a prepackaged, pretailored instance of its own metamodel and could thus be described as an actual process or methodology. Its tailorability is limited. According to its official description in The Rational Unified Process³ (p. 225), this tailoring is restricted to changing relative durations; expanding, modifying, or removing steps from specific activities; tailoring the templates by adding company logos; and adding new checkpoints to the review activities. Tailoring is potentially further restricted by the tight linkages between the process and the tool set provided (i.e., sold) by Rational, which itself contains no way of incorporating feedback to improve the process as required at CMM Level 5. It is further constrained by the stated need (e.g., in The Unified Software Development Process⁶ [pp. 5, 38] and in The Rational Unified Process³ [pp. 30, 98]) that the RUP must be driven by use cases. This obviously precludes the use of RUP in situations that need to be data driven, responsibility driven, document driven, etc., thus severely limiting its tailoring capabilities.

RUP AND OPEN: A COMPARISON
While RUP and OPEN have many similarities, particularly at the metalevel, there are clear distinctions. In summary, the most obvious are:

• RUP has limited tailorability and OPEN is fully tailorable (see Fig. 3). Any pretailored product costs no effort in tailoring but may or may not "fit the bill." In the former case, it is clearly the best solution; in the latter, trying to change something not intended for change may be overly difficult. In contrast, a flexible framework requires costly tailoring but the final result has a 100% fit to requirements.
  
  
• RUP is a proprietary product and OPEN is in the public domain. Here we must, de facto, consider the public domain "face" of RUP.
• RUP (or at least the Unified Process) can only use UML since "UML is an integral part of the Unified Process"⁶ (p. 4), whereas OPEN can support any current (and future) notation of appropriate quality. This means there is a danger RUP may be severely constrained by the (current) incomplete nature of the UML.
• RUP must be use-case driven, as noted earlier. Everything relies on the use cases—even the workflows are derived from use cases⁶ (p. 5—although "how" is not stated!) and each iteration deals with a discrete set of use cases⁶ (p. 7). Yet no comprehensive suite of metrics is derivable from use cases. In contrast, OPEN supports a range of approaches to OO software development (use-case driven, responsibility driven, data driven, etc.).
• While both RUP and OPEN can be said to be waterfall (or rather serial) at the macro (or business) level, RUP uses an embedded waterfall for its iterative structure while OPEN uses an embedded fountain or contract-driven (objectified) software engineering process.

Neither RUP nor OPEN (as published in Version 1) are explicit about the difference between the product life cycle and the process life cycle, although this is discussed in The OPEN Process Specification² (pp. 21, 26) and this discrimination has now been incorporated into Version 2 of OPEN, in which some minor modifications are made to accommodate this upgrade.⁷ OPEN describes and advocates the use of timeboxing, as do DSDM⁸ and SOMA⁹—a highly effective and proven concept totally ignored in RUP. Also ignored in RUP is the idea of a set of principles as utilized by DSDM and, to a lesser degree, by OPEN.²

A further comparison exists in the choice of terminology. RUP chooses neologistic terminology rather than standard project management (PM) practice.¹⁰ To gain a fair comparison, it is therefore necessary to seek a mapping between these RUP terms and OPEN's more standard terminology. This can be accomplished by comparison of definitions and consideration of the two metamodels. There are many clear equivalencies. For example, OPEN "Producer" is exactly the same as the RUP term "Worker"; the definition of RUP's Activity is identical to OPEN's definition of Task. (We suggested a full set of mappings in a previous column.⁷)

One of the hardest parts of this terminological comparison is at the highest level of abstraction. OPEN's process framework describes the full life cycle. This means it encompasses not only the software part of the life cycle but also the business and end-user aspects. Whether the same can be said for RUP is debatable. There are many places in The Rational Unified Process³ and The Unified Software Development Process⁶ where it is clearly stated that RUP/UP only addresses the software component of a software-intensive system's development and ignores business and user issues. It also, by the way, ignores cross-project issues such as domain analysis and reuse, and only supports an incremental (called iterative in RUP)—not a truly iterative—approach to development. If, on the other hand, we extend the current four phases of RUP to cover the business issues, we can then equate RUP's Phases to OPEN's Stages⁷ (see Table 1). If this interpretation—i.e., that the RUP Phases correspond to OPEN Stages of the product life cycle (dealing with business issues), and the Elaboration and Construction Phases in RUP permit detailed description of all the tasks and techniques of the technical IT area—is correct, then the suggestion in the RUP "hump" diagram that all core workflows occur in all phases is somewhat misleading. What is needed is for the elements currently in the Inception and Transition Phases contributing to the nonzero effort curve in this figure to be folded into the Elaboration and Construction Phase, leaving a product-with-embedded-process life cycle as shown in Figure 2 of "Process and Product Life Cycles"⁷ at the highest level of abstraction. As a bonus, this assumption also clarifies a further mapping between RUP's Workflows and OPEN's Activities (see Table 1).

Table 1. Proposed mappings between OPEN Version 2 and RUP terms.
OPEN Terms	RUP Terms
Stage	Phase
Activity	Workflow (detail)
Task	Activity
Subtask	Activity
details of Task (not given name in OPEN)	Step (a.k.a. Activity Step)
Technique	Guideline (+ template + mentor) in RUP tool
Assertion	Trigger
Work Product	Artifact
Producer	Worker
Incremental	Iterative
Iterative	—

Another characteristic is the mode and extent to which RUP and OPEN support PM. In RUP, PM is allocated its own specific workflow, whereas in the OPF it exists in several activities, tasks, and techniques throughout the process elements.

Support for PM is clearly crucial for a process to work on real projects. PM can be defined as the management of people and other resources by a leader in order to plan, analyze, design, construct, test, deploy, and maintain an OO information system. Ideally, the process itself needs continual feedback and modification to improve and meet the business needs.

In OO developments, as in traditional software developments and in nonsoftware projects, the responsibilities, variables, and tasks of a project manager remain the same:

• Responsibilities of organizing, directing, communicating, staffing, planning, and control;
• Variables of scope, time, people, money, tools and techniques, and quality;
• Tasks of scheduling, estimating, monitoring, planning, and risk management, including contingency planning, change management, and associated configuration management.

While the responsibilities, variables, and tasks of a project manager are unaltered, the context in which they operate has been modified. Cognizance needs to be taken of different team structures for OO development to meet the expectations of an iterative, incremental, and parallel (IIP) delivery life cycle. Organizational reuse also requires a different perspective, particularly as we move to a component-oriented development environment. Finally, the use of metrics may have different repercussions; for example, code-size growth rates may be negative when refactoring occurs.

The structure of OPEN means that PM elements exist both in its Activities (and associated Tasks) and in the specification of particular PM techniques, e.g., approval gaining, cost estimation, library management, project planning, risk analysis, and team building.^11,12 Certainly there is extensive support. Rather than a single Workflow (OPEN Activity) as in RUP, PM tasks and techniques are fully integrated in OPEN. A number of the Activities reflect PM perspectives. The important details of PM fall into two major and one minor task: develop software development context plans and strategies, develop and implement a resource allocation plan, and undertake a feasibility study, respectively. There are also a number of quality-focused tasks that might reasonably be grouped into this set of PM-focused tasks.

Within the two major PM Tasks in OPEN, there are many subtasks that deal with specific aspects of either "planning" or "resource management." These include items such as choice of project teams, as well as roles and responsibilities within those teams, choice of hardware and software, specification of goals, development of an iteration plan, and so on (details are to be found in The OPEN Process Specification²). Each of these Tasks is supported by numerous fine-grain Techniques; these are collected together in OPEN's Toolbox.¹² The key element in OPEN is that the linkages between Activities and Tasks and, secondly, between Tasks and Techniques are accomplished, as throughout OPEN, by the use of possibility (or deontic) matrices that assist the method engineering in tailoring the most efficacious pairings, thus accomplishing high-quality software development in the most efficient manner.

In RUP, in contrast, all of the PM elements are grouped together as a separate PM core-supporting workflow, which operates in parallel to the other core workflows and across each iteration workflow. In addition, the actual depth of support for PM is limited. And, as we noted earlier, use of nonstandard PM terminology obfuscates the RUP model further; for instance the use of the word activity to mean task, i.e., the smallest unit of work.

Although derived in large part from the work of Royce,¹³ there are many areas in RUP that show deficiencies from a PM viewpoint. Ambler¹⁴ identifies a number of flaws in RUP's support for PM:

• neglect of several aspects of the larger-scale management issues, especially maintenance and support;
• omission of any support for reuse or associated component library management and cross-project capability;
• overdependence on existing tools (of the vendor) leads to neglect of areas that cannot be automated; and
• weakness in areas such as metrics management, reuse management, people management, and testing.

However, he applauds

• the use of sound software engineering principles focusing on incremental and architecture-based development approaches;
• the linking of prototypes to ends of iterations providing the ability to make go/no-go decisions; and
• the serious investment in software tool support (RUP is after all a tool/product itself).

Cost estimation is discussed in detail in Object-Oriented Project Management with UML¹⁵ although Cantor's emphasis is on what needs to be done rather than how it is to be achieved. He outlines elements of budget tracking techniques and recommends the use of the COCOMO family of models¹⁶ for sizing OO projects. Nevertheless, this is still significantly more support than that described in The Rational Unified Process.³ In RUP's PM Workflow, there are three key purposes: provision of a framework for managing software-intensive projects (in other words, only relevant to the process life cycle of software development); provision of guidelines for planning, staffing, executing, and monitoring projects; and provision of a risk-management framework. Specifically, RUP is said not to cover management issues such as managing people, managing budgets, and managing contracts.

This Workflow concentrates on issues such as planning the details of an iterative project, both at the phase level and at the iteration level, the latter built on traditional techniques such as Gantt charts. Risk management is also an important key feature, although there is little detail in The Rational Unified Process³ (pp. 112–113) about how to go about avoiding, transferring, or accepting risk (either by mitigation or by defining a contingency plan). Metrics are also discussed in passing and with little detail—there is, for instance, no mention of the Goal-Question-Metric paradigm¹⁷ or, at the other extreme, of detailed complexity metrics such as those described in Object-Oriented Metrics.¹⁸ In contrast, OPEN has a large number of tasks and techniques devoted to quality, cost estimation, design, and code metrics. There is significant research backing to the metrics.^{9, 18–21}

OPEN also offers support for projects that are not greenfield projects (a restriction apparent in RUP) through its support for enhancements to existing software in the form of repeated applications of the product life cycle, and through its support of programs of projects that span several software developments, including tasks and techniques focusing on reuse, domain analysis, and program-level resource allocation, as well as on people issues such as team building and organizational roles.

CONCLUSION
Finally, the degree of tailorability in these two processes is vastly different. In particular, placing new demands on PM such that a new workflow (in RUP terminology) or a new Activity (in OPEN and standard PM terminology) is required, would be virtually impossible in RUP (because of the tight constraints to the tool set, etc.) and extremely easy in OPEN (this eventuality was always considered throughout the gestation period of OPEN). Furthermore, the insistence by Jacobson that an OO process must be use-case driven creates some difficulties in integrating ideas of Software Project Management¹³ and others who contemplate a rise in the interest (and necessity for) architecture-driven thinking.

Acknowledgment
This is Contribution no. 00/4 of the Centre for Object Technology Applications and Research (COTAR).

References

1. Henderson-Sellers, B. and S. Mellor. "Tailoring Process-Focused OO Methods," JOOP, 12(4): 40–44, 59, July/Aug. 1999.
2. Graham, I., B. Henderson-Sellers, and H. Younessi. The OPEN Process Specification, Addison Wesley Longman Ltd., London, UK, 1997.
3. Kruchten, P. The Rational Unified Process. An Introduction, Addison–Wesley, Reading, MA, 1999.
4. Rational. White paper at http://www.rational.com, 1999.
5. Henderson-Sellers, B. et al. "Instantiating the Process Metamodel," JOOP, 12(3): 51–57, June 1999.
6. Jacobson, I., G. Booch, and J. Rumbaugh. The Unified Software Development Process, Addison–Wesley, Reading, MA, 1999.
7. Henderson-Sellers, B. and I. Graham. "Process and Product Life Cycles: OPEN's Version 2 Life Cycle Model," JOOP, 13(1): 23–26, 39, Mar./Apr. 2000.
8. Stapleton, J. DSDM. Dynamic Systems Development Method: The Method in Practice, Addison–Wesley, Harlow, UK, 1997.
9. Graham, I. M. Migrating to Object Technology, Addison–Wesley, Wokingham, UK, 1995.
10. Duncan, W. R. A Guide to the Project Management Body of Knowledge, Project Management Institute, PA, 1996.
11. Henderson-Sellers, B. and R. T. Due. "OPEN Project Management," Object Expert, 2(2): 30–35, Jan. 1997.
12. Henderson-Sellers, B., A. J. H. Simons, and H. Younessi. The OPEN Toolbox of Techniques, Addison Wesley Longman Ltd., UK, 1998.
13. Royce, W. Software Project Management. A Unified Framework, Addison–Wesley, Reading, MA, 1998.
14. Ambler, S. "Completing the Unified Process with Process Patterns," white paper available at http://www.ambysoft.com/unifiedProcess.html, 1999.
15. Cantor, M. Object-Oriented Project Management with UML, John Wiley & Sons, New York, 1998.
16. Boehm, B. W. Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ, 1981.
17. Basili, V. R. and H. D. Rombach. "The TAME Project: Towards Improvement-Orientated Software Environments," IEEE Trans. Software Eng., 14(6): 758–773, June 1988.
18. Henderson-Sellers, B. Object-Oriented Metrics. Measures of Complexity, Prentice–Hall, Englewood Cliffs, NJ, 1996.
19. Henderson-Sellers, B. "The Goals of an OO Metrics Programme," Object Magazine, 5(6): 72–79, 95, Oct. 1995.
20. Haynes, P. and B. Henderson-Sellers. "Cost Estimation of OO Projects: Empirical Observations, Practical Applications," American Programmer, 9(7): 35–41, July 1996.
21. Henderson-Sellers, B., L. L. Constantine, and I. M. Graham. "Coupling and Cohesion (Towards a Valid Metrics Suite for Object-Oriented Analysis and Design)," Object-Oriented Systems, 3, 143–158, Sept. 1996.