TOOLS/TOOLS99/USAPM.TEX Existing OO ... - Semantic Scholar

Manuscript: TOOLS/TOOLS99/USAPM.TEX

Existing OO Process-Focussed Methods: A Critique of RUP and OPEN from a PM perspective B. Henderson-Sellers1 , R. Du¶e2 and I. Graham3 1

School of Computing Sciences University of Technology, Sydney Broadway, NSW, Australia 2 Thomsen Du¶e and Associates Edmonton, Alberta, Canada 3 Ian Graham and Associates London, UK Printed: July 25, 1999

(for presentation at TOOLS Workshop on \Project Management of Object-Oriented Developed Systems")

Address for Correspondence Professor B. Henderson-Sellers Director, Centre for Object Technology Applications and Research School of Computing Sciences University of Technology, Sydney P.O. Box 123 Broadway NSW 2007 AUSTRALIA fax: +61 2 9514 1807 email: [email protected]

Abstract Second generation OO methods, with a few exceptions, contained no elements addressing process or project management. Third generation methods have been de¯ned as those collaborative developments which also have a signi¯cant process element. The two main candidates are Rational Uni¯ed Process (RUP) and Object-oriented Process, Environment and Notation (OPEN). In this paper, we critique RUP and OPEN from a project management viewpoint and evaluate whether either or both would meet acceptable standards in process support, project management guidelines and full lifecycle description for OO software development.

1. RUP and OPEN: A Comparison While RUP (also UP) and OPEN have many similarities, particularly at the metalevel, there are clear distinctions. The most obvious are that: ² RUP is a proprietary product and OPEN is in the public domain ² RUP has limited tailorability and OPEN is fully tailorable (Figure 1) ² RUP (or at least the Uni¯ed Process) can only use UML since \UML is an integral part of the Uni¯ed Process' (Jacobson et al., 1999, p4), whereas OPEN can support any current (and future) notation of appropriate quality ² RUP must be use-case-driven. Everything relies on the use cases | even the work°ows are derived from use cases (Jacobson et al., 1999, p5) [although how is not stated!] and each iteration deals with a discrete set of use cases (Jacobson et al., 1999, p7). In contrast, OPEN supports use-case-driven, responsibility-driven, data-driven etc. approaches to OO software development ² While both can be said to be waterfall (or rather serial) at the macro (or business level)1 , RUP uses an embedded waterfall for its iterative structure while OPEN uses an embedded fountain or (objecti¯ed) contract-driven software engineering process. 2. Terminologies RUP chooses terminology purposefully di®erent from standard project management (PM) practice. 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 de¯nitions and consideration of the two metamodels. From the de¯nitions it is clear that the term Producer in OPEN is the same as Worker in RUP (Table 1). Similarly, the 1

Neither RUP nor OPEN (as published) are explicit about the di®erence between the product lifecycle and the process lifecycle (Figure 2), as described by HendersonSellers and Edwards (1994), although this is discussed in Graham et al. (1997, pp21, 26). Certainly Version 2 of OPEN will make some minor modi¯cations to accommodate this upgrade).

1

Table 1 Approximate mappings between OPEN and RUP terms OPEN Terms Activity Task details of Task (not given name in OPEN) Technique Assertion Deliverable (V1) Work Product (V2) Producer

RUP Terms Phase or Stage or Work°ow detail or Iteration work°ow Activity Step or Activity Step Guideline + template + mentor) in RUP tool Trigger Artifact Artifact Worker

