IBM Rational Unified Process®, or RUP®, provides an outstanding foundation that allows Unisys to achieve a higher level of process capabilities in many different CMMI process areas. Moreover, RUP allows the selection and customization of its process elements to adhere to the particularities inherent in each Unisys Global Public Sector project, program, or business unit.

However, RUP is weak in some CMMI process areas. In a comprehensive study performed by the Software Engineering Institute, RUP was assessed against CMMI Continuous Representation.² Although RUP performed well in most of the CMMI process areas, the assessment concluded that RUP was weak in the areas of Supplier Agreement Management and Technical Solution process area practices.

In this paper¹, I describe new process elements that allow RUP to overcome these weaknesses. I discuss some experiences in which RUP has been used to assist IT organizations in achieving a higher level of process capabilities, then present the software process improvement approach that we are using to guide our work. I also describe the new process elements that would be created to overcome the identified weakness related to CMMI assessment.

A philosophy of improving process

A "software process" includes all the activities necessary to manage, develop, acquire, and maintain software products or services. The existence of a defined and sustained process offers a foundation for organizational planning and continuous improvement. When software process is well-established in an organization, it serves as a vehicle for learning, reuse, and the promotion of best practices.

To improve software process quality, we must understand the organization that will benefit from the improvement. The best way to gain this understanding is by studying representative sample projects, and paying particular attention to their development, management, support, and operational practices. This helps identify points in the process that need to be improved, missing practices that need to be included, and practices used in some projects that would bring business benefits if extended to the entire organization.

To help evaluate process practices and identify improvement opportunities, we can compare current capabilities of an organization's processes with the best practices recommended by a reference model. This comparison serves as a basis to derive improvement plans, and specifically allows us to evaluate an organization's capability to produce quality results on time and under the stipulated budget.³

Several reference models for process capability determination have been proposed, including CMMI (Capability Maturity Model - Integration) and ISO/IEC 15504 (a standard for software process assessment agreed by ISO and the International Electrotechnical Commission). They suggest process practices that should be implemented in an organization to better perform and successfully achieve its business goals. Although ISO/IEC 15504 is an international standard for determining process capability, in the US the CMMI is unquestionably the most popular model, and CMMI complies with the ISO/IEC 1504 standard.

CMMI is designed to help an organization improve processes used to manage the development, acquisition, and maintenance of products or services. CMMI is used as a guide for selecting process improvement strategies by facilitating the determination of current process capabilities and the identification of the issues most critical to software quality and process improvement.

The problem

Based on the assumption that there are fundamental practices that should be incorporated in all the processes executed in the organization, a standard process for an organization is typically defined by considering best practices and suggestions from international standards, industrial organizations, governmental guidelines, in-house best practices, etc. (e.g., RUP, ISO/IEC 12207, etc). But for each project, the standard process must be adapted to the particularities of the organization and the project itself.

Following this strategy, Unisys created the Unisys Business Blueprint. This is a business and systems modeling architecture that integrates business vision and IT execution to drive organizational agility. To make organizations successful in meeting the requirements of today's fast-paced information world Unisys has developed Blueprinting to align business with information technology and provide traceability across the whole enterprise. Blueprinting is now the foundation for most of the Unisys business operations, including Unisys GPS geographies, programs, and projects. All are encouraged to use Unisys Business Blueprint Methodology for development, management, and transition of Unisys solutions.

RUP is an important component of Unisys Business Blueprint. RUP allows us to select and customize its process elements to adhere to the particularities inherent in each Unisys GPS project, program, or business unit. Moreover, RUP provides an outstanding foundation that allows Unisys to achieve a higher level of process capabilities in many different CMMI process areas.

However, RUP is weak in some CMMI process areas. In a comprehensive study performed by the Software Engineering Institute, RUP was assessed against CMMI Continuous Representation.⁴ Although RUP performed well in most of the CMMI process areas, the following weaknesses were identified:

Supplier Agreement Management is out of the scope of RUP; that is, RUP in its current form does not explicitly deal with managing work from external suppliers to the project. This is an issue for projects in which Unisys needs to employ subcontractors.

RUP does not explicitly support all the Technical Solution Process Area's practices. For example, RUP does not explicitly cover consideration of design alternatives except at the architectural level, and RUP does not explicitly cover the use of selection criteria for product solutions or components.

