• 8.1 The Rational Unified Process
• 8.2 The Capability Maturity Model

8.1 The Rational Unified Process

The Rational Unified Process (RUP) is an iterative development process, geared towards the development of object-oriented systems. It comes with a lot of tool support, inter/intranet sources and templates for different kinds of documents. It complements UML. RUP might be viewed as somewhat intermediate between document-driven and agile methods. It has a well-defined process, includes reasonably extensive upfront requirements engineering activities, yet emphasizes stakeholder involvement through its use-case driven nature. Its two-dimensional process structure is depicted in figure 8.1.

RUP distinguishes four phases: inception, elaboration, construction and transition. Within each phase, several iterations may occur. In a second dimension, RUP distinguishes nine so-called workflows, such as a requirements workflow and a test workflow. These workflows group logical activities, and might extend over all phases, with varying levels of attention. For instance, the requirements workflow is likely to get a lot of attention during the early phases, while the deployment workflow is most relevant in the transition phase. This is graphically illustrated by the undulating shapes next to each workflow in figure 8.1. This structure allows us to differentiate between successive iterations, and stress that different iterations have a different emphasis. It recognizes that requirements engineering, design, etc are ongoing activities rather than phases with a strict start and end time.

Figure 8.1 — Process structure of RUP

The inception phase focuses on getting the objectives clear: what is the scope of this project, what are its boundaries, what are the acceptance criteria that will be used when the system is delivered to its customers? During this phase too, the overall cost, schedule and risks are estimated. Critical use cases are developed, as well as a candidate architecture. At the end of this phase, the business case for the system must be clear. This might be input to a go/no-go decision.

The elaboration phase is mainly targeted at analyzing the problem domain, and obtaining an architecture. At the end of this phase, most use cases will be identified, and all major risks must be resolved.

The construction phase is a manufacturing, building process. The emphasis is on developing deployable products. Complete components are developed and thoroughly tested. User manuals are written. At the end of this phase, the first operational version of the system, the beta release, is ready.

In the transition phase, the system is released to the user community and beta-tested. During this phase, databases may have to be converted, users are trained and, in case of a replacement system, the legacy system being replaced is phased out.

RUP is based on a series of best practices that have evolved over the years. These best practices are listed in figure 8.2. Many of these best practices of course are also present in other development models. A strong point of RUP is that it provides a balanced integration of them. Given its background, it is no surprise that RUP is geared towards the development of object-oriented systems. But RUP is suited for projects with widely different characteristics. The tuning of RUP to the situation at hand though is left to the user of the method.

Figure 8.2 — Best practices of RUP

The RUP is plan-driven methdology of software development.

8.2 The Capability Maturity Model

The software development process can indeed be controlled, measured, and improved. In order to gauge the process of improving the software development process, Watts Humphrey developed a software maturity framework which has evolved into the Capability Maturity Model (CMM). The CMM is a development model created after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term maturity relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.This framework owes tribute to Total Quality Management (TQM), which in turn is based on principles of statistical quality control. Originally, there were separate CMM models for software engineering, systems engineering, and several others. These have now been integrated, and carry the label CMMI. In 2018 was approved version 2.0 of CMMI which is designed to optimize business capability and performance in a changing world. The CMMI v.2.0 contains a proven set of best practices that enables organizations to build and benchmark the key capabilities that address the most common business challenges.

In CMM (and CMMI), the software process is characterized into one of five maturity levels, evolutionary levels toward achieving a mature software process. To achieve a certain maturity level, a number of process areas must be in place. These process areas indicate important issues that have to be addressed in order to reach that level. Taken together, the process areas of a level achieve the set of goals for that level. Figure 8.3 lists the maturity levels and associated process areas of CMMI.

Figure 8.3 — Maturity levels of CMMI

CMMI’s maturity levels can be characterized as follows:

• Initial At the initial process level, the organization operates without formalized procedures, project plans, or cost estimates. Tools are not adequately integrated. Many problems are overlooked or forgotten, and maintenance poses real problems. Software development at this level can be characterized as being ad-hoc. Performance can be improved by instituting basic project management controls:

Requirements management involves establishing and maintaining an agreement with the customer on the requirements of the system. Since requirements inevitably change, controlling and documenting these requirements is important.

Project planning involves making plans for executing and managing the project. To be able to do any planning, an approved statement of work to be done is required. From this statement of work, estimates for the size of the project, resources needed, and schedule are determined, and risks to the project are identified. The results are documented in the project plan. This plan is used to manage the project; it is updated when necessary.

Project monitoring and control is concerned with the visibility of actual progress. Intermediate results have to be reviewed and tracked with respect to the project plan. When necessary, the project plan has to be realigned with reality.

Supplier agreement management. Where applicable, work done by suppliers has to be managed: plans for their part of the work have to be made, and progress of their part of the job has to be monitored.

