16. Capability Maturity Model Integration

The Software Engineering Institute¹ developed the Capability Maturity Model (CMM) in the early 1990s as a framework to help software organizations improve their software process maturity. The CMMI is the successor to the older CMM, and its implementation brings best practice in software and systems engineering into the organization. The SEI and many other quality experts believe that there is a close relationship between the maturity of software processes and the quality of the delivered software product.

The CMM built upon the work of quality gurus such as Deming [1], Juran [2] and Crosby [3]. These quality gurus were effective in transforming struggling manufacturing companies with quality problem to companies that could consistently produce high-quality products. Their success was due to the focus on improving the manufacturing process and in reducing variability in the process. The work of these quality experts is discussed in [4].

Similarly, software companies need to have quality software processes to deliver high-quality software to their customers. The SEI has collected empirical data to suggest that there is a close relationship between software process maturity and the quality of the delivered software. Therefore, there is a need to focus on the software process as well as on the product.

The CMM was released in 1991 and its successor, the CMMI^® model, was released in 2002 [5]. The CMMI is a framework to assist an organization in the implementation of best practice in software and systems engineering. It is an internationally recognized model for process improvement and is used worldwide by thousands of organizations.

The process is an abstraction of the way in which work is done in the organization, and is seen as the glue (Fig. 16.1) that ties people, procedures and tools together.

It may be described by a process map which details the flow of activities and tasks. The process map will include the input to each activity and the output from each activity. Often, the output from one activity will become the input to the next activity. A simple example of a process map for creating the system requirements specification was described in Chap. 15 (Fig. 15.​2).

The ISO/IEC 12207 standard for software processes distinguishes between several categories of software processes, including the primary lifecycle processes for developing and maintaining software; supporting processes to support the software development lifecycle, and organization lifecycle processes. These are summarized in Fig. 16.2.

Watts Humphrey began applying the ideas of Deming, Juran and Crosby to software development, and he published the book “Managing the Software Process” [6]. He moved to the SEI to work on software process maturity models with the other SEI experts, and the SEI released the Capability Maturity Model in the early 1990s. This process model has proved to be effective in assisting companies in improving their software engineering practices and in achieving consistent results and high-quality software.

The CMM is a process model and it defines the characteristics or best practices of good processes. It does not prescribe how the processes should be defined, and it allows the organization the freedom to interpret the model to suit its particular context and business needs. It also provides a roadmap for an organization to get from where it is today to a higher level of maturity. The advantage of model-based improvement is that it provides a place to start process improvement, as well as a common language and a shared vision.

The CMM consists of five maturity levels with the higher maturity levels representing advanced software engineering capability. The lowest maturity level is level one and the highest is level five. The SEI developed an assessment methodology (CBA IPI) to determine the maturity of software organizations, and initially most organizations were assessed at level one maturity. However, over time companies embarked on improvement initiatives and matured their software processes, and today, many companies are performing at the higher maturity levels.

The first company to be assessed at CMM level 5² was the Motorola plant in Bangalore in India. The success of the software CMM led to the development of other process maturity models such as the systems engineering capability maturity model (CMM/SE) which is concerned with maturing systems engineering practices, and the people Capability Maturity Model (P-CMM) which is concerned with improving the ability of the software organizations to attract, develop and retain talented software engineering professionals.

The SEI commenced work on the CMMI^® [5] in the late 1990s. This is a replacement for the older CMM model, and its development involved merging the software CMM and the systems CMM, and ensuring that the new model was compatible with ISO 15504 standard.³ The CMMI is described in the next section.

The CMMI consists of five maturity levels (Fig. 16.4) with each maturity level (except level one) consisting of a number of process areas. Each process area consists of a set of goals, and these must be implemented by a set of related practices in order for the process area to be satisfied. The practices specify what is to be done rather than how it should be done. Processes are activities associated with carrying out certain tasks, and they need to be defined and documented. The users of the process need to receive appropriate training to enable them to carry out the process, and process discipline need to be enforced by independent audits. Process performance needs to be monitored and improvements made to ineffective processes.

The emphasis on level two of the CMMI is on maturing management practices such as project management, requirements management and configuration management. The emphasis on level three of the CMMI is on maturing engineering and organization practices. Maturity level three is concerned with defining standard organization processes, and it also includes process areas for the various engineering activities needed to design and develop the software. Level four is concerned with ensuring that key processes are performing within strict quantitative limits, and adjusting processes, where necessary, to perform within these limits. Level five is concerned with continuous process improvement. Maturity levels may not be skipped in the staged implementation of the CMMI, as each maturity level is the foundation for work on the next level.