In a 2003 study, Manzoni and Price evaluated RUP against SW-CMM.⁵ For each key practice (KP) identified in each key process area (KPA) of SW-CMM levels 2 and 3, the Rational Unified Process was assessed to determine whether it satisfied the KPA or not. The report concluded that an organization using RUP would need to complement it to conform to SW-CMM. According to the study, SW-CMM key process areas best supported by RUP are requirements management, software project planning, software project tracking and oversight, software configuration management, organization process definition, and software product engineering. RUP offers good support to both integrated software management and inter-group coordination KPAs; RUP offers low support for software quality assurance, organization process focus, and peer review KPAs; and RUP does not support software subcontract management or training KPAs.

Based on these analytical studies, we conclude that an organization would need to enhance its version of RUP to improve its process capabilities.

Back to top

The approach

In this section, I will describe the approach Unisys GPS Blueprint is using to enhance Unisys Blueprint Methodology to increase its level of compliance with CMMI. As indicated in Figure 1, there is a symbiotic relationship between assessment, capability maturity determination, and process improvement.⁶ The capacity determination of a process -- in our case, the Unisys Blueprint methodology, or more precisely the RUP product -- is used to identify weaknesses that motivate improvements. Such improvements reflect changes in the process -- in our case, changes to the RUP product.

Figure 1: Software process assessment and improvement

Models are used as references for process assessment and for determining improvement opportunities. Nevertheless, software process continuous improvement demands a disciplined approach. In our case, we have adopted an incremental, inductive improvement approach called the Quality Improvement Paradigm -- QIP.

QIP has been successfully applied for many years at several organizations. HP, Daimler-Benz, NASA, Nokia, and Motorola⁷ offer a few examples where higher levels of maturity and return on investment have been obtained via the use of QIP and its supporting methods.

QIP: A two-loop feedback process

The QIP is a two-loop feedback process that includes a project loop and an organization loop.⁸ This is a variation of the scientific method consisting of the steps illustrated in Figure 2:

Figure 2: QIP intra- and inter-loop

As shown in Figure 2, the QIP process involves the following steps:

1. Characterize and understand the organization and its process capabilities. To do so, perform capability determination and process assessment of the current projects and its environment with respect to reference models and metrics.
   
   
2. Set quantifiable goals for successful project performance and improvement.
   
   
3. Choose the appropriate process and supporting techniques, methods, and tools. New processes may need to be created. However, it is much more likely that existing processes will be tailored to fulfill the gaps identified during the characterization and understanding of the organization.
   
   
4. Execute the processes, construct the products, and collect and validate the prescribed data. According to AINSI,⁹ after issues are identified and improvement options determined, a pilot project should be executed using new practices and/or tools. The scope, participants, and project evaluation strategy should be defined before its execution. After the pilot project execution is finished and the results are analyzed, the technology might be transferred to the rest of the organization or other pilot projects should be executed.
   
   
5. Analyze the data to evaluate the current practices, determine problems, record findings, and recommend future project improvements. This step is crucial to the success of this solution. It is here that both project and organization learning is leveraged. The feedback obtained by analyzing the measurable goals and process effectiveness will support the continuous improvement of both our business and our methodology.
   
   
6. Package the experience in the form of models and other forms of structured knowledge.

The following sections outline the approach to be used in each of the above steps.

Capability determination and process assessment

In the study performed by the Software Engineering Institute, RUP was assessed against CMMI Continuous Representation.¹⁰ The weaknesses of RUP regarding this reference model have been identified and suggestions for improvement have been outlined.

Set quantifiable goals

The Goal/Question/Metric (GQM) is the method for defining software measurement.¹¹ GQM allows us to define a measurement model on three levels:

• Conceptual level (goal): A goal is defined for an object, for a variety of reasons, with respect to various models of quality, from various points of view, and relative to a particular environment/project.
  
  
• Operational level (question): A set of questions is used to define models of the object of study and then focuses on that object to characterize the assessment or achievement of a specific goal.
  
  
• Quantitative level (metric): A set of metrics, based on the models, is associated with every question in order to answer it in a measurable way.

Table 1 provides a sample of a Goal-Questions-Metrics model used in our study.