Measurement and analysis is concerned with making sure measurements are made and their results used. First, objectives for measurement and the way measures should be collected, stored and analysed are established. Next, the collection, storage, and analysis of data must be implemented. Finally, the results are used for decision making, and corrective actions are taken where needed.

Process and product quality assurance involves reviewing and auditing products and processes to validate that they comply with agreed upon standards and procedures.

Configuration management is concerned with establishing and maintaining the integrity of all work items during the entire project life cycle. This involves identification of configuration items and baselines, and procedures to control changes to them.

• Managed The main difference between the initial process level and the managed process level is that the repeatable level provides control over the way plans and commitments are established. Through prior experience in doing similar work, the organization has achieved control over costs, schedules, and change requests, and earlier successes can be repeated. The introduction of new tools, the development of a new type of product, and major organizational changes however still represent major risks at this level. The process areas needed to advance to the next level are aimed at standardizing the software process across the projects of the organization:

Requirements development involves the production and analysis of requirements. Requirements have to be elicited, analyzed, validated, and communicated to appropriate stakeholders. Requirements development is not a one-shot activity. Rather, requirements are identified and refined throughout the whole life cycle.

Technical solution is about design and implementation. Decisions concerning the architecture, custom development as opposed to an off the shelf solution, and modularization issues are typical ingredienst of this process area.

​Product integration concerns the assembling of a complete product out of its components. This can be one stage after all components have been developed, or it can proceed incrementally. An important element of product integration is the management of interfaces, to make sure that the components properly fit together.

​Verification is concerned with ensuring that the product meets its requirements. Peer reviews are an effective means for early defect detection and removal. Peer reviews, such as walk through sand inspections, are practices in which peers try to identify errors and areas where changes are needed.

​Validation is concerned with establishing that the product fulfills its intended use. As far as possible, validation activities should be done in the intended environment in which the product is going to be used.

​Organization process focus is concerned with organization process improvement. Measurements, lessons learned, project post-mortems, product evaluation reports are typical sources of information to guide improvement activities. The responsibility for guiding and implementing these activities is typically assigned to a process group. In this way, improvement of the organization’s process capabilities is made a responsibility of the organization as a whole, rather than the individual project manager.

​Organization process definition. The organization develops and maintains a set of software process assets, such as process elements, life cycle models, guidelines for tailoring a process model. Each project uses a process built out of these process assets.

​Organizational training. The purpose of the training program is to develop the necessary skills and knowledge of individuals to perform their roles. Training needs are identified at the level of the organization, project and individual. The fulfillment of these needs is addressed as well.

​Integrated project management involves developing a project-specific software process from the organization’s set of standard processes, as well as the actual management of the project using the tailored process. Since the software processes of different projects have a common ancestor, projects may now share data and lessons learned.

Risk management concerns the identification of potential problems, so that timely actions can be taken to mitigate adverse effects.

​Decision analysis and resolution is concerned with establishing guide lines as to which issues houldbesubjectedtoformalevaluation processes, and the application of those formal processes. The selection of COTS components and architectural reviews are example arease where formal evaluation processes might be applied.

• Defined At the defined process level, a set of standard processes for the development and maintenance of software is in place. The organization has achieved a solid foundation, and may now start to examine their processes and decide how to improve them. Major steps to advance to the next level are:

Organizational process performance, whose purpose is to establish and maintain a quantitative understanding of the performance of the set of standard processes. Individual projects are measured, and compared against expected results as documented in a baseline. The information is not only used to assess a project, but also to quantitatively manage it.   

Quantitative project management, which involves the setting of performance goals, measuring process performance, analyzing these measurements, and making the appropriate adjustments to the process in order to bring it in line with the defined limits. There is, therefore, an organization-wide measurement program and the results of it are used to continuously improve the process. An example process measure is the number of lines of code reviewed per hour.

• Quantitatively managed At the quantitatively managed process level, quantitative data is gathered and analyzed on a routine basis. Everything is under control, and attention may therefore shift from being reactive -- what happens to the present project? -- to being proactive -- what can we do to improve future projects? The focus shifts to opportunities for continuous improvement:

Organizational innovation and deployment is concerned with the identification and deployment of improvements. Technical improvements relate to new technologies and their orderly transition into the organization. Process improvements relate to the process in order to improve the quality of the products, the productivity of the software development organization, and reduction of the time needed to develop products.

Causal analysis and resolution is concerned with identifying common causes of defects, and preventing them from recurring.

• Optimizing At the final, optimizing, level, a stable base has been reached from which further improvements can be made. The step to the optimizing process level is a paradigm shift. Whereas attention at the other levels is focused on ways to improve the product, emphasis at the optimizing level has shifted from the product to the process. The data gathered can now be used to improve the software development process itself.