There is also a continuous representation⁴ of the CMMI (similar to ISO 15504) that allows the organization to focus its improvements on the key processes that are closely related to its business goals. This allows it the freedom to choose an approach that should result in the greatest business benefit rather than proceeding with the standard improvement roadmap of the staged approach. However, in practice, it is often necessary to implement several of the level two process areas before serious work can be done on maturing a process to a higher capability level. Table 16.1 presents motivations for the implementation of the CMMI.

The CMMI model covers both the software engineering and systems engineering disciplines. Systems engineering is concerned with the development of systems that may or may not include software, whereas software engineering is concerned with the development of software systems. The model contains extra information relevant to a particular discipline, and this is done by discipline amplification.⁵ The CMMI has been updated in recent years to provide support for the Agile methodology.

The CMMI allows organizations to benchmark themselves against similar organizations (Fig. 16.3). This is generally done by a formal SEI SCAMPI Class A appraisal⁶ conducted by an authorized SCAMPI lead appraiser. The results will generally be reported back to the SEI, and there is a strict qualification process to become an authorized lead appraiser. The qualification process helps to ensure that the appraisals are conducted fairly and objectively and that the results are consistent. An appraisal verifies that an organization has improved, and it enables the organization to prioritize improvements for the next improvement cycle. Small organizations will often prefer a SCAMPI Class B or C appraisal, as these are less expensive and time consuming.⁷

The time required to implement the CMMI in an organization depends on its size and current maturity. It generally takes one to two years to implement maturity level two, and a further one to two years to implement level 3. The implementation of the CMMI needs to be balanced against the day-to-day needs of the organization in delivering products and services to its customers.

The SEI has gathered empirical data (Table 16.2) on the benefits gained from the implementation of the CMMI [7]. The table shows the median results reported to the SEI.

The processes implemented during a CMMI initiative will generally include:

The CMMI is divided into five maturity levels (Table 16.3) with each maturity level (except level one) consisting of several process areas. The maturity level is a predictor of the results that will be obtained from following the software process, and the higher the maturity level of the organization, the more capable it is and the more predictable its results. The current maturity level acts as the foundation for the improvements to be made in the move to the next maturity level.

The maturity levels provide a roadmap for improvements in the organization, and maturity levels are not skipped in the staged implementation. A particular maturity level is achieved only when all process areas belonging to that maturity level (and all process areas belonging to lower maturity levels) have been successfully implemented and institutionalized⁸ in the organization.

The implementation of the CMMI generally starts with improvements to processes at the project level. The focus at level two is on improvements to managing projects and suppliers and improving project management, supplier selection, management practices and so on.

The improvements at level 3 involve a shift from the focus on projects to the organization. It involves defining standard processes for the organization, and projects may then tailor the standard process (using tailoring guidelines) to produce the project’s software process. Projects are not required to do everything in the same way as the tailoring of the process allows the project’s defined software process to reflect the unique characteristics of the project: i.e., a degree of variation is allowed as per the tailoring guidelines to reflect the unique characteristics of the project.

The implementation of level three involves defining procedures and standards for engineering activities such as design, coding and testing. Procedures are defined for peer reviews, testing, risk management and decision analysis.

The implementation of level four involves achieving process performance within defined quantitative limits. This involves the use of metrics and setting quantitative goals for project and process performance and managing process performance. The implementation of level 5 is concerned with achieving a culture of continuous improvement in the company. The causes of defects are identified and resolution actions implemented to prevent a reoccurrence.

The process areas on the CMMI can be divided into four categories. These are shown in Table 16.5.

This section provides a brief overview of the process areas of the CMMI model. All maturity levels (with the exception of level one) contain several process areas. The process areas are described in more detail in [5] (Table 16.6).

The maturity level of an organization indicates the expected results that its projects will achieve and is a predictor of future project performance. Each maturity level consists of a number of process areas, and each process area consists of specific and generic goals, and specific and generic practices. Each maturity level is the foundation for improvements for the next level (Fig. 16.7).

The specific goals and practices are listed first and then followed by the generic goals and practices. The specific goals and practices are unique to the process area being implemented and are concerned with what needs to be done to perform the process. The specific practices are linked to a particular specific goal, and they describe activities that when performed achieve the associated specific goal for the process area.

The generic goals and practices are common to all process areas for that maturity level and are concerned with process institutionalization at that level. The generic practices are organized by four common features:

They describe activities that when implemented achieve the associated generic goal(s) for the process area. The commitment to perform practices relate to the creation of policies and sponsorship of process improvement; the ability to perform practices are related to the provision of appropriate resources and training to perform the process; the directing implementation practices relate to activities to control and manage the process; and verifying practices relate to activities to verify adherence to the process.

