The Capability Maturity Model (CMM), also known as the Software CMM (SW-

CMM), was first described by Watts Humphrey in his book Managing the Software
Process. The CMM is a process model based on software best-practices effective in
large-scale, multi-person projects.

The CMM has been retired and not been updated in over 10 years. CMM has been
superseded by CMMI (Capability Maturity Model Integrated).

The CMM has been used to assess the maturity levels of organization areas as diverse as
software engineering, system engineering, project management, risk management, system
acquisition, information technology (IT) or personnel management, against a scale of
five key processes, namely: Initial, Repeatable, Defined, Managed and Optimized.

CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon
University in Pittsburgh. It has been used extensively for avionics software and
government projects around the world.
 What is the Capability Maturity Model?
There are many different applications of the Capability Maturity Models. Some of
these models target software development, staffing, etc. In this series I will focus on
the Systems Engineering Capability Maturity Model (CMM). The CMM is service
marked by the Software Engineering Institute (SEI) of Carnegie Mellon University
and was developed by the SEI, the Department of Defense and a host of other
entities.

Why is the CMM Valuable?

The CMM is valuable for several reasons.

1- It is simple and easy to understand; therefore, it speaks to the executives of

a corporation. Many corporate executives are already familiar with this model
and it is probable that your company’s executives are also familiar with it.
Over the years I have been able to successfully use this model to illustrate
major IT issues/concepts to senior executives.CMM to be a very valuable tool
for attaining project funding for key initiatives like enterprise data asset
management and meta data repository development.

2- Second, as you view the model it is intuitive that a company cannot currently
be ranked at a level 2 and directly jump to level 4. Instead, an organization
must first develop a strategy to elevate themselves to level 3.

3- Many large companies and government institutions are actively using this
model to compare themselves with other entities. In fact, many corporations
have goals centered on the CMM levels. Fourth, the model gives companies a
mechanism to compare themselves with other companies within their
industry.

 What is CMM?
• Framework that describes five (5) levels of maturity within the
software process
• Each maturity level within CMM is divided into Key Process Areas
(KPAs)
• Evolutionary improvement path from an ad hoc, immature
organization to a mature, disciplined organization
• CMM provides the framework. Each organization determines how to
meet the criteria of the framework
 CMM Benefits
• Creates a shared vision of software process improvement within an
organization
• Establishes a common language for the software process
• Defines a set of priorities for addressing software issues
• Supports measurement of the process by providing a framework for
reliable, consistent assessments
 CMM Focus
• Capability of organizations to produce high-quality products
consistently and predictably
• Inherent ability of process to produce planned results
• Process as a means to empower the people doing the work
The CMM model defines five levels of organizational maturity:

1. Initial level is a basis for comparison with the next levels. In an organization at
the initial level, conditions are not stable for the development of quality software.
The results of any project depend totally on the manager’s personal approach and
the programmers’ experience, meaning the success of a particular project can be
repeated only if the same managers and programmers are assigned to the next
project. In addition, if managers or programmers leave the company, the quality
of produced software will sharply decrease. In many cases, the development
process comes down to writing code with minimal testing.

2. Repeatable level. At this level, project management technologies have been

introduced in a company. That project planning and management is based on
accumulated experience and there are standards for produced software (these
standards are documented) and there is a special quality management group. At
critical times, the process tends to roll back to the initial level.

3. Defined level. Here, standards for the processes of software development and
maintenance are introduced and documented (including project management).
During the introduction of standards, a transition to more effective technologies
occurs. There is a special quality management department for building and
maintaining these standards. A program of constant, advanced training of staff is
required for achievement of this level. Starting with this level, the degree of
organizational dependence on the qualities of particular developers decreases and
the process does not tend to roll back to the previous level in critical situations.

4. Managed level. There are quantitative indices (for both software and process as a
whole) established in the organization. Better project management is achieved due
to the decrease of digression in different project indices. However, sensible
 variations in process efficiency may be different from random variations (noise),
especially in mastered areas.

5. Optimizing level. Improvement procedures are carried out not only for existing
processes, but also for evaluation of the efficiency of newly introduced innovative
technologies. The main goal of an organization on this level is permanent
improvement of existing processes. This should anticipate possible errors and
defects and decrease the costs of software development, by creating reusable
components for example.

CMM LEVEL DEFINITION WHEN TO USE

