There are at least three reasons to use a reference model in structuring a process improvement program. A model provides:

  • a language and constructs with which to communicate about process issues

  • a standard of comparison and benchmark to evaluate process “goodness”

  • process improvement investment guidance

Two important issues in selecting a model are its domain and its architecture.

Model Domains

The domain of a model refers to the system whose order and effectiveness are to be improved. There are numerous models crafted to focus on the critical aspects of various domains, including software, system engineering, system acquisition, people issues, software integrity, etc. Additional versions of the CMMI® address acquisition practices, data management, and people issues.

Model Architecture

The architecture of a model refers to its underlying structure and the relationship of Maturity Levels and Process Areas (PAs). A staged model (see Figure 1a) has a specific set of Process Areas that are associated with distinct Maturity Levels.

In contrast to the staged architecture, a continuous model (see Figure 1b) has Capability Levels within PA’s. In the continuous representation of CMMI®, for example, each of the Process Areas has within it the Capability Levels of:

  • Incomplete (Level 0),
  • Performed (Level 1),
  • Managed (Level 2), and
  • Defined (Level 3)

The CMMI® is structured so that its content can be represented in either a staged or a continuous version.