notion of Deliverable in OPEN (renamed Work Product in Version 2) is the same as the RUP notion of Artifact. In OPEN, a Task is de¯ned as the smallest unit of work that can be project managed (Goldberg and Rubin, 1995, p144; Henderson-Sellers, 1999) and this is essentially the same as the de¯nition given by Jacobson (1998) in which the RUP Activity is de¯ned as \a unit of work a worker may be asked to perform". This gives an equivalence between the OPEN Task and RUP's Activity2 (Table 1). In RUP, Activities are explicitly broken down into a set of sequential Activity Steps | the equivalent in OPEN's Tasks is not given a separate name. OPEN Techniques (answering the question \how?") are equivalent to RUP Guidelines, supported only in the proprietary part of the process and also by templates and mentors. Sequencing is done by Assertions (in OPEN) and by Triggers (again explained only the proprietary, unpublished part of RUP) (Kruchten, 1999b) The only signi¯cant di±culty in mapping between OPEN and RUP occurs in the use of the terms Activity (and Subactivity) in OPEN and the use of terms like Phase and Work°ow (both core work°ow and iteration work°ow) in RUP. Henderson-Sellers and Mellor (1999) suggest that the concept of the RUP Phase seems to correspond to the concept of Activity in the OPEN metamodel (Table 2(a)) since the Phases in RUP are described as giving the management perspective (Kruchten, 1999b). Thus the RUP Inception Phase would map to the Project Initiation Activity of OPEN (Figure 3); the RUP Elaboration Phase subsumes Requirements engineering; model re¯nement and project planning Activities (not all shown explicitly in this diagram). Construction is equivalent to the Build Activity and Transition to Implementation Planning. There is no equivalent to the Evaluation Activity of OPEN nor to any activities in the Programme part of OPEN. Kruchten (1999b), however, recommends a mapping of the OPEN Activity to either Work°ow detail or Iteration Work°ow in RUP. The problem 2

Although we should note that in Booch et al. (1999) the RUP Activity is de¯ned to be an aggregate of Tasks and Techniques.

2

Table 2a Possible mapping between OPEN's Activities and RUP's Phases OPEN

RUP

Terms

Examples

Terms

Examples

Activity

Project initiation

Phase

Inception

Requirements

Elaboration

Engineering Build

Construction

Implementation

Transition

Planning

Table 2b Alternative mapping between OPEN's Stages and RUP's Phases OPEN Version 2

RUP

Terms

Examples

Terms

Examples

Stage

Business Planning

Phase

Inception

Build

Elaboration + Construction

Delivery/

Transition

Deployment here, simply, is that there is one concept in OPEN (Activity) yet two alternatives (with respect to mappings) concepts in RUP (Phase and Work°ow). A key consideration here is whether the RUP Inception phase assumes a software solution (i.e. whether it ignores business issues of the \product lifecycle") or whether these aspects of the business | seeking sponsorship, getting project approval etc. | are part of Inception. The implication that RUP is software focussed is strong in UP/RUP (e.g. Jacobson et al., 1999, p342; Kruchten, 1999a, p109) and this viewpoint is also supported in Cantor's (1998) controlled iteration lifecycle model which is strongly identi¯ed with UP/RUP. He states (p167) that the inception phase \starts after the software development plan : : : has been written and approved. Management is fully committed : : : and you have permission to proceed". This clearly identi¯es Inception as the start of the software focussed \process lifecycle" of Figure 2. This is con¯rmed (p177) by the recommended creation of top-level class diagrams in Inception, again a component only of the software, not the business, domain. An alternative mapping results if we take into account the OPEN Version 2 proposals for discriminating between the \product" and \process" lifecycles as illustrated in Figure 2. Now we might consider and evaluate a possible equivalence mapping between the three 3

\Stages" in MOSES/OPEN and the four RUP Phases (Table 2b). This has appeal because of (1) the solidly sequential nature of the Phases in RUP and Stages in OPEN Version 2 together with (2) the strong emphasis on strictly >1 core work°ows that take place in Elaboration + Construction in comparison with the almost mono-core work°ow situation in the Inception Phase (only Requirements work°ow) and in Transition (dominated by Deployment core work°ow plus some small amount of User testing3 ). While we might recommend this as a way forward for RUP, this appealing idea is quashed in the current version since it is made clear (Jacobson et al., 1999, p105; Kruchten, 1999a, p64) that RUP concentrates on IT issues and neglects the importance of business decisions (as seen in the MOSES Business Planning Stage in Figure 2) and starts with the assumption that a software solution has already been selected. Indeed, Jacobson et al. (1999, p342) discuss some of the (business decision-making) events that have to take place before the commencement of the Inception Phase. However, there are some hints (Jacobson et al., 1999, p319 and p341; Kruchten, 1999a, p64) that it is intended that Inception should include business decision-making processes. At present, however, the activities in this Phase seem to blur any distinction between business decision-making and the IT solution space by including aspects of both (see, for example, the four bullet points on page 85 of Jacobson et al., 1999, three of which are IT focussed and only one on business issues). Indeed, it is clear that some items, clearly relevant to business issues, are precluded from RUP | for instance, the construction of the phase plan (Kruchten, 1999a, p109) is outside (before) the Inception Phase of RUP. This con¯rms a de¯ciency of RUP in terms of its inadequate coverage of the business issues in software development (as it also ignores reuse and cross-project or programme issues such as domain analysis, as supported by OPEN). If this interpretation is correct, i.e. that the RUP Phases correspond to OPEN Stages of the product lifecycle (dealing with business issues) and the Elaboration + Construction Phases in RUP permit detailed description of all the tasks and techniques of the technical IT area, then the strong suggestion in Figure 4 (used as a prime explanation of the RUP) that all core work°ows occur in all phases is somewhat misleading. What is needed is for the elements currently in the Inception and Transition Phases contributing to the non-zero e®ort curve in this ¯gure to be folded into the Elaboration + Construction Phase, leaving a product-with-embedded-process lifecycle as shown in Figure 5 | essentially equivalent to Figure 2. In this case, Work°ows in RUP truly map to OPEN's Activities | although the level of granularity and detailed descriptors are (currently) a little di®erent. Table 1 is thus revised | as shown in Table 3. 3. Project management elements Project management in an OO software development environment can be de¯ned as: 3

The non-zero e®ort in requirements engineering is at odds with the emphatic statement by Cantor (1998, p283) to \Resist all attempts to add functionality during the transition phase."

4

Table 3 Revised mappings between OPEN Version 2 and RUP terms OPEN Terms

RUP Terms

Stage

Phase

Activity

Work°ow (detail)

Task

Activity

Subtask

Activity

details of Task

Step (a.k.a. Activity Step)

(not given name in OPEN) Technique

Guideline + template + mentor) in RUP tool

