12.5 CMM and CMM Integration

12.5 CMM and CMM Integration

12.5.1 CMM

The CMM ^. for Software is a model for identifying the maturity of an organization in software process development. CMM ^. was developed by the Software Engineering Institute [5] and released as a full version in 1993. It has become a de facto standard for assessing and improving software processes. Its aim is to help software organizations improve the maturity of their software processes from ad hoc, chaotic processes to mature, disciplined software processes. The use of the CMM ^. spread rapidly to many organizations and soon became the preferred means of determining the maturity of the software development processes of an organization.

In addition to software processes themselves , the CMM ^. focuses on software process capability, performance, and maturity as defined in [6]:

• Software process capability describes the range of results that can be expected to be achieved by following a software process. The software process capability of an organization provides one means of predicting the most likely outcome expected from the next software project the organization undertakes.

• Software process performance represents the actual results achieved by following a software process. Thus, software process performance focuses on the results achieved, while software process capability focuses on the results expected.

• Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective.

The main principle of the CMM ^. is simple. It distinguishes five levels of maturity. Each level is identified by a certain number of key process areas. To achieve a particular level of maturity means to comply with all key process areas of that and previous levels. Each key process area is described in terms of key practices that describe the activities and infrastructure that contributes most to the effective implementation and institutionalization of the key process area. The key practices provide a description of the essential elements of an effective software process (i.e., they describe what is to be done, and not how the process should be implemented).

The key practices are intended to communicate principles that apply to a wide variety of projects and organizations, which are valid across a range of typical software applications, and which will remain valid over time.

Therefore, the approach is to describe the principles and leave their implementation as the responsibility of each organization, according to its culture and the experiences of its managers and technical staff.

The CMM ^. specifies five levels of maturity as shown in Figure 12.5. The five CMM ^. levels are [7]:

1. Initial . The software process is characterized as ad hoc, and even chaotic. Success depends much on individual effort and heroics . There are no or few processes that are defined.

2. Repeatable . The main goal of this level is to achieve a stable development environment and establish a project management. Basic project management processes are established to track cost, schedule, and functionality. The processes needed to repeat earlier successes with projects with similar applications are identified at this level.

   
   Figure 12.5: The software CMM levels.

3. Defined . To achieve this level, it is necessary to establish the organization’s common processes and engineering methods . The software processes for both management and engineering activities are documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, adjusted version of the organization’s standard software process for developing and maintaining software.

4. Managed. This level specifies how to manage the continuous changes to which an organization is exposed. Detailed measurements of the software process and product quality are collected. Both the software process and products are quantitatively evaluated and controlled.

5. Optimizing . Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

The key process areas at level two focus on the ability to repeat software projects, so it concerns processes related to establishing basic project management controls. The key process areas are requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and SCM.

The key process areas at level three address both project and organizational issues. The key process areas are organization process focus, organization process definition, training program, integrated software management, software product engineering, intergroup coordination, and peer reviews.

The key process areas at level four focus on establishing a quantitative understanding of both the software process and the software work products being built. They are quantitative process management and software quality management.

The key process areas at level five cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement. They are defect prevention, technology change management, and process change management.

On these levels, SCM is a key process area on the second ( repeatable) maturity level. On level five are technology change management and process change management, but these types of change are not directly related to the change management that is a part of SCM. The SCM key process area includes the same types of key practice as other key process areas. The basic principles of the key practices are ensuring the availability of resources for the activities concerned , planning them, performing them, measuring them, and analyzing them. A verification process also achieves quality assurance goals.

The following key practices for SCM are specified:

1. Commitment to perform:

   • The project follows a written organizational policy for implementing SCM.

2. Ability to perform:

   • A group that is responsible for coordinating and implementing for the project (i.e., the SCM group ) must exist.

   • Adequate resources and funding must be provided for the performance of their activities.

   • A manager is assigned specific responsibilities for SCM.

   • Members of the SCM group are trained in the objectives, procedures, and methods for performing their SCM activities.

3. Activities performed:

   • An SCM plan is prepared for each software project according to a documented procedure.

   • A documented and approved SCM plan is used as the basis for performing the SCM activities.

4. Measurement and analysis:

   • Measurements are made and used to determine the status of the SCM activities.

5. Verifying implementation:

   • The SCM activities are reviewed with the project manager on both a periodic and event-driven basis.

   • The software quality assurance group reviews and audits the activities and work products for SCM and reports the results.

The CMM has rapidly become widely accepted, and many organizations in both military and civil industries have used it to measure their ability to produce software of high quality and to improve their software development processes. For example, the deployment of SCM tools has increased tremendously during the 1990s, thanks to the popularity of CMM .. Experience indicates, however, that acquiring CMM is difficult. The vast majority of organizations are not able to reach even level two. In

2002, less than 150 organizations in the world reached levels four or five. Indian companies with approximately 80 organizations, which comply with these levels, occupy leading positions . One of the problems with using CMM is its extensive and very detailed documentation, which makes it difficult to understand and to process. One of the common complaints about the CMM is that its use is only feasible in very large organizations, despite documented evidence that it is also applicable in small organizations [8]. Although the intention of CMM is not to require or espouse a specific model of the software life cycle or a specific organizational structure, but rather to give basic elements of each process, there are complaints that the CMM is most applicable with the waterfall model, and that it is not applicable with other types of development processes (such as incremental development). There have been, however, positive experiences with the use of different development models in combination with the CMM (e.g., extreme programming [9]). The CMM has been a very positive influence in encouraging the use of SCM, which has led to a wider understanding of the need to use SCM tools and for planned and measurable SCM processes in software development.

12.5.2 CMM Integration

Although the objectives of the CMM are the improvement of software development, most of the principles identified in the CMM are valid for other types of life cycles. Many organizations now apply the CMM in their processes, which are not necessarily pure software development processes. Learning from these experiences, SEI has developed a new model, CMM Integration (CMMI .), which is an extension of the CMM .. The targets of CMMI are system and integration processes [10]. In particular, CMMI is a result of combining CMM for Software version 2.0 with the EIA Interim Systems Engineering Capability Model Standard and the CMMI Product Development, Draft Version 0.98. A CMM ^. for Software version 2 draft was the major contributor to CM in the CMMI [11]. This version was never released but included about 200 user requests from lessons learned in CMM for Software implementation, defining a better understanding of software maturity, and achieving better consistency with the other software industry standards and terminology [12]. The staged structure of the model is adopted from the CMM .. Like the CMM ., CMMI is composed of five ascending levels. The designation of level two was changed from repeatable to managed, and that of level four was changed from managed to quantitatively managed. The term key process area has been changed to process area.

CM is a process area at level two that belongs to a class of support area processes together with process and product quality assurance, measurement and analysis, decision analysis and resolution, and causal analysis and resolution. In the same way as SCM in the CMMI, the purpose of CM is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits [13]. The main configuration management activities are grouped in establishing baselines, establishing integrity, and tracking and controlling changes (see Figure 12.6).

Figure 12.6: CM activities in CMMI

Similar products