View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 181 Identifying Extensions Required by RUP(Rational Unified Process) to Comply with CMM (Capability Maturity Model) Levels 2 and 3 Lisandra V. Manzoni and Roberto T. Price, Member, IEEE Abstract—This paper describes an assessment of the Rational Unified Process (RUP) based on the Capability Maturity Model (CMM). For each key practice (KP) identified in each key process area (KPA) of CMM levels 2 and 3, the Rational Unified Process was assessed to determine whether it satisfied the KP or not. For each KPA, the percentage of the key practices supported was calculated, and the results were tabulated. The report includes considerations about the coverage of each key process area, describing the highlights of the Rational Unified Process regarding its support for CMM levels 2 and 3, and suggests where an organization using it will need to complement it to conform to CMM. The assessment resulted in the elaboration of proposals to enhance the Rational Unified Process in order to satisfy the key process areas of CMM. Some of these are briefly described in this article. Index Terms—Capability Maturity Model, CMM, process assessment model, Rational Unified Process, RUP, software process, software quality, Unified Modeling Language, UML. æ1 INTRODUCTIONR ESEARCHERS and practitioners have realized that processes cannot be defined and “frozen” once andfor all . Processes need to undergo changes and the CMM concept to multiple disciplines, such as systems engineering, software engineering, integrated product and process development, and supplier sourcing.refinements continuously in order to increase their ability The Rational Unified Process (RUP)  is a softwareto deal with the requirements and expectations of all engineering process that provides a disciplined approachstakeholders, i.e., processes need to be continuously to the assignment of tasks and responsibilities within aassessed and improved . development organization . Its goal is to ensure the These observations have motivated the creation of production of high-quality software that meets the needsquality models and standards for software process im- of its end users within a predictable schedule and budgetprovement , , , , , , . One of the first , .and best known is the Capability Maturity Model (CMM) RUP uses the Unified Modeling Language (UML)  tofrom the Carnegie Mellon University Software Engineering model the software and describes how to apply bestInstitute (CMU/SEI) , , . practices of software engineering via guidelines, templates, CMM provides a guide for selecting process improve- and tool mentors for all critical software lifecycle activities.ment strategies by facilitating the determination of current Within the growing number of text-books and articles onprocess capabilities and the identification of the issues most RUP, one finds descriptions such as “RUP is a softwarecritical to software quality and process improvement . engineering process” , “RUP is a process framework” , “RUP is a process and a process framework” , andThe first version of CMM was released in 1991 while the “RUP serves as the organization-wide process.”  Bothlatest version (SW-CMM version 1.1), available at the SEI “process” as well as “process-framework” are seen at thesite, dates from 1993 . CMM version 1.1 was used for same level in the metalevel hierarchy, the difference beingthis assessment. The Capability Maturity Model has that framework expresses the complete set of RUP activitiesevolved to Capability Maturity Model Integration (CMMI) from which a project-specific process or organization-wide, which enables the continued growth and expansion of process can be configured (essentially a tailored subset of RUP) , .. L.V. Manzoni is with the Servico Federal de Processamento de Dados ¸ Being a development process, it is possible to assess RUP (SERPRO), RS, Brazil, and PhD student in computer science at the with respect to a reference model for process improvement Universidade Federal do Rio Grande do Sul (UFRGS), RS, Brazil. such as CMM. This article describes such an applied E-mail: firstname.lastname@example.org, email@example.com. ´tica at the Universidade Federal assessment to RUP seen as a process framework. RUP is a. R.T. Price is with the Instituto de Informa do Rio Grande do Sul and with TeleNova Comms, 100 North Biscayne proprietary product, sold as a CD or website access , Boulevard Suite 2905, Miami, Florida 33132. which is essentially a hyperlink book. This paper refers to E-mail: firstname.lastname@example.org, email@example.com. release 2001.03.00 of this product.Manuscript received 12 Nov. 2001; revised 26 Aug. 2002; accepted 16 Sept. The option for CMM is because it is one of the best2002. known models of software process maturity , . ItRecommended for acceptance by M. Shepperd.For information on obtaining reprints of this article, please send e-mail to: shows a detailed structure of software firstname.lastname@example.org, and reference IEEECS Log Number 115357. process improvement and its practical usability has been 0098-5589/03/$17.00 ß 2003 IEEE Published by the IEEE Computer Society
182 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003proven by several assessment cases . CMM describes a because they have precisely quantifiable values, but ratherprocess model that aims at helping an organization reach because successful organizations commonly use them inprocess maturity, besides being specific for software industry , . These best practices are to developdevelopment, and strongly emphasizing aspects of contin- software iteratively, to manage requirements, to useuous improvement . component-based architecture, to model software visually, The assessment was based on the key practices described to verify software quality, and to control changes toby the Technical Report CMM/SEI-93-TR-025 Key Practices software.of the Capability Maturity Model . For each key practice The software lifecycle is based on four phases, throughidentified in this report, RUP was assessed to determine which the project evolves linearly in time. The phases are:whether it describes elements that implement key practices Inception Phase, Elaboration Phase, Construction Phase,or not. A key practice is considered RUP-supported when a and Transaction Phase . Each of these phases issubstantial part (> 75 percent) of its subpractices are composed of one or more iterations. Each iteration followsestablished. a waterfall pattern containing requirement elicitation, This paper analyzes the Rational Unified Process by analysis, design, implementation, test, and deploymentdescribing what it offers to support of CMM related , , and results in a release (either internal or external)activities and how and by identifying which aspects will of an executable product, which grows incrementally fromrequire an organization using it to develop efforts to iteration to iteration to become the final system , .complement RUP to conform to CMM levels 2 and 3. Emphasis on these activities changes in different iterations The result of the assessment is useful for organizations and on different phases.that use the Rational Unified Process because it highlights A model process describes who does what, how, andwhere RUP supports the implementation of the quality when . The Rational Unified Process is represented withpractices recommended by CMM, and where the process the use of four primary modeling elements, which arehas to be enhanced to conform to CMM. The evaluation can workers, activities, artifacts, and workflows .also assist process engineers in the customization of RUP A worker defines the behavior and responsibilities of anfor specific projects, making it possible for an organization individual or a group of individuals working as a team.to deploy a subset of RUP, according to the key process Workers represent a role played by individuals on a project,areas it desires to reach. and define how they carry out their work. Workers have The paper is outlined as follows: Section 2 briefly activities, which define the work they perform. An activitydescribes the Rational Unified Process. Section 3 shortly is something a worker does that provides a meaningfulintroduces the structure of the Capability Maturity Model. result in the context of the project.Section 4 describes the assessment conducted on RUP based Activities have input and output artifacts. An artifact is aon CMM, including the assessment process, a brief work product of the process; workers use artifacts toexplanation of how RUP satisfies each key process area of perform activities, and produce artifacts in the execution oflevels 2 (repeatable process) and 3 (defined process), the activities. Artifacts are pieces of information that aresummary of the results of the assessment. Finally, it produced, modified, or used by a process.describes some proposals to extend RUP. Section 5 Core workflows, in the Rational Unified Process,mentions some related work and Section 6 concludes with represent a partitioning of workers and activities intoobservations regarding the results of the assessment and logical groupings called areas of concern or disciplinesextensions needed by RUP to support all of CMM . The core process workflows are grouped into sixrecommended key practices. engineering workflows: Business Modeling, Requirements, Analysis and Design, Implementation, Test, and Deploy- ment; and three supporting workflows: Project Manage-2 THE RATIONAL UNIFIED PROCESS ment, Configuration and Change Management, andThe Rational Unified Process is a software development Environment .process that describes the set of activities needed totransform user requirements into a software system.However, the Rational Unified Process is more than a 3 CAPABILITY MATURITY MODELsingle process; it is claimed to be a generic process The Capability Maturity Model for Software (CMM orframework that can be specialized for a large class of SW-CMM), developed by the Software Engineeringsoftware systems, for different application areas, different Institute (SEI), defines a five-level framework of how antypes of organizations, different competence levels, and organization matures its software development processdifferent project sizes . . CMM can be used for software process improvement, RUP is a disciplined approach to assign and manage software process assessments, and software capabilitytasks and responsibilities in a development organization. evaluations , .The goal of this process is to produce, within a predictable In the following lines the structure of CMM is brieflyschedule and budget, high-quality software that meets the described , .needs of its end users . CMM is composed of five maturity levels. A maturity The Rational Unified Process shows how a software level is a well-defined evolutionary plateau towardsdevelopment team can apply commercially proven ap- achieving a mature software process . The maturityproaches to software development . These so-called level of an organization software process indicates its“best practices,” were selected by RUP designers not process capabilities. The five levels are the following:
MANZONI AND PRICE: IDENTIFYING EXTENSIONS REQUIRED BY RUP (RATIONAL UNIFIED PROCESS) TO COMPLY WITH CMM... 183 TABLE 1 organizations using them. The five common features are Key Process Areas for Each Maturity Level listed below : . Commitment to Perform describes the actions that the organization must take to ensure that the process is established and will endure. It involves establish- ing organizational policies and senior management sponsorship. . Ability to Perform describes the preconditions that must exist in the project or organization to imple- ment the software process competently. It involves resources, organizational structures, and training. . Activities Performed describes the roles and proce- dures necessary to implement a key process area. It involves establishing plans and procedures, per- forming the work, tracking it, and taking corrective actions as necessary. . Measurement and Analysis describes the need to measure the process, ways to do it and to analyze the measurements. It includes examples of measure- ments that could be taken to determine the status and effectiveness of the Activities Performed. . Verifying Implementation describes the steps to ensure that the activities are performed in compli- ance with the process that has been established. It . Initial. The software process is characterized as ad involves reviews and audits by management and hoc and occasionally even chaotic. Few processes are software quality assurance. defined and success depends on individual effort The practices in the common feature Activities Per- and heroics. formed describe what must be implemented to establish a . Repeatable. Basic project management processes are process capability. The other practices, taken as a whole, established to track cost, schedule, and functionality. form the basis through which an organization can institu- The necessary process discipline is in place to repeat tionalize the practices described in the Activities Performed earlier successes on projects with similar applications. common feature . . Defined. Management and engineering activities are The key practices of CMM were used for this assessment documented, standardized, and integrated into a because they state the fundamental policies, procedures, family of standard software processes for the and activities for the key process area . The assessment organization. Projects use a tailored version of the was conducted by analyzing each of the 229 key practices standard software processes of the organization for described within the 13 key process areas of CMM levels 2 developing and maintaining software. and 3. . Managed. Detailed measures of the software process Due to the large number of key practices, the summary and product quality are collected. Software pro- identifying how RUP satisfies CMM, described in Section 4, cesses and products are quantitatively understood is shown in groups of key process areas. A master’s and controlled. dissertation, available in its current Portuguese version at . Optimizing. Continuous process improvement is http://www.inf.ufrgs.br/amadeus/atuais/lisandra.html, facilitated by quantitative feedback from the process has a detailed description of how RUP supports each CMM and from piloting innovative ideas and technologies. key practice (or why not) . With the exception of level 1, each maturity level iscomposed of several key process areas. Each key processarea identifies a cluster of related activities (key practices) 4 USING CMM TO ASSESS RUPthat, when performed collectively, achieve a set of goals Defining their own software process and assessing andconsidered important for establishing the process capability improving it has been a matter of concern to manyat that maturity level. Table 1 shows the key process areas organizations that develop software, as demonstrated byfor each maturity level. the number of models of process assessment available , Each key process area is described in terms of key illustrated by models such as CMM , , Bootstrap ,practices that, when implemented, help to satisfy its goals. Trillium  and SQUID ; and the standardization effortsThe key practices in each key process area are organized by as the norms ISO9000-3 , ISO12207 , and ISO15504a set of common features. The common features are (or SPICE) .attributes that indicate whether the implementation and The key practices of CMM are expressed in terms ofinstitutionalization of a key process area are effective, what is expected to be the normal practice of organizationsrepeatable, and lasting. The common features also group that work on large government contracts. It is an SEIand order the key practices in a sequence that is helpful for recommendation that, in any context in which CMM is
184 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003applied, a reasonable interpretation of how the practices listed beneath the top-level key practices and describe whatshould be applied must be used . Technical Report one would expect to find implemented for the top-level keyCMM/SEI-94-TR-024  contains guidelines on interpret- practice .ing CMM. The CMM key practices not supported by RUP were also This paper summarizes the assessment conducted by the identified. Any organization using RUP and aiming atauthors to identify the RUP-provided support to organiza- CMM must look for alternatives to satisfy them.tions that want to reach CMM maturity levels 2 and 3. The For every key process area, a percentage of key practicesobjective of the assessment is to identify how RUP satisfies satisfied was calculated. The analysis also considered theCMM key practices, and to identify practices not supported key practices grouped by common features.by RUP. The practices not supported by RUP are of great The following section briefly describes how the Rationalconcern, as the organization should achieve them by others Unified Process supports each key process area (KPA) ofmeans. CMM levels 2 and 3. This is done by stating how the The assessment used the key practices described by elements described in RUP, such as workflows, activities,Technical Report CMM/SEI-93-TR-025 “Key Practices of workers, and artifacts, support each CMM key process area.the Capability Maturity Model” , Version 1.1 and the 4.2 Level 2—Repeatable ProcessRational Unified Process 2001.03.00, distributed by RationalCorporation . KPA: Requirements Management. The Requirements Work- The assessment was based on guidelines on how to flow of RUP describes the sequence of activities that must be carried out to manage the requirements of the system and tointerpret the model, identifying in RUP the elements execute changes to these requirements.described by CMM, regardless of the names used, matching The requirements of the system are documented in thethose in RUP that fulfilled the proposed objectives of those artifact Software Requirements Specification, which consists ofin CMM. For example, the common feature of CMM a package containing Use Cases of the Use Case Model andVerifying Implementation contains practices that detail the applicable Supplementary Specifications, and the nontechnicalreview of activities by senior managers, while in RUP this requirements are documented in the artifacts Stakeholderactivity is executed by the Project Reviewer. The objective is Requests and Vision. RUP describes the measures related tofulfilled, despite the use of different names for the activities the requirements in the artifact Measurement Plan. Theand the roles of the workers that perform them. artifact Requirements Attributes contains a repository of In this assessment, all key practices of levels 2 and 3 are project requirements, attributes, and dependencies to trackconsidered applicable. For some organizations or projects, the requirements.some key practices may not be applicable; in which case, the The worker Change Control Manager is responsible forparticular recommendations that follow from the assess- approving and revising the change proposals in thement may be ignored. For example, all key practices of requirements. The Requirements Reviewer plans and con-Subcontract Management may be ignored if the organiza- ducts the formal review of software requirements. Thetion does not practice any sort of outsourcing. The System Analyst leads and coordinates requirements elicita-assessment process is sketched in the next section. tion and use-case modeling.4.1 The Assessment Process KPA: Software Project Planning. The Project Manage- ment Workflow of RUP describes the activities to manageThe assessment process followed a precise routine. For each software projects, such as: Develop Software Developmentkey practice identified in the CMM report, the Rational Plan, Plan Phases and Iterations, Project Planning Review, andUnified Process was assessed to determine whether it Define Monitoring and Control Processes. RUP proposes ansatisfied it or not. A CMM key practice is considered to be iterative and incremental lifecycle.satisfied if there is a set of activities, artifacts, workers, or Artifact Software Development Plan (SDP) describes theworkflows in RUP to implement it. planning of the project; Vision describes the general vision For example, CMM describes the following key practice: of the requirements of the design. Business Case describes anThe software engineering group uses the allocated require- economic analysis of the project. Risk Management Planments1 as the basis for software plans, work products, and details how to manage the risks associated with the project.activities. Development Case describes the infrastructure plans and RUP satisfies this key practice because its Requirements tools. Status Assessment provides a mechanism for addres-Workflow describes a systematic approach to find, docu- sing, communicating, and resolving management issues,ment, organize, and manage changes in software require- technical issues, and project risks. The project data arements. Software requirements are documented by means of stored in artifact Project Measurements.Use Cases, and the Use Cases are used as the basic element Project Manager is responsible for negotiating commit-for planning and monitoring the project. ments and developing the SDP. The Project Reviewer is In this assessment, a key practice is considered sup- responsible for evaluating project planning and projectported when a substantial part (>75 percent) of the assessment artifacts.subpractices associated with it are established by RUP. KPA: Software Project Tracking and Oversight. ProjectSubpractices, also known as subordinate key practices, are Management Workflow describes the activities that must be executed to tracking and oversight of the project, such as 1. The system requirements allocated to the software, usually referred toas the "allocated requirements" in CMM, are the subset of the system Monitor and Control Project, Project Planning Review, and torequirements that the software components of the system implement. perform formal reviews at the end of each phase (major
MANZONI AND PRICE: IDENTIFYING EXTENSIONS REQUIRED BY RUP (RATIONAL UNIFIED PROCESS) TO COMPLY WITH CMM... 185milestones). Monitor and Control Project has the main purpose Process Engineer is responsible for defining the softwareof continuously monitoring the project in terms of active development process for each project.risks and objective measurements of progress and quality. RUP does not describe how the improvements identified Project Manager is responsible for negotiating commit- at the process evaluation are implemented, neither does itments to develop the SDP and to accomplish the project. include information about how to elaborate or review plans, Iteration Plan describes a time-sequenced set of activities as is proposed in CMM.and tasks, with assigned resources, containing task depen- KPA: Organization Process Definition. RUP proposesdencies for every iteration. Risk List enumerates known in Environment Workflow the activities and the guidelines torisks associated with specific mitigation or contingency. The configure the Rational Unified Process for a standardproject accomplishment data are stored in the artifact Project process of the organization and to configure the organiza-Measurements. tion’s standard process for a specific project. In many cases, KPA: Software Subcontract Management. RUP does not the Rational Unified Process serves as the organization-support this key process area. wide process. KPA: Software Quality Assurance. RUP proposes the Development Case describes the configured developmentelaboration of a Quality Assurance Plan for each project. This process for a given project. Organization’s software processplan provides a clear view of how product, artifact, and must be registered in a site, allowing access to all the staffprocess quality are to be assured. organization. The procedure to develop this plan is described in the Software Engineering Process Authority has the function toactivity Develop Quality Assurance Plan of the Project develop and to maintain the organization’s process standard.Management Workflow. RUP recommends that the Software Engineering Process The Process Engineer is responsible for the software develop-Authority (SEPA) should have responsibility for the process ment process itself, and to develop the Development Case.aspects of quality and perform process reviews and audits, The activities to define the process are scheduled in theas well as ensuring proper planning and conduct of the Software Development Plan and they are accomplished in thereview events described in the Review and Audit section of activity Monitor Project Status of the Project Managementthe Quality Assurance Plan. Workflow. RUP is not clear about how to deal with the problems KPA: Training Program. RUP does not support this keyidentified in the reviews and audits, neither does it state process area.how the results of these reviews are communicated to the KPA: Integrated Software Management. The Environ-Software Engineering Group or to the workers. ment Workflow specifies how to configure the organization’s KPA: Software Configuration Management. The Con- software process to a specific project. This configuredfiguration and Change Management Workflow describes activ- process is described in the artifact Development Case andities to manage configuration and to control change, such as must be used to plan and to manage the project.Establish Configuration Management Policies, Establish Change The activity Project Planning Review has the purpose ofControl Process, Write Configuration Management Plan, Man- reviewing the Software Development Plan and the Develop-age Baselines and Releases, Perform Configuration Audit and ment Case.Monitor, and Report Configuration Status. The data of the repository Project Measurements are used Configuration Management Plan describes all Configura- in the activities: Monitor Project Status and Report Status. Intion and Change Control Management (CCM) activities that the Plan Phases and Iterations activity, RUP suggests that thewill be performed during the course of the product or collected data be used in future estimates.project lifecycle. The major milestones serve to review the state of the Change Control Manager reviews submitted change project at the end of a phase and determine whether therequests to determine if it is a valid request or not. project should proceed to the next phase.Configuration Manager provides the overall Configuration Risk Management Plan specifies how to manage the risksManagement (CM) infrastructure and environment to the associated with a project, and Risk List identifies projectproduct development team. He is responsible for writing risks, associating them with specific mitigation or con-CM Plan and reporting progress statistics based on change tingency actions.requests. Integrator combines components to produce a KPA: Software Product Engineering. Software engineer-build. ing activities are described in the Rational Unified Process,4.3 Level 3—Defined Process through six process workflows, Business Modeling, Require-KPA: Organization Process Focus. The activity Assess ments, Analysis and Design, Implementation, Test, and Deploy-Current Organization in Environment Workflow describes the ment; and three support workflows, Configuration andcurrent status of the software organization in terms of its Change Management, Project Management, and Environment.current process, tools, staff abilities and attitudes, custo- RUP describes the relationships between the workflows andmers, competitors, technical trends, problems, and im- between the activities of each workflow. For each activity,provement areas. RUP also describes the related artifacts and the workers Software Engineering Process Authority (SEPA) facilitates responsible for the activity.the exchange of information and provides process guidance KPA: Intergroup Coordination. RUP describes the soft-both to and from project practitioners, maintaining a ware engineering group and other engineering groups ascurrent assessment of the organization’s process maturity. workers of the process that relate with one another by means
186 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 TABLE 2 practices not supported by RUP. Table 4 shows how the keyCMM Key Practices Coverage for RUP by Key Process Areas practices supported are distributed through the five common features (Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, Verifying Implementation). Table 5 shows that, excluding the key practices of the common feature Ability to Perform, this key process area supports all eight key practices. 4.4.1 Key Practices Coverage Table 2 shows that RUP establishes procedures that satisfy almost all the key practices described by CMM to the key process areas Requirements Management, Software Project Planning, Software Project Tracking and Oversight, Software Configuration Management, Organization Process Definition, and Software Product Engineering. In general, the missing key practices result from RUP neither describing how adequate human resources and funding are provided to carry out the process activities, nor ensuring that the development workers are trained to perform their activities. The Requirements core workflow in RUP describes a sequence of activities that must be carried through to manage the software requirements and to provide changesof the artifacts that they produce and of the activities that in these requirements.they execute. The activities related to the Software Project Planning and Software Development Plan describes all the activities Software Project Tracking and Oversight are described in therelated to the software project. Project Manager has the Project Management Workflow.responsibility to manage critical dependencies between the RUP is limited to the planning of the software project,activities. Reviews and audits are held at some points of the not describing the relationships of the software project withdevelopment process. Software Engineering Process Authority the overall project. Overall project planning involves thehas the purpose of facilitating the exchange of information activities executed by other groups, as network infrastruc-between the participants of the process. ture, hardware, marketing, etc. RUP does not describe how It is not clear in RUP how the activities and commitments to identify, estimate, and track critical computer resourcesat the system level are coordinated. such as: computer memory capacity, computer processor KPA: Peer Reviews. The reviews that will be held at the usage, and communication channels capacity, etc.project are described in the Review and Audit Plan contained In the Configuration and Change Management Work-in the Quality Assurance Plan. Associated to the plan are flow, the activities related to the key process area Softwareguides on how to carry out reviews. Configuration Management (SCM) are described. Review Record elaborated at the end of each review Organization Process Definition involves developing andcaptures the results of the review of a project artifact, maintaining the standard software process of the organiza-including review result, defects or problems identified, tion, along with related process assets, such as descriptionschedule, participants, etc. of software life cycles, process tailoring guidelines and criteria, and the support documents . RUP describes4.4 Results of the Assessment guidelines to customize the Rational Unified Process for theThe results of the assessment are described in Tables 2, 3, 4, process standard of the organization, considering theand 5. Table 2 shows the coverage of the CMM key practices application domain, reuse practices, and core technologiesby RUP, expressed in percentage of key practices, grouped mastered by the user organization. In the Environmentby key process areas. Table 3 lists the missing or incomplete Workflow, these guidelines to customize and to maintainkey practices. Table 4 shows the percentage of key practices the process are described.satisfied by common features in each key process area. Software Product Engineering describes the engineeringTable 5 shows the percentage of key practices supported by tasks to build and to maintain the software. In RUP, theseCMM, ignoring the common feature Ability to Perform. This activities are described, mainly, in the process workflows:common feature is eliminated because it describes the Business Modeling, Requirements, Analysis and Design,preconditions that must exist in the project or organization, Implementation, Test, and Deployment.such as resources, organizational structures, and training; RUP offers a good support to the key process areaissues considered beyond the scope of RUP. Integrated Software Management, and Intergroup Coordination. For example, the key process area Requirements Manage- In these cases, it satisfies almost 70 percent of CMM-ment recommends 12 key practices that are divided among recommended key practices. Integrated Software Managementfive common features. Table 2 shows that 10 of the 12 key describes how to use the standard software process,practices are supported. Table 3 explicitly shows those key developed in the key process area Organization Process
MANZONI AND PRICE: IDENTIFYING EXTENSIONS REQUIRED BY RUP (RATIONAL UNIFIED PROCESS) TO COMPLY WITH CMM... 187 TABLE 3 Missing or Incomplete CMM Key PracticesDefinition, in order to create a specific process for a project. Rational Unified Process itself), for a specific project, andRUP describes, in the Environment Workflow, procedures how this process must be documented in the Developmentto customize the process for an organization (it can be the Case. Intergroup Coordination involves establishing means
188 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 TABLE 4 TABLE 5 Percentage of Key Practices Satisfied by RUP, CMM Key Practices Coverage for RUP by Key Process Areas Organized by Common Features areas in terms of common features and to identify the common features that are not supported by the key process areas. The common features are Commitment to Perform (CM),for the workers of a project to participate actively in the Ability to Perform (AB), Activities Performed (AC), Measure-development of a system. ment and Analysis (MA), and Verifying Implementation (VI). RUP offers poor support in a number of key practices for The common features are briefly described in Section 3.the key process areas Software Quality Assurance, Organiza- Table 4 shows the low percentage achieved by thetion Process Focus, and Peer Reviews. common feature Ability to Perform in support of all key In RUP, version 2001.00.03, a number of activities to practices. The common feature Ability to Perform involvesensure project quality have been added, including the resources, organizational structure, and training.elaboration of a Quality Assurance Plan. However, there are Table 4 highlights that RUP focuses on software projecta number of gaps in handling the problems detected in management and software building processes, but it is notreviews and audits, and in reporting the results to the so keen on aspects related to systems management, such asproject team. RUP does not describe how measurements are cost management, training, human resource management,made to determine cost and schedule status of the SQA communications management, and procurement manage-activities. ment, i.e., the precondition activities described by the RUP proposes that the current status of the organization common feature Ability to Perform. This is very naturalshould be described in the activity Assess Current and perfectly understandable because RUP evolves fromOrganization, mainly with respect to its current process the unification of methods for software development ,and improvement areas. However, RUP does not describe , , and not from project management processes.how the identified improvements are implemented, co- Nevertheless, those indices show the need to examine theordinated, or accomplished, including the development of missing practices carefully.improvement plans and the review of these plans, as CMM RUP describes the purpose of Project Managementrecommends; that explains the low coverage percentage Workflow as the provision of a framework for managingreached in the key process area Organization Process Focus. software-intensive projects, the provision of practical guide- The key process areas Subcontract Management and lines for planning, staffing, executing, and monitoringTraining Program are not supported at all by the Rational projects, and the provision of a framework for managingUnified Process. RUP considers these key process areas risk . It is said that RUP does not attempt to cover allorganizational responsibilities that are beyond the scope of aspects of project management and that it does not coverthe software process  and, therefore, need to be issues such as managing people, managing budget, andsupported through other means by the organization. In managing contracts .the analyses presented in Tables 4 and 5, therefore, key RUP suggests that procedures to satisfy these issues areprocess areas Software Subcontract Management and Training out of its scope and must be defined by the organizationProgram will be left out. . The organization could use a specific approach for project management to complement RUP , such as the4.4.2 Key Practices Organized by Common Features Project Management Institute’s Project Management BodyIn Table 4, the key practices are organized by common of Knowledge (PMBOK) . PMBOK identifies specificfeatures in each key process area. The objective is to knowledge areas to treat human resources management,describe the percentage of key practices by key process procurement management, integration management, and
MANZONI AND PRICE: IDENTIFYING EXTENSIONS REQUIRED BY RUP (RATIONAL UNIFIED PROCESS) TO COMPLY WITH CMM... 189other management issues. Other authors examined RUPfrom a project management viewpoint , , . Table 5 shows the percentages of key practices supportedby key process area, eliminating practices described in thecommon feature Ability to Perform. This common featurewas eliminated considering that the organizational pre-conditions are beyond the scope of RUP. Analysis of this table shows that, when excluding the keypractices of CMM described in the common feature Abilityto Perform, the percentages supported by RUP in each keyprocess area substantially increase, reaching 100 percent inmany key process areas. The key process area Peer Review, which had apercentage of 67 percent in Table 2, has its percentage risento 100 percent in Table 5. This is because this KPA has ninekey practices and three of them are related to preconditions(training and people) that are not considered in RUP. The next section makes some propositions to extend theRational Unified Process to conform to CMM.4.4.3 Some Propositions to Conform to CMM Fig. 1. Estimation and tracking of critical computer resources.With the objective of extending RUP to satisfy CMM keypractices, some proposals are suggested. These proposals critical computer resources are managed according to a docu-describe the inclusion/alteration of activities, inclusion/ mented procedure.”alteration of artifacts, inclusion of workflows, and inclusion In order to estimate the critical resources, this procedureof workers or groups of workers. must use the historical information of similar projects. The Regarding activities, the propositions are to create estimated critical computer resources must be documented atactivities to estimate resources and funds, to estimate and track the software development plan. Identified risks must becritical computational resources, to define activities that must be associated to critical computer resources in the risk manage-executed by software quality assurance group to ensure the ment plan, to ensure that they will be monitored andsoftware process steps and standards are followed, and to improve controlled, as shown in Fig. 1.the organization’s software process. Regarding artifacts, RUP The evaluation of the critical resources must be done atshould also have documents to specify project plans, process minor and major milestones, and corrective actions must beimprovement plan, and register required resources at plans taken when risks arise in the project.developed. Finally, regarding workflow, a set of activities, Proposal 2: Definition of a new workflow: Subcontractartifacts, and workers to implement Subcontract Management Management Workflow. RUP does not show a definedand Training must be defined. process with respect to subcontract management. The aim This paper will briefly describe only two examples of of this proposal is to formalize the subcontract managementproposals. A more comprehensive set of propositions to process and to satisfy the key process area Subcontractbring RUP up to CMM levels 2 and 3 is described in Lisandra Management, through the definition of a new workflow,Manzoni’s recently presented master dissertation . called Subcontract Management Workflow. This workflow Proposal 1: New procedures to estimate and track is defined by using an activity diagram, as shown in Fig. 2.critical computer resources. In order to satisfy the key This workflow proposes the inclusion of seven newpractices Activities Performed 11/15 of the key process area activities, which are develop a subcontract management plan,Software Project Planning; Activities Performed 7/13 of the key select subcontractor, elaborate contract and define commitments,process area Software Project Tracking and Oversight, and track activities of the subcontractor, perform reviews and audits,Activities Performed 8/11 of the key process area IntegratedSoftware Management, procedures are required to estimate monitor activities configuration management, and evaluateand track critical computer resources (computer memory, artifacts developed. Included artifacts are subcontract manage-computer processor, communications channel capacity, etc.) ment plan and contract, and the worker subcontract manager.needed by the project. 4.5 To Reach CMM Levels 2 and 3 The key practice Activities Performed 11/15 of the keyprocess area Software Project Planning describes that An organization deploying RUP that desires to reach CMM“Estimates for the project’s critical computer resources are level 2 needs to define its own procedures to select and toderived according to a documented procedure.” train human resources, to manage subcontracts, to provide The key practice Activities Performed 7/13 of the key funds to the project, to estimate and to track criticalprocess area Software Project Tracking and Oversight de- computer resources for the project, and to coordinate thescribes that “The project’s critical computer resources are software project planning with the overall project planning.tracked, and corrective actions are taken as necessary.” The key It is also necessary to define how problems identified in thepractice Activities Performed 8/11 of the key process area reviews must be handled and related to the workers, whatIntegrated Software Management describes that “The project’s measurements will be made to determine status of the SQA
190 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 evaluated whether either or both would meet acceptable standards in process support, project management guide- lines, and full lifecycle description for OO software development. The authors conclude that both processes are deficient in certain standard project management areas of knowledge to be fully self-contained processes capable of supporting the full suite of project management techniques and that therefore further extensions into these subdomains would seem to be desirable. In , Hull et al. identify the best practices for software development and provide a basis for the assessment of three processes: Catalysis, OPEN, and RUP. The authors conclude that RUP is presented in a very management oriented format, whereas Catalysis is described as focusing on software engineering, while OPEN is somewhere in between the two. The level of detail of RUP is aimed at managers as opposed to software managers who would benefit more from descriptions and applications of UML. OPEN is a rich process and is documented clearly. Its level of detail is nearer that of Catalysis, being of use to both the manager and the software engineering. Catalysis is more detailed . A qualitative evaluation is performed on the public domain component of RUP and on OPEN in . TheFig. 2. Workflow of subcontract management. authors focus their comparison on aspects of the process architecture and underpinning metamodel, the concepts andactivities, and how to include reviews of all performed terminology utilized and support for project management.activities to assure software quality. The authors conclude that the metalevel architecture of RUP In order to reach CMM level 3, it is necessary to describe leads to some dilemmas in terms of the lack of support for ahow the software process of the organization can be truly iterative development and an over-reliance on use-improved, including the development of improvement cases. OPEN combines the adaptability to construct aplans and the review of these plans by senior management; process to the specific needs of an individual domain andand the organization must define procedures to identify the to adapt the process continually to particular projects. OPENtraining needed by project team members, and then offers more extensive support in the area of cross-projectdevelop or procure training to address the identified needs. suites of application developments and maintenance and it offers more extensive support in metrics and quality considerations. The authors concluded that these differences5 RELATED WORK probably reflect the more underpinning model provided byIn , an evaluation of the Rational Unified Process in developers of OPEN rather than the more pragmatic, tools-respect to standard ISO/IEC15504—Part 5 is described. focused considerations of RUP developers .Part 5 contains a detailed elaboration of mandatory In , an evaluation of how RUP meets the goals in eachprocesses and defines associated base practices, work key process area of CMM levels 2 and 3 is described. Theproducts, and management practices, which are used to difference between that evaluation and the analysisdetermine the capability for each assessed process. The reported in this paper is on focus. While  looked atreport presents a summary as a graph of ratings against 33 goals in CMM, this analysis looked into 229 key practicesprocesses grouped by category and concludes that the and their organization in common features. The Rationalratings reflect the engineering focus of RUP, which fails to white paper  addresses how an organization can usemeet the requirements of standard 15504 at higher ratings RUP to achieve CMM level 2 key practices. Some differ-in regards mainly to the management and organizational ences in conclusions between this paper and Rational Whiteareas and the quality assurance functions. Papers ,  are as follows: The Rational White Papers RUP was also assessed in regards to its conformity to ISO state that the Software Development Plan defines the9000-3 in . The authors concluded in this report that the overall plan for the project, but this plan is concerned onlyimplementation of RUP needs to be supported by com- with software planning. Some activities and work productsplementary actions to satisfy the standard because RUP required by CMM are lacking in RUP, and those papers dodoes not support several requirements of ISO 9000-3, such not address these issues clearly. Some of the missingas definition of contracts, organizational responsibilities activities involve cost management, human resourcesand policies, control of external products/services, etc. management (training), estimating critical computer In , the object-oriented processes RUP and OPEN resources, handling of problems detected in reviews and(Object-Oriented Process, Environment, and Notation) are audits, and continuous software process improvement. Thisexamined from a project management viewpoint and paper goes further, pointing to missing key practices,
MANZONI AND PRICE: IDENTIFYING EXTENSIONS REQUIRED BY RUP (RATIONAL UNIFIED PROCESS) TO COMPLY WITH CMM... 191quantifying the coverage that RUP offers by key process ACKNOWLEDGMENTSarea and suggesting extensions to missing key practices. This project was partially supported by the Brazilian Research Agency CNPq under the grant Amadeii 5228-6 SUMMARY AND CONCLUSION 2519-99/8.The assessment shows that the Rational Unified Processmeets most of the Capability Maturity Model requirements, REFERENCESbut some of the more managerial aspects of the software  ˆ A.A. Alcantara, T.M.M. Maciel, S.L. Meira, and F.Q.B. da Silva,process are not currently supported. ¸˜ “Uso do Processo RUP na Implantacao da ISO 9000-3,“ Proc. Sixth The Rational Unified Process presents a well-defined Workshop Qualidade de Software, pp. 60-71, 1999.approach on software project management and software  A. April and F. Coallier, “Trillium: Model for Telecom Productengineering processes, but it is not an approach centered on Development and Support Process Capability,“ Proc. Second IEEE Software Eng. Standards Symp., Aug. 1995.systems management concerns. Therefore, it lacks activities  J. Boegh, S. Depanfilis, B. Kitchenham, and A. Pasquini, “Ainvolving issues such as cost management, human resource Method For Software Quality Planning, Control, and Evaluation,“management, communications management, and contracts IEEE Software, vol. 16, no. 2, pp. 69-85, Mar. 1999.  G. Booch, Object-Oriented Analysis and Design with Applications,management. second ed. The Benjamin/Cummings Publishing Co., 1994. CMM key process areas better supported by RUP are  G. Booch, J. Rumbaugh, and I. Jacobson, The Unified ModelingRequirements Management, Software Project Planning, Language Users Guide. Addison Wesley, 1999.  B. Fitzgerald and T. O’Kane, “A Longitudinal Study of SoftwareSoftware Project Tracking and Oversight, Software Config- Process Improvement,“ IEEE Software, vol. 16, no. 3, pp. 37-45,uration Management, Organization Process Definition, and May 1999.Software Product Engineering. RUP offers good support to  V. Haase, G. Koch, H.J. Kugler, and P. Decrinis, “Bootstrap: Fine- Tuning Process Assessment,“ IEEE Software, vol. 11, no. 4, pp. 25-key process areas Integrated Software Management, and 35, July 1994.Intergroup Coordination. Key process areas Software  ´ B. Henderson-Sellers, R. Due, and I. Graham, “Third GenerationQuality Assurance, Organization Process Focus, and Peer OO Processes: A Critique of RUP and OPEN from a ProjectReviews show low support to the corresponding key Management Perspective,“ Proc. Seventh Asia-Pacific Software Eng. Conf. (APSEC’ 2000), pp. 428-435, 2000.practices recommended by CMM. RUP does not support  J. Herbsleb, A. Carleton, J. Rozum, J. Siegel, and D. Zubrow,key process areas Software Subcontract Management and “Benefits of CMM-Based Software Process Improvement InitialTraining. Results,” Technical Report CMM/SEI-94-TR-13, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Penn., 1994, http:// An organization aiming at CMM levels 2 and 3 must www.sei.cmu.edu/pub/documents/94.reports/pdf/tr13.94.pdf.complement RUP. It must develop its own procedures to  ISO 9000-3, “ISO 9000-3 Guidelines for the Application of ISO 9001satisfy key practices not supported by RUP, or use a to the Development, Supply, and Maintenance of Software,” Int’l Standards Organization, Geneva, 1991, http://www.iso.org/.specific project management approach to deal with human  ISO/IEC 12207, “ISO/IEC 12207 Information Technology—Soft-resource management, budget management, and contract ware Life-Cycle Processes,” Int’l Standards Organization, Geneva,management. 1995, http://www.iso.org/. This study was started at the beginning of 2000 and was  I. Jacobson, G. Booch, and J. Rumbaugh, Unified Software Development Process. Addison-Wesley, 1998.first conducted on the RUP available then (version 5.5) .  I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-RUP has considerably improved its coverage of CMM Oriented Software Engineering: A Use Case-Driven Approach. Ad-practices from version 5.5 to version 2001. From a key dison-Wesley, 1992.  P. Kruchten, The Rational Unified Process—An Introduction. Ad-process area coverage of only 35 percent (minimum) to dison-Wesley, 2000.79 percent (maximum) for CMM key practices in version 5.5,  E.G. McGuire, “Initial Effects of Software Process Improvement onit now covers 44 percent (minimum) to 86 percent an Experienced Software Development Team,“ Proc. 29th Ann. Hawaii Int’l Conf. System Sciences, pp. 713-721, 1998.(maximum) in its 2001 version. The improvements have  M. Paulk, “Effective CMM-Based Process Improvement,“ Proc.come from the emphasis the new version places on the Sixth Int’l Conf. Software Quality (ICSQ’96), pp. 226-237, 1996.definition of procedures for software quality assurance.  M. Paulk, B. Curtis, M. Chrissis, and C. Weber, “Capability Maturity Model for Software,” Version 1.1, Technical Report CMU/SEI-93-With the inclusion of software quality assurance activities, TR-24, Software Eng.Inst., Carnegie Mellon Univ., Pittsburgh, Penn.,RUP satisfies the key practices of the common features 1993, http://www.sei.cmu.edu/pub/documents/93.reports/Verifying Implementation, included in almost all key pdf/tr24.93.pdf.process areas, thus increasing the percentage of coverage  M. Paulk et al., “Key Practices of Capability Maturity Model for Software,” Version 1.1, Technical Report CMU/SEI-93-TR-25, Soft-of key practices in these KPAs. ware Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Penn., 1993, This paper identifies missing key practices and proposes http://www.sei.cmu.edu/pub/documents/93.reports/pdf/some activities and artifacts to complement RUP. The tr25.93.pdf.  CMMI Product Team, “Capability Maturity Model, Integrationauthors are working on the elaboration of templates for the (CMMI),” Version 1.1, Technical Report CMU/SEI-2002-TR-011,proposed artifacts and on guidelines to the proposed Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Penn.,activities. Mar. 2002, http://www.sei.cmu.edu/pub/documents/02.reports /pdf/02tr011.pdf. Some results described in this assessment have also been  Project Management Institute, Inc., “A Guide to the Projectevaluated by the use of the Rational Unified Process in real Management Body of Knowledge,” 2000 ed., 2000, http://projects, mainly within the Brazilian Federal Data Proces- www.pmi.org.sing Agency SERPRO. The authors would like to express  Rational Software Corporation, “Rational Unified Process,” Ver- sion 2001.3, CD-ROM, Rational Software, Cupertino, Calif.: 2001.their gratitude to the SERPRO managers that allowed  Rational Software Corporation, “Rational Unified Process,”Ver-interaction to happen. sion 5.5, CD-ROM, Rational Software, Cupertino, Calif.: 1999.
192 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 2, FEBRUARY 2003 Rational Software Corporation, “Rational Unified Process Best Lisandra V. Manzoni received the MSc degree Practices for Software Development Teams,” White Paper, 1998, in computer science from the Universidade http://www.rational.com/media/whitepapers/rup_bestpracti- Federal do Rio Grande do Sul (UFRGS) and ces.pdf. the BSc degree from the Universidade Federal Rational Software Corporation, “Assessing the Rational Unified de Santa Maria (UFSM). She is currently a PhD Process against ISO/IEC15504-5: Information Technology—Soft- student in computer science at UFRGS. She ware Process Assessment Part 5: An Assessment Model and works at Servico Federal de Processamento de ¸ Indicator Guidance,” White Paper, 2000, http://www.rational. Dados in research and software development. com/products/whitepapers/rup_iso.jsp. Her research interests are on software process, J. Rumbaugh, M.R. Blaha, W. Lorensen, F. Eddy, and W. software project management, and tools. She is Premerlani, Object-Oriented Modeling and Design. Prentice-Hall, member of the Brazilian Computing Society. 1991. ISO/IEC 15504, “Information Technology—Software Process Roberto T. Price received the PhD degree from Assessment—Part 1: Concepts and Introductory Guide,” Techni- the University of Sussex-UK (School of Engi- cal Report ISO/IEC TR 15504-1:1998, Int’l Standards Organization, neering and Applied Sciences), the MSc degree JTC 1/SC 7, 1998, http://www.iso.org/. from the University of London (LSE), and the J. Smith, “Reaching CMM Level 2 and 3 with the Rational Unified BSc degree from the Universidade Federal do Process,” White Paper, 2000, http://www.rational.com/products/ Rio Grande do Sul (Escola de Engenharia). He whitepapers/100416.jsp. is currently VP of R&D at TeleNova Commu- R.W. Reitzig, C. Rodriguez, and G. Holt, “Achieving Capability nications and also a collaborator-professor at Maturity Model Level 2 with Rational Unified Process,” Rational ´ the Instituto de Informatica at the Universidade White Paper, 2002, http://www.cognence.com/AchievingCMM- Federal do Rio Grande do Sul, where he had a Level2.pdf. career as researcher, lecturer, and academic administrator. His M.P. Ginsberg and L.H. Quinn, “Process Tailoring and the Software research interests in Software Engineering are on tools, methods, and Capability Maturity Model,” Technical Report CMU/SEI-94-TR- processes. Dr. Price is a founding member of the Brazilian Computing 024, Software Eng. Inst., Carnegie Mellon Univ., Pittsburgh, Penn. Society. He is a member of the IEEE and the IEEE Computer Society. 1995, http://www.sei.cmu.edu/pub/documents/94.reports/pdf /tr24.94.pdf. M.E.C. Hull, P.S. Taylor, J.R.P. Hanna, and R.J. Millar, “Software Development Processes—An Assessment,“ Information and Soft- . For more information on this or any computing topic, please visit ware Technology, vol. 44, no. 1, pp. 1-12, Jan. 2002. our Digital Library at http://computer.org/publications/dlib. ´ B. Henderson-Sellers, G. Collins, R. Due, and I.M. Graham, “A Qualitative Comparison of Two Processes for Object-Oriented Software Development,“ Information and Software Technology, vol. 43, no. 12, pp. 705-724, Dec. 2001. A. Fuggeta, “Software Process: A Roadmap,” Proc. 22nd Int’l Conf. Software Eng.—Future of Software Eng., pp. 25-34, 2000. L.V. Manzoni, “Using a Workflow Management System to Support Software Development Based on Extended Rational Unified Process to Reach Maturity Model Levels 2 and 3,” master dissertation, Inst. of Informatics, Federal Univ. of Rio Grande do Sul, Porto Alegre, Brazil, 2001, http://www.inf.ufrgs.br/amadeus /atuais/lisandra.html.