Choose the processes

Based on the characterization of the environment and the defined objectives, we have to choose the appropriate processes for improvement, as well as the process tools and supporting methods, making sure they agree with the objectives.

Table 2 presents the specific process practices within the CMMI Technical Solution process area that have low or medium support by RUP according to SEI assessment.

Table 3 shows the process models we analyzed and their compliance with CMMI Technical Solution's Specific Process practices. CMMI Supplier Agreement Management's Specific Process practices are not included since RUP does not provide any specific support to them. The compliance level is indicated by Low, Medium or High (L, M, H).

Note that the RUP benchmarking was extracted from Gallagher & Brownsword 2001 RUP/CMMI tutorial.¹² Our results can be further explained as follows:

Rational Unified Process. We replicated here the results of the assessment conducted by SEI where RUP was benchmarked against CMMI Continuous Representation. Only the specific practices considered as either low or medium supported by RUP are shown.

NASA SEL COTS-based process.¹³ After investigating fifteen projects developed according to NASA COTS-based software development, Morisio and colleagues proposed new process elements for COTS (Commercial Off-the-Shelf available software) identification, selection, and integration. For instance, the requirement process was enhanced with the following activities: make versus buy decision, COTS identification and selection, and COTS familiarization. Table 4 shows the synergy between this process model and the CMMI Technical Solution process area.

OTSO COTS Selection Process. Kontio¹⁴ proposes a method for searching, screening and evaluting COTS. This method was successfully applied in two case studies carried out with Hughes Corporation in the EOS program developed for NASA. Software Productivity Consortium embraced this method as part of its COTS purchase process (SPC, 1989). Table 5 presents the synergy between OTSO and CMMI Technical Solution and Supplier Management process areas.

SPC's Subcontracting Products or Services for Software-Intensive Systems Guidebook. This provides a process for managing subcontracting of products or services. The first activity of this process is to perform the make vs. buy analysis. This activity describes the use of a balanced scorecard to identify and focus on business needs when evaluating make versus buy alternatives (SPC, 2001). The scorecard contains financial performance, customer satisfaction, internal process, learning and innovation, and sourcing liability factors, along with strategies to optimize performance for those factors that relate to business needs. Table 6 presents the synergy between this process, more specifically between the activity to perform make vs. buy analsyis and the CMMI Technical Solution.

In this section, we presented an overview of the process models we investigated to address the weakness of RUP with regards to CMMI Technical Solution and Supplier Management process areas. Three process models (in addition to RUP) were analyzed. We indicated the level of synergy of these processes and CMMI. The three cited processes inspired us to propose the creation of new process elements to extend RUP. Later on, we will present how this was done.

Packaging experiences for project and corporate learning

Once the measurable goals are set, the processes are chosen and executed. Then, it is time to analyze the results, package the experience and lessons learned, and save these packages in our corporate repository for reuse and continuous improvement. By doing so, our assets can be reused and can evolve. In addition, as prescribed in Figure 2, we should consider them for the further iterations in the same project or leverage them across the organization.

To package our experience, we have extended RUP. In the next section, these new elements are presented.

Back to top

New process elements

Figure 3 shows an overview of the new process elements that we have created. In the following paragraphs I provide a high-level description of these new process elements. To create the elements, we have used Spearmint,¹⁵ a graphical modeling tool for describing software development processes. The tool's conceptual schema of process information is a subset of the OMG's Software Process Engineering Metamodel (SPEM) specification. The tool utilizes a graphical notation close to UML. A full description of the new elements can be provided under request.¹⁶

Figure 3: New process elements

Based on the analyses of process models cited in the previous section, we proposed that the following activities be added to our version of RUP.

Perform the make vs. buy analysis. The make vs. buy analysis is the decision-making process to determine whether to implement a COTS solution or build a custom solution. The project manager is assigned this activity. As noted by Morisio and his colleagues, the use of COTS in a project is a key decision that impacts all subsequent phases and the success of the project. Therefore, the main project stakeholders should participate in this analysis and final decision.