Assertion

Trigger

Work Product

Artifact

Producer

Worker

² 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 In order to ful¯l this, a project manager needs some support in the form of a project management methodology, either overlain on the technical development (as in RUP) or fully integrated (as in OPEN). In OO developments, as in traditional software developments and on non-software projects, the reponsibilities, variables and tasks of a project manager remain the same: ² Responsibilities of Organizing, Directing, Sta±ng, Planning, Control ² Variables of Scope, Time, People, Money, Tools & Techniques, Quality ² Tasks of Scheduling, Estimating, Monitoring, Contingency Planning, Risk Management While the responsibilities, variables and tasks are unaltered, the context in which they operate has been modi¯ed. Cognizance needs to be taken of di®erent team structures for OO development to meet the expectations of an iterative, incremental and parallel (IIP) delivery lifecycle. Organizational reuse also requires a di®erent perspective, particularly as we move to a component-oriented development environment. Finally, the use of metrics may have di®erent repercussions, for example, code size growth rates may be negative when refactoring occurs. OPEN also suggests that you de¯ne your own Project Charter which contains an agreed statement on (i) Business Statement, (ii) Description, (iii) Context Model, (iv) Methodology, (v) Project Resource Estimates and Schedules, (vi) Quality Assurance, (vii) Post-Implementation Review and (viii) Risk Analysis and Contingency Planning (Du¶e and Henderson-Sellers, 1995). This Charter is an encapsulated agreed statement on the constraints and resources available. It is a source of reference should disputes arise later. The structure of OPEN means that project management elements exist both in its Activities (and associated Tasks) and in the speci¯cation of particular PM techniques 5