The implementation of the generic practices institutionalizes the process and makes it ingrained in the way that work is done. Institutionalization means that the process is defined, documented and understood. Process users are appropriately trained and the process is enforced by independent audits. Institutionalization helps to ensure that the process is performed consistently and is more likely to be retained during times of stress. The degree of institutionalization is reflected in the extent to which the generic goals and practices are satisfied. The generic practices ensure the sustainability of the specific practices over time.

There is one specific goal associated with the Requirements Management process area (Fig. 16.8), and it has five associated specific practices:

The components of the CMMI model are grouped into three categories, namely required, expected and informative components. The required category is essential to achieving goals in a particular area and includes the specific and generic goals that must be implemented and institutionalized for the process area to be satisfied. The expected category includes the specific and generic practices that an organization will typically implement to perform the process effectively. These are intended to guide individuals or groups who are implementing improvements, or who are performing appraisals to determine the current maturity of the organization. They state what needs to be done rather than how it should be done, thereby giving the organization freedom on the most appropriate implementation.

The informative category includes information to guide the implementer on how best to approach the implementation of the specific and generic goals and practices. These include subpractices, typical work products and discipline amplifications. This information assists with the implementation of the process area.

The implementation and institutionalization of a process area involves the implementation of the specific and generic practices. The specific practices are concerned with process implementation and are described in detail in [8]. The generic practices are concerned with process institutionalization and are summarized in Table 16.7.

The generic goals support an evolution of process maturity, and the implementation of each generic goal provides a foundation for further process improvements. That is, a process rated at a particular maturity level has all of the maturity of a process at the lower levels and the additional maturity of its rated level. In other words, a defined process is a managed process; a quantitatively managed process is a defined process, and so on.

Several of the CMMI process areas support the implementation of the generic goals and practices. These process areas contain one or more specific practices that when implemented may either fully implement a generic practice or generate a work product that is used in the implementation of the generic practice. The implementation of the generic practices is supported by the following process areas (Table 16.8).

SCAMPI appraisals are conducted to enable an organization to understand its current software process maturity, and to prioritize future improvements [9]. The appraisal is an independent examination of the processes used in the organization against the CMMI model, and its objective is to identify strengths and weaknesses in the processes, which are then used to prioritize improvements in the next improvement cycle.

The SCAMPI methodology is the appraisal methodology used with the CMMI, and there are three distinct classes of appraisal (SCAMPI Class A, B and C) [10]. These classes vary in formality, the cost, effort and timescales involved, the rating of the processes and the reporting of results.

The scope of the appraisal includes the process areas to be examined, and the projects and organization unit to be examined. It may be limited to the level 2 process areas, or the level 2 and level 3 process areas, and so on. The scope depends on how active the organization has been in process improvement.

The appraisal will identify any gaps that exist with respect to the implementation of the CMMI practices for each process area within the scope of the appraisal. The appraisal team will conduct interviews and review project documentation, and they will examine the extent to which the practices are implemented.

The appraisal findings are presented and are used to plan and prioritize the next improvement cycle. SCAMPI appraisals are discussed in more detail in [4].

The Capability Maturity Model Integration is a framework to assist an organization in the implementation of best practice in software and systems engineering. It was developed at the Software Engineering Institute and is used by many organizations around the world.

The SEI and other quality experts believe that there is a close relationship between the quality of the delivered software and the maturity of the processes used to create the software. Therefore, there needs to be a focus on the process as well as on the product, and the CMMI contains best practice in software and systems engineering to assist in the creation of high-quality processes.

The process is seen as the glue that ties people, technology and procedures coherently together. Processes are activities associated with carrying out certain tasks, and they need to be defined and documented. The users of the process need to receive appropriate training on their use, and process discipline needs to be enforced with independent audits. Process performance needs to be monitored and improvements made to ineffective processes.

The CMMI consists of five maturity levels with each maturity level (except level one) consisting of several process areas. Each maturity level acts as a foundation for improvement for the next improvement level, and each increase in maturity level represents more advanced software engineering capability. The higher the maturity level of the organization, the more capable it is, and the more predictable its results. The lowest level of maturity is maturity level 1 and the highest level is maturity level 5.

Each process area consists of a set of specific and generic goals, and these must be implemented by an associated set of specific and generic practices. The practices specify what is to be done rather than how it should be done, and the organization is given freedom in choosing the most appropriate implementation to meet its needs.

The SCAMPI appraisal methodology is used to determine the maturity of software organizations. It is a systematic examination of the processes used in the organization against the CMMI model, and it includes interviews and reviews of documentation. A successful SCAMPI Class A appraisal allows the organization to report its maturity rating to the SEI and to benchmark itself against other companies. Appraisals are a part of the improvement cycle, and improvement plans are prepared after the appraisal to address the findings and to prioritize improvements.