• Home
• About
• Services
• PDPI^SM
• Models
• Results
• Reference
• Contact

• PDPI^SM
• Motive
• Model
• Method
• Managing Change
• Measures

PDPI^SM | Model

Which reference model best maps to the organization practices under consideration?

A reference model or process standard is often used either as a standard of comparison or as a source of ideas for good practices. There are many improvement or process models available which are intended to address an organization’s critical issues. The Software CMM^®, System Engineering CMM^® and ISO 9000 series of standards were the starting points for many of the later models and standards. The CMMI^® is the model of choice for many organizations which develop products involving both hardware and software. While the Software CMM^® is no longer supported by SEI, MDM can offer consulting support for organizations desiring to continue to use it as their model of choice.

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^® will address acquisition practices and providing services.

Model Architecture

The architecture of a model refers to its underlying structure and the relationship of maturity levels and process areas. A staged model (see Figure 1a) has specific PAs that are associated with distinct maturity levels. For example, in the staged representation of CMMI^®, Requirements Management is a Maturity Level 2 PA, while the Requirements Development PA is Level 3.

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 such as Technical Solution or Configuration Management, has within it the Capability Levels of:

• Incomplete (Level 0),
• Performed (Level 1),
• Managed (Level 2),
• Defined (Level 3),
• Quantitatively Managed (Level 4), and
• Optimizing (Level 5).

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

Choosing the right model.