(e.g. approval gaining; cost estimation; library management; project planning; risk analysis; team building: Henderson-Sellers et al., 1998). Certainly there is extensive support. Rather than a single Work°ow (OPEN Activity) as in RUP, project management tasks and techniques are fully integrated in OPEN. A number of the Activities re°ect PM perspectives. The important detail comes in the two major and one minor tasks (Task: Develop software development context plans and strategies; Task: Develop and Implement Resource Allocation Plan; and Undertake Feasibility Study, respectively). There are also a number of quality focussed tasks which might also reasonably be grouped into this set of PM-focussed tasks. Within the two major PM Tasks in OPEN, there are many subtasks which deal with speci¯c aspects of either \planning" or \resource management". These include items such as choice of project teams, as well as r^oles and responsibilities within those teams; choice of hardware and software; speci¯cation of goals; development of iteration plan and so on. (Details are to be found in Graham et al., 1997). Each of these Tasks is supported by numerous ¯ne-grain Techniques | these are collected together in OPEN's toolbox (Henderson-Sellers et al., 1998). 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 which assist the method engineering in tailoring the most e±cacious pairings and thus accomplishing a high quality software development int he most e±cient manner. In RUP, in contrast, all of the PM elements are grouped together as a separate project management core supporting work°ow which operates in parallel to the other core work°ows and across each iteration work°ow. In addition, the actual depth of support for project management is limited. And use of non-standard 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 (1998), there are many areas in RUP which show de¯ciencies from a project management viewpoint. Ambler (1999) identi¯es a number of weaknesses in RUP's support for project management: ² the neglect of several aspects of the larger scale management issues, especially maintenance and support ² the omission of any support for reuse and cross-project capability ² the over-dependence on existing tools (of the vendor) leads to neglect of areas that cannot be automated ² weakness in areas such as metrics management, reuse management, people management and testing while applauding ² the use of sound SE principles focussing on iterative, incremental and architecture based development approaches ² the linking of prototypes linked to ends of iterations providing the ability to make go/no go decisions ² the serious investment in software tool support (RUP is after all a tool/product itself) Cost estimation is discussed in detail by Cantor (1998) although his emphasis is on what needs to be done rather than how it is to be achieved. He outlines elements of budget 6

tracking techniques and recommends the use of the COCOMO family of models for sizing OO projects. Nevertheless, this is still signi¯cantly more support than that described by Kruchten (1999a). In RUP's Project Management Work°ow, there are three key purposes: the provision of a framework for managing software-intensive projects (in other words, only relevant to the process lifecycle of software development); provision of guidelines for planning, sta±ng, executing and monitoring projects; and provision of a risk management framework. Speci¯cally, RUP is said not to cover management issues such as managing people, managing budgets, and managing contracts. This Work°ow 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 Kruchten (1999a, p112/113) about how to go about avoiding, transferring or accepting risk (either by mitigation or by de¯ning a contingency plan). Metrics are also discussed in passing with little detail | there is, for instance, no mention of the Goal{Question{Metric paradigm of Basili and Rombach (1988) or, at the other extreme, of detailed complexity metrics such as those described in, for example, Henderson-Sellers (1996). In contrast, OPEN has a large number of tasks and techniques devoted to quality, cost estimation, design and code metrics. There is signi¯cant research backing to the metrics, primarily from the work of Henderson-Sellers (1995, 1996), Graham (1995), Haynes and Henderson-Sellers (1996) and Henderson-Sellers et al. (1996). OPEN also o®ers support for projects that are not \green¯eld" projects (a restriction apparent in RUP) by its support for enhancements to existing software in the form of repeated applications of the product lifecycle, its support of programmes of projects which span several software developments including tasks and techniques focussing on reuse, domain analysis and programme-level resource allocation, as well as on people issues such as team building and organizational r^oles. Reuse is supported not only \with reuse" but also, importantly, \for reuse". Here, strategies to inculcate reuse as a mindset and part of the organizational culture are important. Consequently, as component-oriented development emerges into the mainstream, OPEN will o®er full support4 for component reuse by aggregative \plug-and-play" techniques, including cost estimation techniques of the value of reuse. OPEN has a metamodel focus on interfaces as distinct from implementations, critical for component design and, at the design level, fully supports the use of patterns and frameworks. Finally, as noted above, the degree of tailorability in these two processes is vastly di®erent. In particular, should new demands be placed on project management such that a new work°ow (in RUP terminology) or a new Activity (in OPEN and standard PM terminology) be required, then this would be virtually impossible in RUP (because of the tight constraints to the toolset etc.) and extremely easy in OPEN (this eventuality was always considered throughout the gestation period of OPEN). Furthermore, the insistence 4

The existing strong support for component development will be strengthened by the results from a project to incorporate component development ideas from Catalysis into OPEN: Wills and Graham, 1999.

7

