Capability Maturity Model

The Capability Maturity Model (CMM) is a method for evaluating and measuring the
maturity of the software development process of organizations on a scale of 1 to 5.

The CMM was developed by the Software Engineering Institute (SEI) at Carnegie
Mellon University in Pittsburgh. It has been used extensively for avionics software and
for government projects since it was created in the mid-1980s.

The SEI has subsequently released a revised version known as the Capability Maturity
Model Integration (CMMI).

History: The term software originates from the idea that software is easy to change
("soft") in comparison to hardware, which was more difficult to change ("hard"). In the
1970s, the field of software development saw significant growth. Due to increased
complexity, the industry began to discover that software was not as easy to create or
change as the original term implied. Many software projects failed due to inadequate
processes and project management. The United States Air Force funded a study at the
SEI to create a model for the military to use as an objective evaluation of software
subcontractors. In 1989, the Capability Maturity Model was published as Managing the
Software Process.

Although these models have proved useful to many organizations, the use of multiple
models has been problematic. Further, applying multiple models that are not integrated
within and across an organization is costly in terms of training, appraisals, and
improvement activities. The CMM Integration project was formed to sort out the problem
of using multiple CMMs. The CMMI Product Team's mission was to combine three
source models:

1. The Capability Maturity Model for Software (SW-CMM) v2.0 draft C

2. The Systems Engineering Capability Model (SECM)
3. The Integrated Product Development Capability Maturity Model (IPD-CMM)
v0.98.

CMMI is the designated successor of the three source models. The SEI has released a
policy to sunset the Software CMM. The same can be said for the SECM and the IPD-
CMM. These models are expected to be succeeded by CMMI.

Levels of the CMM:

"Predictability, effectiveness, and control of an organization's software processes are

believed to improve as the organization moves up these five levels. While not rigorous,
the empirical evidence to date supports this belief."
Level 1 - Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually
does not provide a stable environment. Success in these organizations depends on the
competence and heroics of the people in the organization and not on the use of proven
processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations
often produce products and services that work; however, they frequently exceed the
budget and schedule of their projects.

Maturity level 1 organizations are characterized by a tendency to over commit, abandon

processes in the time of crisis, and not be able to repeat their past successes again.

Level 2 - Repeatable

At maturity level 2, Software development successes are repeatable. The organization

may use some basic project management to track cost and schedule.

Process discipline helps ensure that existing practices are retained during times of stress.
When these practices are in place, projects are performed and managed according to their
documented plans.

Project status and the delivery of services are visible to management at defined points
(for example, at major milestones and at the completion of major tasks).

Level 3 - Defined

At maturity level 3, processes are well characterized and understood, and are described in
standards, procedures, tools, and methods.

The organization’s set of standard processes, which is the basis for level 3, is established
and improved over time. These standard processes are used to establish consistency
across the organization. Projects establish their defined processes by the organization’s
set of standard processes according to tailoring guidelines.

The organization’s management establishes process objectives based on the

organization’s set of standard processes and ensures that these objectives are
appropriately addressed.

A critical distinction between level 2 and level 3 is the scope of standards, process
descriptions, and procedures. At level 2, the standards, process descriptions, and
procedures may be quite different in each specific instance of the process (for example,
on a particular project). At level 3, the standards, process descriptions, and procedures for
a project are tailored from the organization’s set of standard processes to suit a particular
project or organizational unit.
Level 4 - Managed

Using precise measurements, management can effectively control the software

development effort. In particular, management can identify ways to adjust and adapt the
process to particular projects without measurable losses of quality or deviations from
specifications.

Subprocesses are selected that significantly contribute to overall process performance.

These selected subprocesses are controlled using statistical and other quantitative
techniques.

A critical distinction between maturity level 3 and maturity level 4 is the predictability of
process performance. At maturity level 4, the performance of processes is controlled
using statistical and other quantitative techniques, and is quantitatively predictable. At
maturity level 3, processes are only qualitatively predictable.

Level 5 - Optimizing

Maturity level 5 focuses on continually improving process performance through both

incremental and innovative technological improvements. Quantitative process-
improvement objectives for the organization are established, continually revised to reflect
changing business objectives, and used as criteria in managing process improvement. The
effects of deployed process improvements are measured and evaluated against the
quantitative process-improvement objectives. Both the defined processes and the
organization’s set of standard processes are targets of measurable improvement activities.

Process improvements to address common causes of process variation and measurably

improve the organization’s processes are identified, evaluated, and deployed.

Optimizing processes that are agile and innovative depends on the participation of an
empowered workforce aligned with the business values and objectives of the
organization. The organization’s ability to rapidly respond to changes and opportunities is
enhanced by finding ways to accelerate and share learning.

A critical distinction between maturity level 4 and maturity level 5 is the type of process
variation addressed. At maturity level 4, processes are concerned with addressing special
causes of process variation and providing statistical predictability of the results. Though
processes may produce predictable results, the results may be insufficient to achieve the
established objectives. At maturity level 5, processes are concerned with addressing
common causes of process variation and changing the process (that is, shifting the mean
of the process performance) to improve process performance (while maintaining
statistical probability) to achieve the established quantitative process-improvement
objectives.
Extensions

Recent versions of CMMI from SEI indicate a "level 0", characterized as "Incomplete".
Many observers leave this level out as redundant or unimportant, but Pressman and others
make note of it.

 CMM level 0 (negligent)

 CMM level -1 (obstructive)
 CMM level -2 (contemptuous)
 CMM level -3 (undermining)

Process Areas

The CMMI contains several key process areas indicating the aspects of product
development that are to be covered by company processes.