Little documentation and few

if any processes and
procedures are in place. Used for one of a kind projects
Level 1 - Chaos
Success is only achieved by of very limited scope.
the heroic actions of team
members.

Used for any project that will

Enough documentation exists
be done again, whether as an
Level 2 - Repeatability that the QA process is
upgrade or a somewhat similar
repeatable.
variation.

QA documentation and Critical for a QA department

processes & procedures are
Level 3 -
standardized. Templates exist
Standardization
for all documentation and a
QA "system" exists.
that must provide QA for
multiple projects. Avoids
reinventing the wheel for each
project.

The exact time & resources

required to provide adequate
QA for each product is known
Level 4 -
precisely so timetables and
Manageability
quality levels are met
consistently, and without
surprises.
Requires an existing data set
based on previous QA
projects. This level can only be
achieved by well documented
experience.

QA processes and procedures Actually should be used in

Level 5 - Optimization are understood well enough every Stage. By Level 5, this is
to be refined and streamlined. the only thing left to work on.
Misconceptions About Maturity Levels
Misconception #1: If you are at Level 1, you are pond scum. One problem with the
term "process maturity" is that if you are on the low end of the scale, you are "immature"
by definition. Some people object to the term "maturity" in this context because it sounds
like a value judgment, rather than being an objective appraisal of process capability.
The fact is that most software organizations are operating at the Initial level of the CMM
today, yet some of them are successful by many commonly accepted measures
(profitability, market share, customer satisfaction). However, other organizations are
struggling, delivering poor quality products (or nothing) with substantial cost and
schedule overruns.
Being Level 1 does not mean that the members of a software organization are barely
breathing (as one manager put it). It does mean that the organization's projects are likely
to have less predictability, more rework, more defects, and more schedule slippage than
those in a higher maturity organization. The CMM is concerned with organizational
process capability; it does not pass judgment on the performance or capabilities of
individual software practitioners.
Misconception #2: Level 2 is mostly about software engineering activities, such as
requirements analysis, design, coding, and testing. Actually, the Repeatable Level
addresses practices that relate to planning, managing, and tracking several fundamental
aspects of a software project (see Table 1). The standard software engineering tasks of
analysis, design, coding, testing, and documentation are all included in a large KPA called
Software Product Engineering at Level 3.
For an organization to have a repeatable process, the project management controls and
discipline that are provided by the Level 2 KPAs must first be established. Without a
foundation of disciplined project management, even effective software engineering
procedures may be abandoned during times of schedule pressure or rapidly changing
requirements.
Misconception #3: You have to perform all of the activities and practices defined at
some maturity level in order to achieve that level. Over 120 key practices are defined
for the Repeatable Level alone, counting the activities, commitments, abilities,
measurements, and verification steps. You do not have to perform every one of these
practices in order to achieve Level 2. However, you do need to demonstrate that you are
satisfying all of the goals that are defined for the applicable Level 2 KPAs. (If an
organization does not engage in subcontracting, the Software Subcontract Management
KPA is not applicable.) You may have alternative practices that accomplish the goals of a
KPA, but which are not mentioned in the CMM. The key practices are only a guideline-
not a requirement-for determining whether goals are satisfied.
Misconception #4: Software measurement is not required until you are approaching
Level 4. People having a superficial knowledge of the CMM may be aware that the
Managed Level addresses the quantitative measurement of software products and
processes. These people sometimes are surprised to learn that measurement is a part of
every KPA at every maturity level. The Measurement and Analysis common feature
provides a hint to this effect.
Most of these measurements determine the status of activities associated with application
of the KPA. Consider the Requirements Management KPA. You should measure the
status of each requirement, the effort spent on requirements management activities, and
requirements stability (the frequency of change of the requirements). At the higher
maturity levels, metrics are increasingly used to monitor progress and manage projects
proactively. However, software groups at all maturity levels should begin incorporating
fundamental software metrics into their routine operating practices.
Misconception #5: The SEI certifies an organization at a specific maturity level.
There is no such thing as being "SEI-certified," and there is no certification associated
with achieving a specific CMM maturity level. Perhaps this misunderstanding arises
because some people erroneously refer to CMM-based process appraisals as "audits," and
certain audits do result in a certification of some sort. The SEI maintains a database of
accumulated results from formal process appraisals, but it will not divulge the results for
any specific organization.