Define COTS evaluation scope. This planning activity is performed by the project manager to define the scope for the activities involved in the component evaluation process.¹⁷ The organizational characteristics provided in the Software Development Document, customer needs indicated in the Vision document, and project specifications provided in the Software Requirement Specification (SRS) and Supplementary Specification are used by the project manager to create the component evaluation plan. This plan would enrich the Software Development Document and defines the level of effort for each activity to be performed in the component evaluation process. Each iteration may require this plan be redefined for one or more of the process activities. Further details about Software Development Document, SRS, Supplementary Specification and Vision artifacts can be found in RUP.

Perform COTS evaluation. This activity addresses the problems of evaluating, comparing, and selecting components.¹⁸ This activity would complement the Analysis and Design discipline -- more precisely, the workflow detail: perform architectural synthesis activity. Although this activity focuses on off-the-shelf components, it applies to all types of components large or small. This activity is strongly related to the architectural synthesis. It deals with evaluating components that already exist within the project or that have been created in previous iterations or system versions, or COTS that have been requested to be part of the system. The architect is primarily responsible for this activity. As recommended by Kontio (1995) and SPC, this activity can be decomposed in the following sub-activities: search and screen candidates, define evaluation criteria, evaluate component alternatives, and analyze evaluation results. Figure 4 shows the product flow of these sub-activities.

Based on the results provided by this activity, the architect can generate change requests related to the proposed architecture and/or requirements. These change requests would be managed using the project change management process as recommended in RUP. The main output of this activity would be a list of selected components indicating the components chosen for inclusion in the system as a result of the evaluation process. As far as RUP artifacts are concerned, this list would be included in the Software Architecture Document.

Figure 4: Component evaluation product flow

Purchase COTS product and service agreement. This activity's main goal is to acquire the select components. It is also recommended to purchase a service agreement that provides support and upgrades to the acquired components.¹⁹

Transition COTS product. This activity's main goal is to transit the acquired products from the supplier to the project.²⁰ The project manager must ensure that an adequate infrastructure is in place to receive, store, use, and maintain the acquired components. In addition, appropriate training must be provided for those involved in receiving, storing, using, and maintaining the acquired products. Finally, the project manager should make sure that storing, distributing, and using the acquired products are performed according to the terms and conditions specified in the supplier agreement or license.

Back to top

Conclusion

RUP is the de facto industry standard for project lifecycle development and management. Unisys integrates RUP into its Business Blueprint methodology to provide a highly mature process across the entire organization. However, RUP presents low-process capability regarding some CMMI software process areas and needs improvement. To clearly identify these weaknesses and improve RUP to overcome them, we have used an empirically validated and technically sound software process improvement approach called QIP. As a result, a process model based on the Rational Unified Process concepts was proposed to enhance RUP compliance to CMMI. To verify the efficiency and efficacy of the proposed process model, we are currently validating it on pilot projects. To roll it out in the entire organization, we are proposing the integration of this new capability via a CMMI plug-in for RUP. Finally, we believe that other groups can apply the approach we have described in this paper to mitigate risks in other process areas.

Back to top

References

V. Basili, G. Caldiera and D. Rombach, "The Goal Question Metric Approach."Encyclopedia of Software Engineering. Wiley 1994.

V. R. Basili, M. K. Daskalantonakis, R. H. Yacobellis. "Technology Transfer at MOTOROLA," IEEE Software, 11(2): 70-76.

L. Briand; K. El Eman; W. L. Melo. "AINSI: An inductive method for software process improvement: concrete steps and guidelines." In K. El Eman and N. H, Madhavji (eds.), Elements of Software Process Assessment and Improvement. 1999. IEEE Press.

CMMI Product Team. Capability Maturity Model Integration (CMMISM), Version 1.1, Continuous Representation, CMU/SEI-2002-TR-011, 2002.

CMMI Product Team. Capability Maturity Model Integration (CMMISM), Version 1.1, Staged Representation, CMU/SEI-2002-TR-012, ESC-TR-2002-012, 2002.

K. El Emam; J.-N. Drouin; W. Melo. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. IEEE Press. 1998.

B. Gallagher & L. Brownsword. "The Rational Unified Process and the Capability Maturity Model -- Integrated Systems/Software Engineering." RUP/CMMI Tutorial -- ESEPG, 2001.

R. Grady, Successful Software Process Improvement, Prentice-Hall, 1997.