Key Process Areas of the Capability Maturity Model Integration (CMMI)

Maturity
Abbreviation Name Area
Level
CAR Causal Analysis and Resolution Support 5
CM Configuration Management Support 2
DAR Decision Analysis and Resolution Support 3
Project
IPM Integrated Project Management 3
Management
Project
ISM Integrated Supplier Management 3
Management
Project
IT Integrated Teaming 3
Management
MA Measurement and Analysis Support 3
Organizational Environment for
OEI Support 3
Integration
Organizational Innovation and Process
OID 5
Deployment Management
Process
OPD Organizational Process Definition 3
Management
Process
OPF Organizational Process Focus 3
Management
Process
OPP Organizational Process Performance 4
Management
Process
OT Organizational Training 3
Management
PI Product Integration Engineering 3
Project
PMC Project Monitoring and Control 2
Management
 Project
PP Project Planning 2
Management
Process and Product Quality
PPQA Support 2
Assurance
Project
QPM Quantitative Project Management 4
Management
RD Requirements Development Engineering 3
REQM Requirements Management Engineering 2
Project
RSKM Risk Management 3
Management
Project
SAM Supplier Agreement Management 2
Management
TS Technical Solution Engineering 3
VAL Validation Engineering 3
VER Verification Engineering 3

Controversial aspects

The software industry is diverse and volatile. All methodologies for creating software
have supporters and critics, and the CMM is no exception.

Praise
 The CMM was developed to give Defense organizations a yardstick to assess and
describe the capability of software contractors to provide software on time, within
budget, and to acceptable standards. It has arguably been successful in this role,
even reputedly causing some software salespeople to clamour for their
organizations' software engineers/developers to "implement CMM."

 The CMM is intended to enable an assessment of an organization's maturity for

software development. It is an important tool for outsourcing and exporting
software development work. Economic development agencies in India, Ireland,
Egypt, and elsewhere have praised the CMM for enabling them to be able to
compete for US outsourcing contracts on an even footing.

Criticism
 CMM has failed to take off the world over. It's hard to tell exactly how wide
spread it is as the SEI only publishes the names and achieved levels of compliance
of companies that have requested this information to be listed. The most current
Maturity Profile for CMMI is available online.

 CMM is well suited for top heavy bureaucratic organizations such as government
agencies, large corporations and regulated monopolies where deference is given
to form over substance. CMM follows the old AT&T Joint Practice "perfect
form" mentality that assumes anyone, regardless of intellect, can produce
consistent output if they follow a cookbook recipe and fill out the forms properly.
 Lost in the process is all opportunity for creativty with the resulting output being a
sort of socialist mediocrity. If the organizations deploying CMM are large
enough, they may employ a team of CMM auditors reporting their results directly
to the executive level. (A practice encourage by SEI.) The use of auditors and
executive reports assures that the entire IT organization begins to focus on
perfectly completed forms rather than application development, client needs or
the marketplace. Assume when implementing CMM that the number of CMM
process managers to developers will increase exponentially. The CMM process
works best where time to market is unimportant. If the project is driven by a due
date, CMMs intensive reliance on process and forms becomes a hinderance to
meeting the due date and arbitrary decisions begin to be made by executive
management as to which processes are expendable... such as testing.

 Suggestions of scientifically managing the software process with metrics only

occur beyond the Fourth level. There is little validation of the processes cost
savings to business other than a vague reference to empirical evidence. It is
expected that a large body of evidence would show that adding all the business
overhead demanded by CMM somehow reduces IT headcount, business cost, and
time to market without sacrificing client needs.

 No external body actually certifies a software development center as being CMM

compliant. It is supposed to be an honest self-assessment.

 The CMM does not describe how to create an effective software development
organization. The CMM contains behaviors or best practices that successful
projects have demonstrated. Being CMM compliant is not a guarantee that a
project will be successful, however being compliant can increase a project's
chances of being successful.

 The CMM can seem to be overly bureaucratic, promoting process over substance.
For example, for emphasizing predictability over service provided to end users.
More commercially successful methodologies (for example, the Rational Unified
Process) have focused not on the capability of the organization to produce
software to satisfy some other organization or a collectively-produced
specification, but on the capability of organizations to satisfy specific end user
"use cases" as per the Object Management Group's UML (Unified Modeling
Language) approach.

 Whilst CMM may have been very positive for the employment of software
engineers in emerging or Third World economies - notably in India during the
early 2000s - it is regarded as having adversely affected the potential employment
opportunities for software engineers in the developed economies - notably the
USA and Europe. This outsourcing is a form of labor arbitrage which is similar to
the movement of manufacturing of (for example) fashion clothing or Nike shoes
to Third World economies with relatively cheap labor rates.
The most beneficial elements of CMM Level 2 and 3
 Creation of Software Specifications, stating what it is that is going to be
developed, combined with formal sign off, an executive sponsor and approval
mechanism. This is NOT a living document, but additions are placed in a deferred
or out of scope section for later incorporation into the next cycle of software
development.

 A Technical Specification, stating how precisely the thing specified in the

Software Specifications is to be developed will be used. This is a living
document.

 Peer Review of Code (Code Review) with metrics that allow developers to walk
through an implementation, and to suggest improvements or changes. Note - This
is problematic because the code has already been developed and a bad design can
not be fixed by "tweaking", the Code Review gives complete code a formal
approval mechanism.

 Version Control - a very large number of organizations have no formal revision

control mechanism or release mechanism in place.

 The idea that there is a "right way" to build software, that it is a scientific process
involving engineering design and that groups of developers are not there to simply
work on the problem du jour.