7.1 What is CMMI?

CMMI is a process improvement approach that defines the essential elements of effective processes.  It provides guidance for quality processes and a point of reference for appraising current processes.   It can be used to guide process improvement across a project, a division, or an entire organization.

CMMI includes successful practices and practical knowledge that have been implemented in hundreds of organizations since Version 1.0 was first released in 2000.  The scope of CMMI includes all of the systems engineering and project management processes that are covered by this guidebook.  CMMI is maintained by the Software Engineering Institute at Carnegie Mellon University, in consultation with a CMMI Product Team that includes process experts from the public sector, private companies, and academia.  All of the current CMMI documentation is available on the SEI web site at http://www.sei.cmu.edu/cmmi/.

The CMMI Models

The CMMI model documents can seem formidable, but they don’t have to be.  Armed with a basic understanding of how the models are put together, you can easily navigate through the models and quickly find the information you need.  The remainder of this section provides a quick overview of the major types of information that are included in CMMI, summarized in Figure 7‑2.

Figure 7‑2   Inside the CMMI Models

Constellations

Three different CMMI model documents are available, one for each of three different CMMI constellations.  Constellations collect together the parts of CMMI that apply to different types of organizations.  The three constellations in CMMI Version 1.2 are:

• Development – For organizations that want to improve their ability to develop products and services.  For example, this includes the ITS system integrators and some larger transportation agencies.
• Acquisition – For organizations that want to improve their ability to acquire products and services.  This includes the transportation agency project sponsors.
• Services – For organizations that want to improve their ability to establish, manage, and deliver services.  In ITS, this includes the systems engineering technical assistance consultants.

When you begin to use CMMI, you start by choosing a constellation because CMMI publishes separate model documentation for each constellation.  Transportation agencies that typically use a procurement process to deliver their ITS projects should start with the Acquisition constellation.  Transportation agencies that do significant in-house development and the private companies that respond to RFPs for ITS projects should use the Development constellation.  Organizations that chiefly provide services – toll agencies and 511 providers for example, may consider the Services constellation.  A state DOT or large private company could find that different divisions within the organization would use different constellations.

Figure 7‑3 shows the three constellations and their relationships.  As shown, the constellations overlap because processes like project planning, monitoring, and control are germane to all types of organizations.   These common areas are defined one time in the “CMMI Model Foundation” and included in all three constellations.

Figure 7‑3  CMMI Constellations

Process Areas

Process areas are the main building blocks of each CMMI model.  They are defined for each topic that CMMI covers and are allocated to constellations so that each constellation includes some common process areas (defined in the CMMI Model Foundation) and specific process areas that are unique to that constellation.   These process areas cover the “waterfront” of successful practices needed for systems acquisition, system development, and service provision.  

Figure 7‑4 identifies the 22 Process Areas that are in the Development constellation.  The process areas are divided into four interrelated categories as shown.  Process management occurs at the organizational level and defines and monitors the processes that are used by the organization and supports training and personnel development.   The project management processes, in turn, support the engineering processes at the project level.  Cross-cutting processes that support all levels are on the left side of the diagram.

The Acquisition constellation process areas are related in a similar fashion as shown in Figure 7‑5.  The “Engineering” process category is replaced by an “Acquisition” process category in this model.  The foundation Process Management, Project Management, and Support process areas are essentially the same in the two models.

Similarly, the Services Constellation includes a set of Service Establishment and Delivery process areas that are supported by general Support, Project Management, and Process Management process areas.

Figure 7‑4 Development Constellation Process Areas

Figure 7‑5 Acquisition Constellation Process Areas

Process Area Documentation

The bulk of the CMMI model is composed of the documentation for each process area.   Figure 7‑6 shows the types of information that are included in each process area and differentiates between information that is required, expected, and informative.  As shown, only the process area goals are required.  A set of expected practices are associated with each goal.  An organization does not have to implement the expected practices, but must be able to explain how their organization achieves the associated goals in another way.  The great majority of process area documentation is informative; it is intended to increase understanding, but is not required.

Figure 7‑6 Process Area Documentation

Table 7‑1 shows an example of the documentation for the Configuration Management process area.  As shown, a general goal statement is supported by several expected practices that are a bit more specific.  These four succinct statements are supported by approximately four pages of informative documentation including detailed notes, typical word products, and typical supplier deliverables that define and explain “baselines”, “configuration items”, “change management” and other key configuration management concepts.  Overall, the Configuration Management process area includes 3 goals and seven expected practices that are supported by 10+ pages of documentation.

Table 7‑1 Example Goal and Practices for the Configuration Management Process Area