T. Kilpi, "Implementing a Software Metrics Program at Nokia," IEEE Software, 18(6):72-77, 2001.

J. Kontio. "A Case Study in Applying a Systematic Method for COTS Selection,"Proc. of the 18th Int. Conf. on Software Engineering, IEEE CS Press, March 1996.

F. McGarry et .al. "An Overview of the NASA Software Engineering Laboratory." NASA SEL, Technical Reports, SEL-94-005, 1994.

ISO/IEC TR 15504-1. "Information technology -- Software process assessment -- Part 1: Concepts and introductory guide." 1998.

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.

L. V. Manzoni & R. T. Price. "Identifying Extensions Required by RUP to Comply with CMM Levels 2 and 3." IEEE TSE, Vol. 29, No. 2, February 2003.

M. Morisio, C.B. Seaman, V.R. Basili, A.T. Parra, S.E. Kraft, S.E. Condon. "COTS-Based Software Development: Processes and Open Issues."Journal of Software and Systems, 2001.

M. Paulk. Capability Maturity Model for Software, Version 1.1. Addison-Wesley.1993.

Software Productivity Consortium (SPC). Component Evaluation Process. SPC-98091-CMC. 1999.

Software Productivity Consortium (SPC). "Subcontracting Products or Services for Software-Intensive Systems." SPC-2000039-MC, September 2001.

Rational Software. "Reaching CMM Levels 2 and 3 with the Rational Unified Process." White Paper. 2001.

R. W. Reitzig; Carlo Rodriguez; Gary Holt. "Achieving Capability Maturity Model Level 2 with the Rational Unified Process." Gognenceinc Integrated Software Engineering. www.cognence.com. White Paper. 2002.

R. W. Reitzig; John B. Miller; Dave West; Raymond L. Kile. "Achieving Capability Maturity Model Integration Maturity Level 2 Using IBM Rational Software's Solutions." Rational White Paper. 2003.

R. W. Reitzig. "Using Rational Software Solutions to Achieve CMMI Level 2."The Rational Edge. Jan. 2003.

Back to top

Appendix A: Related work

RUP is one of the pillars of Unisys Blueprint Methodology. RUP has been claimed as a "software process improvement tool" that would help an organization or project to achieve a higher level of process capabilities. In this section, we highlight some studies that advocate RUP as such a tool. We do not intend to cover all the experiences already conducted about this subject, but to show a sample related to our proposal.

Reitzig and his colleagues (2002) identified various RUP roles, disciplines, templates, and activities that would apply in satisfying the various CMM Level 2 key practice areas. To deal with the weakness of RUP regarding SW-CMM Level 2-3, they recommended using other processes in combination with RUP. For instance, regarding the lack of RUP support for the supplier management process, they claimed that an organization could become compliant with this process area by using the IEEE Std 1062 Recommended Practice for Software Acquisition. This standard outlines the recommended steps an organization should follow when undergoing a software acquisition effort. According to Reitzig et. al., if the standard were used correctly, many of the supplier management procedures asked for by the SW-CMM would be produced.

In another white paper Rational Software (2001) describes how Rational Unified Process can support an organization that is trying to achieve SW-CMM Level 2-3. High-level recommendations are provided on how to cover RUP weaknesses regarding SW-CMM Level 2-3 (Rational, 2001).

Reitzig and his colleagues (2003) provide guidelines on how an organization that uses RUP can accelerate the attainment of CMMI maturity Level 2, and have a solid foundation for maturity level 3. Since the Technical Solution process area is only requested in CMMI Staged Representation Level 3, they did not address the weaknesses identified in RUP regarding compliance with this process area. Regarding the supplier management process area, which is required in CMMI Staged Representation Level 2, they indicated that many of the practices required by the CMMI in the Supplier Agreement Management process area are not specifically addressed by RUP. Reitizig (2003) complements this study by indicating supplementary standards and practices that could be leveraged to overcome RUP weaknesses regarding CMMI Level 2-3, but he does not explicitly indicate how RUP should be enhanced to incorporate his recommendations.

