Category list

Section 6.3. Technology Disciplines Covered Under CMMI

6.3. Technology Disciplines Covered Under CMMI

As noted earlier, the Capability Maturity Model began as a process improvement framework for the field of technology engineering. The structure of the original CMM reflects that focus. But as the CMM's popularity grew, the SEI (and the CMM user community) began to see potential for applying the model to a broader group of IT activities. And so the SEI developed extensible forms of CMM, with the base version becoming know as the SW-CMM. A version was tailored for the processes and activities of systems engineering, known as the SE-CMM; a version was tailored to address the unique needs of strategic product and service acquisition (Supplier Sourcing); and a version was developed for the broad applicability of Integrated Product and Process Development, the IPPD-CMM.

Each of these models enjoyed acceptance and success in the various disciplines it addressed. Yet they all still retained many common elements. After a few years , many organizations that used all four disciplines began to ask for a model that capitalized on the common elements and at the same time allowed for a degree of flexible configurability. CMMI was the initiative to regroup these various tailored versions into a single, configurable model for all four disciplines. The Capability Maturity Model Integration represents the end result.

Today, CMMI-Dev v1.2 includes practices and program components for the following IT disciplines:

Systems engineering
Software engineering
Integrated product and process development

In CMMI, these disciplines are keyed to a series of Process Areas that contain the recommended practices that make the model work.

For IPPD, the full model appliesall Process Areas are relevant. IPPD is typically employed on only the largest of projects, or the most disparate, in which multiple organizations or reporting groups from different disciplines must be allied with a common vision to execute multiple project components in a highly coordinated manner.

For systems and software engineering, all Process Areas apply, with the exception of the IPPD principles and practices.

Practices for supplier sourcing are addressed under "Supplier Agreement Management," later in this chapter.

6.4. CMMI-Dev Structure and Design

CMMI-Dev is specifically structured for the IT industry. As discussed earlier in Chapter 5, ISO 9001 can be employed for almost any manufacturing environment. Six Sigma can be used anywhere (or best) where transactions are recurrent. CMMI can (and has been) used in non-IT environments, but its raison d'tre is to help IT organizations develop highly reliable management, engineering, and quality-support systems.

CMMI is focused on the concept of process improvement. It assumes that process works, that following a tried and true path gets you where you want to go most times you travel it. It also operates under the postulate that successful organizations (and by this they mean organizations that have shown themselves to be successful over time) tend to be process-mature. They design processes, implement them, study them, and then refine them over time.

In the parlance of Deming and Baldridge, the honored approach is to Plan, Do, Check, Act.

6.4.1. A Goal-Oriented Design

CMMI is structured as a series of Process Areas (PAs). You can think of each Process Area as a collection of best practices that help a technology organization manage its activity and control its quality. The full model contains 22 Process Areas. As an example, one of the Process Areas is called Project Planning. Naturally, it provides guidance for effectively planning projects. Another PA is called Requirements Development. This PA provides guidance on eliciting , describing, and documenting customer and product requirements.

Each Process Area within CMMI establishes one or more goals that should be achieved in order for an organization to be able to claim that it is truly following the program. There are two kinds of goals in the model: specific goals and generic goals. The generic goals represent the "common elements" of CMMI. The specific goals shape the direction of each Process Area.

Additionally, each goal is supported by recommended practices. You'll find that the goals are typically expressed in high-level terms, while the practices are expressed in more concrete, " actionable " terms. The assumption with the goal-practice structure is that if you implement the practices described for each goal, you'll meet the intention of the goal itself.

There are specific practices for the model's specific goals, and there are generic practices for the model's generic goals.

By way of strict interpretation, the practices are optional. Were an organization to be officially appraised, the job of the lead appraiser would simply be to collect ample evidence that the goals are being met. Yet, most organizations (and certainly most appraisers) find that the best route to complianceand to realizing the benefits of CMMIis to largely use the practices to get to the goals.

I summarize the specific goals and practices of CMMI in the section "The Process Areas of CMMI," later in this chapter. But this is probably a good time to take a look at the generic goals and how they contribute to the model's use.