by Jacobson that an OO process must be use-case-driven, creates some di±culties in integrating ideas of Royce (1998) and others who contemplate a rise in the interest (and necessity for) architecture-driven thinking. 4. Summary and Conclusions Currently both RUP and OPEN need further development to be able to o®er clean support for a di®erentiation between the business-focussed product lifecycle and the softwarefocussed process lifecycle. Indeed, the extent to which RUP o®ers any support for business issues has been demonstrated to be arguable. RUP's project management support occurs in an independent work°ow that is inadequately described in the published description of RUP. Fuller, associated project management support, although not part of RUP, can be found in the book by Royce (1998). In OPEN, project management tasks and techniques are extensive and fully described in publications. Furthermore, the degree to which these tasks and techniques can be selected and con¯gurated within OPEN o®ers a more °exible and extensible framework which the project manager can readily tailor to suit his/her individual project management strategies and/or style. 5. Acknowledgements This is Contribution no 99/14 of the Centre for Object Technology Applications and Research (COTAR). References Ambler, S., 1999, Completing the Uni¯ed Process with process patterns, white paper available at http://www.ambysoft.com/uni¯edProcess.html Basili, V.R. and Rombach, H.D., 1988, The TAME project: towards improvementorientated software environments, IEEE Trans. Software Eng., 14(6), 758{ 773 Booch, G., Rumbaugh, J. and Jacobson, I., 1999, The Uni¯ed Modeling Language User Guide, Addison-Wesley, Reading, MA, USA, 482pp Cantor, M., 1998, Object-Oriented Project Management with UML, John Wiley & Sons, Inc., New York, 343pp Du¶e, R.T. and Henderson-Sellers, B., 1995, The changing paradigm for object project management, Object Magazine, 5(4), 54{60, 78 Goldberg, A. and Rubin, K.S., 1995, Succeeding with Objects. Decision Frameworks for Project Management, Addison-Wesley, Reading, MA, 542pp Graham, I.M., 1995, Migrating to Object Technology, Addison{Wesley, Wokingham Graham, I., Henderson-Sellers, B. and Younessi, H., 1997, The OPEN Process Speci¯cation, Addison Wesley Longman Ltd., London, UK, 314pp Haynes, P. and Henderson-Sellers, B., 1996, Cost estimation of OO projects: empirical observations, practical applications, American Programmer, 9(7), 35{41 8

Henderson-Sellers, B., 1995, The goals of an OO metrics programme, Object Magazine, 5(6), 72{79, 95 Henderson-Sellers, B., 1996, Object-Oriented Metrics. Measures of Complexity Prentice Hall, NJ, 234pp Henderson-Sellers, B., 1999, A methodological metamodel of process, JOOP/ROAD, 11(9), 56{58, 63 Henderson-Sellers, B. and Edwards, J.M., 1994, BOOKTWO of Object-Oriented Knowledge: The Working Object, Prentice-Hall, Sydney, 594pp Henderson-Sellers, B. and Mellor, S., 1999, Tailoring process-focussed OO methods, JOOP/ROAD, 12(4), 40{44, 59 Henderson-Sellers, B., Constantine, L.L. and Graham, I.M., 1996, Coupling and cohesion (towards a valid metrics suite for object-oriented analysis and design), ObjectOriented Systems, 3, 143{158 Henderson-Sellers, B., Simons, A.J.H. and Younessi, H., 1998, The OPEN Toolbox of Techniques, Addison Wesley Longman, Ltd., UK, 426pp + CD Jacobson, I., 1998, The uni¯ed process, keynote presentation at EDOC'98 Jacobson, I., Booch, G. and Rumbaugh, J., 1999, The Uni¯ed Software Development Process, Addison Wesley Longman Inc., Reading, MA, USA, 463pp Kruchten, Ph., 1999a, The Rational Uni¯ed Process. An Introduction, Addison Wesley Longman Inc., Reading, MA, USA, 255pp Kruchten, Ph., 1999b, personal communication Royce, W., 1998, Software Project Management. A Uni¯ed Framework, Addison-Wesley, Reading, MA, USA, 406pp Wills, A.C. and Graham, I., 1999, paper in preparation

9

Figure Legends Figure 1 The tailorability axis showing fully pre-tailored methods at the right hand side and fully tailorable methods at the left hand side (after Henderson-Sellers c and Mellor, 1999) °SIGS

Figure 2 Product and process lifecycle with embedded fountain model, derived from the MOSES lifecycle architecture Figure 3 OPEN's contract-driven lifecycle instantiated from the OPEN metamodel/framework for MIS applications (Graham et al., 1997, p46) with RUP Phases superimposed c Figure 4 Work°ows within the RUP process (after Kruchten, 1999a) °AWL Figure 5 RUP's lifecycle model with OPEN's Stages superimposed

10