Manzoni and Price (2003) after identifying the issues of RUP with regards to SW-CMM -- proposed creating new process elements to improve RUP. For instance, they proposed a new discipline for dealing with supplier management and new procedures to estimate and track critical computer resources. Detailed descriptions of such new elements can be found in Manzoni (2001). These cited studies are very useful for confirming the weaknesses of RUP with regards to CMMI compliance. Also, they provide overall guidance on how RUP could be enhanced to overcome such issues.

Back to top

Notes

¹Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the author(s) and do not necessarily reflect the views of Unisys Corporation.

²B. Gallagher & L. Brownsword. "The Rational Unified Process and the Capability Maturity Model -- Integrated Systems/Software Engineering." RUP/CMMI Tutorial -- ESEPG, 2001.

³ M. Paulk. Capability Maturity Model for Software, Version 1.1. Addison-Wesley.1993.

⁴ B. Gallagher & L. Brownsword. "The Rational Unified Process and the Capability Maturity Model -- Integrated Systems/Software Engineering." RUP/CMMI Tutorial -- ESEPG, 2001.

⁵ L. V. Manzoni & R. T. Price, "Identifying Extensions Required by RUP to Comply with CMM Levels 2 and 3," IEEE TSE, Vol. 29, No. 2, February 2003.

⁶ K. El Emam; J.-N. Drouin; W. Melo. SPICE: The Theory and Practice of Software Process Improvement and Capability Determination. IEEE Press. 1998.

⁷ The success with QIP is documented for most of these companies in the studies cited here: For HP, see R. Grady, Successful Software Process Improvement, Prentice-Hall, 1997. For NASA, see F. McGarry et. al. "An Overview of the NASA Software Engineering Laboratory," NASA SEL, Technical Reports, SEL-94-005, 1994. For Nokia, see T. Kilpi, "Implementing a Software Metrics Program at Nokia", IEEE Software, 18(6):72-77, 2001. For Motorola, see V. R. Basili, M. K. Daskalantonakis, R. H. Yacobellis. "Technology Transfer at Motorola," IEEE Software, 11(2): 70-76.

⁸ V. Basili, "Software Improvement Feedback Loops: The SEL Experience," 10th Software Development Expo & Conference (SODEC), Tokyo, Japan, June 2001.

⁹ L. Briand; K. El Eman; W. L. Melo. "AINSI: An inductive method for software process improvement: concrete steps and guidelines," in K. El Eman and N. H, Madhavji (eds.), Elements of Software Process Assessment and Improvement. IEEE Press: 1999.

¹⁰ B. Gallagher & L. Brownsword, 2001. Op. cit.

¹¹ V. Basili, G. Caldiera and D. Rombach, "The Goal Question Metric Approach."Encyclopedia of Software Engineering. Wiley 1994.

¹² B. Gallagher & L. Brownsword, "The Rational Unified Process and the Capability Maturity Model -- Integrated Systems/Software Engineering," RUP/CMMI Tutorial -- ESEPG: 2001.

¹³ M. Morisio, C.B. Seaman, V.R. Basili, A.T. Parra, S.E. Kraft, S.E. Condon, "COTS-Based Software Development: Processes and Open Issues," Journal of Software and Systems, 2001. It is important to point out that Morisio's COTS-based process provides new elements to an already existing NASA COTS-based software development, which is essentially different from the Rational Unified Process. It is out of the scope of this paper to compare NASA COTS-based software development to RUP. Our goal here is to indicate that the ideas proposed by Morisio and his colleagues have influenced our decision to create new process elements to enhance our corporate process and increase our compliance to CMMI.

¹⁴ J. Kontio. "A Case Study in Applying a Systematic Method for COTS Selection," Proc. of the 18th Int. Conf. on Software Engineering, IEEE CS Press, March 1996.

¹⁵ http://www.iese.fhg.de/Spearmint_EPG/

¹⁶ A full description of the new elements can be provided under request.

¹⁷ Software Productivity Consortium (SPC). Component Evaluation Process. SPC-98091-CMC. 1999.

¹⁸ Ibid. See also J. Kontio. "A Case Study in Applying a Systematic Method for COTS Selection,"Proc. of the 18th Int. Conf. on Software Engineering, IEEE CS Press, March 1996.

¹⁹ Software Productivity Consortium, 1999. Op. cit.

²⁰ Ibid.

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• The approach
• New process elements
• Conclusion
• References
• Appendix A: Related work
• Notes
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers