Capability Maturity Model

The Capability Maturity Model (CMM) is a service mark owned by Carnegie Mellon
University (CMU) and refers to a development model elicited from actual data. The data
was collected from organizations that contracted with the U.S. Department of Defense,
who funded the research, and became the foundation from which CMU created the
Software Engineering Institute (SEI). Like any model, it is an abstraction of an existing
system.When it is applied to an existing organization's software development processes,
it allows an effective approach toward improving them. Eventually it became clear that
the model could be applied to other processes. This gave rise to a more general concept
that is applied to business processes and to developing people.

Overview

The Capability Maturity Model (CMM) was originally developed as a tool for objectively
assessing the ability of government contractors' processes to perform a contracted
software project. The CMM is based on the process maturity framework first described in
the 1989 book Managing the Software Process by Watts Humphrey. It was later
published in a report in 1993 (Technical Report CMU/SEI-93-TR-024 ESC-TR-93-177
February 1993, Capability Maturity Model SM for Software, Version 1.1) and as a book
by the same authors in 1995.

Though the CMM comes from the field of software development, it is used as a general
model to aid in improving organizational business processes in diverse areas; for example
in software engineering, system engineering, project management, software maintenance,
risk management, system acquisition, information technology (IT), services, business
processes generally, and human capital management. The CMM has been used
extensively worldwide in government, commerce, industry and software development
organizations.

Rated organizations

An organization may be assessed by an SEI-Authorized Lead Appraiser, and will then be

able to claim that they have been assessed as CMM level X, where X is from 1 to 5.
Although sometimes called CMM-certification, the SEI doesn't use this term due to
certain legal implications.

The SEI maintains a list of organizations assessed for CMM since 2006.[1]

Among the first organizations to receive the highest CMM rating were many India based
software offshoring companies.
History
Prior need for software processes

In the 1970s, the use of computers grew more widespread, flexible and less costly.
Organizations began to adopt computerized information systems, and the demand for
software development grew significantly. The processes for software development were
in their infancy, with few standard or "best practice" approaches defined.

As a result, the growth was accompanied by growing pains: project failure was common,
and the field of computer science was still in its infancy, and the ambitions for project
scale and complexity exceeded the market capability to deliver. Individuals such as
Edward Yourdon, Larry Constantine, Gerald Weinberg, Tom DeMarco, and David
Parnas began to publish articles and books with research results in an attempt to
professionalize the software development process.

In the 1980s, several US military projects involving software subcontractors ran over-
budget and were completed far later than planned, if at all. In an effort to determine why
this was occurring, the United States Air Force funded a study at the SEI.

Precursor

The Quality Management Maturity Grid was developed by Philip B. Crosby in his book
"Quality is Free".[2]

The first application of a staged maturity model to IT was not by CMM/SEI, but rather by
Richard L. Nolan, who, in 1973 published the stages of growth model for IT
organizations.[3]

Watts Humphrey began developing his process maturity concepts during the later stages
of his 27 year career at IBM. (References needed)

Development at SEI

Active development of the model by the US Department of Defense Software

Engineering Institute (SEI) began in 1986 when Humphrey joined the Software
Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania
after retiring from IBM. At the request of the U.S. Air Force he began formalizing his
Process Maturity Framework to aid the U.S. Department of Defense in evaluating the
capability of software contractors as part of awarding contracts.

The result of the Air Force study was a model for the military to use as an objective
evaluation of software subcontractors' process capability maturity. Humphrey based this
framework on the earlier Quality Management Maturity Grid developed by Philip B.
Crosby in his book "Quality is Free".[2] However, Humphrey's approach differed because
of his unique insight that organizations mature their processes in stages based on solving
process problems in a specific order. Humphrey based his approach on the staged
evolution of a system of software development practices within an organization, rather
than measuring the maturity of each separate development process independently. The
CMM has thus been used by different organizations as a general and powerful tool for
understanding and then improving general business process performance.

Watts Humphrey's Capability Maturity Model (CMM) was published in 1988[4] and as a
book in 1989, in Managing the Software Process.[5]

Organizations were originally assessed using a process maturity questionnaire and a

Software Capability Evaluation method devised by Humphrey and his colleagues at the
Software Engineering Institute (SEI).

The full representation of the Capability Maturity Model as a set of defined process areas
and practices at each of the five maturity levels was initiated in 1991, with Version 1.1
being completed in January 1993.[6] The CMM was published as a book[7] in 1995 by its
primary authors, Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis.

Superseded by CMMI

The CMM model proved useful to many organizations, but its application in software
development has sometimes been problematic. Applying multiple models that are not
integrated within and across an organization could be costly in training, appraisals, and
improvement activities. The Capability Maturity Model Integration (CMMI) project was
formed to sort out the problem of using multiple CMMs.

For software development processes, the CMM has been superseded by Capability
Maturity Model Integration (CMMI), though the CMM continues to be a general
theoretical process capability model used in the public domain.

Adapted to other processes

The CMM was originally intended as a tool to evaluate the ability of government
contractors to perform a contracted software project. Though it comes from the area of
software development, it can be, has been, and continues to be widely applied as a
general model of the maturity of processes (e.g., IT service management processes) in
IS/IT (and other) organizations.

Model topics
Maturity model

A maturity model can be viewed as a set of structured levels that describe how well the
behaviours, practices and processes of an organisation can reliably and sustainably
produce required outcomes. A maturity model may provide, for example :

• a place to start
• the benefit of a community’s prior experiences
• a common language and a shared vision
• a framework for prioritizing actions.
 • a way to define what improvement means for your organization.

A maturity model can be used as a benchmark for comparison and as an aid to

understanding - for example, for comparative assessment of different organizations where
there is something in common that can be used as a basis for comparison. In the case of
the CMM, for example, the basis for comparison would be the organizations' software
development processes.

Structure

The Capability Maturity Model involves the following aspects:

• Maturity Levels: a 5-Level process maturity continuum - where the uppermost

(5th) level is a notional ideal state where processes would be systematically
managed by a combination of process optimization and continuous process
improvement.
• Key Process Areas: a Key Process Area (KPA) identifies a cluster of related
activities that, when performed together, achieve a set of goals considered
important.
• Goals: the goals of a key process area summarize the states that must exist for
that key process area to have been implemented in an effective and lasting way.
The extent to which the goals have been accomplished is an indicator of how
much capability the organization has established at that maturity level. The goals
signify the scope, boundaries, and intent of each key process area.
• Common Features: common features include practices that implement and
institutionalize a key process area. There are five types of common features:
commitment to Perform, Ability to Perform, Activities Performed, Measurement
and Analysis, and Verifying Implementation.
• Key Practices: The key practices describe the elements of infrastructure and
practice that contribute most effectively to the implementation and
institutionalization of the KPAs.

Levels

There are five levels defined along the continuum of the CMM[8] and, according to the
SEI: "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."

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new
process.
2. Managed - the process is managed in accordance with agreed metrics.
3. Defined - the process is defined/confirmed as a standard business process, and
decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Quantitatively managed
5. Optimizing - process management includes deliberate process
optimization/improvement.
Within each of these maturity levels are Key Process Areas (KPAs) which characterise
that level, and for each KPA there are five definitions identified:

1. Goals
2. Commitment
3. Ability
4. Measurement
5. Verification

The KPAs are not necessarily unique to CMM, representing — as they do — the stages
that organizations must go through on the way to becoming mature.

The CMM provides a theoretical continuum along which process maturity can be
developed incrementally from one level to the next. Skipping levels is not
allowed/feasible.

N.B.: The CMM was originally intended as a tool to evaluate the ability of government
contractors to perform a contracted software project. It has been used for and may be
suited to that purpose, but critics pointed out that process maturity according to the CMM
was not necessarily mandatory for successful software development. There were/are real-
life examples where the CMM was arguably irrelevant to successful software
development, and these examples include many Shrinkwrap companies (also called
commercial-off-the-shelf or "COTS" firms or software package firms). Such firms would
have included, for example, Claris, Apple, Symantec, Microsoft, and Lotus. Though these
companies may have successfully developed their software, they would not necessarily
have considered or defined or managed their processes as the CMM described as level 3
or above, and so would have fitted level 1 or 2 of the model. This did not - on the face of
it - frustrate the successful development of their software.

Level 1 - Initial (Chaotic)

It is characteristic of processes at this level that they are (typically) undocumented
and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled
and reactive manner by users or events. This provides a chaotic or unstable
environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable,
possibly with consistent results. Process discipline is unlikely to be rigorous, but
where it exists it may help to ensure that existing processes are maintained during
times of stress.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and
documented standard processes established and subject to some degree of
improvement over time. These standard processes are in place (i.e., they are the
AS-IS processes) and used to establish consistency of process performance across
the organization.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics,
management can effectively control the AS-IS process (e.g., for software
 development ). In particular, management can identify ways to adjust and adapt
the process to particular projects without measurable losses of quality or
deviations from specifications. Process Capability is established from this level.
Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually
improving process performance through both incremental and innovative
technological changes/improvements.

At maturity level 5, processes are concerned with addressing statistical common causes of
process variation and changing the process (for example, to shift the mean of the process
performance) to improve process performance. This would be done at the same time as
maintaining the likelihood of achieving the established quantitative process-improvement
objectives.

Software process framework

The software process framework documented is intended to guide those wishing to assess
an organization/projects consistency with the CMM. For each maturity level there are
five checklist types:

TypeSD Description
Describes the policy contents and KPA goals recommended by the
Policy
CMM.
Describes the recommended content of select work products
Standard
described in the CMM.
Describes the process information content recommended by the
CMM. The process checklists are further refined into checklists for:

• roles
• entry criteria
• inputs
• activities
• outputs
Process
• exit criteria
• reviews and audits
• work products managed and controlled
• measurements
• documented procedures
• training

• tools
Describes the recommended content of documented procedures
Procedure
described in the CMM.
Level Provides an overview of an entire maturity level. The level overview
overview checklists are further refined into checklists for:

• KPA purposes (Key Process Areas)

• KPA Goals
 • policies
• standards
• process descriptions
• procedures
• training
• tools
• reviews and audits
• work products managed and controlled

• measurements

Cyclomatic complexity (or conditional complexity) is a software

metric (measurement). It was developed by Thomas J. McCabe, Sr. in 1976 and is used to
indicate the complexity of a program. It directly measures the number of linearly
independent paths through a program's source code. The concept, although not the
method, is somewhat similar to that of general text complexity measured by the Flesch-
Kincaid Readability Test.

Cyclomatic complexity is computed using the control flow graph of the program: the
nodes of the graph correspond to indivisible groups of commands of a program, and a
directed edge connects two nodes if the second command might be executed immediately
after the first command. Cyclomatic complexity may also be applied to individual
functions, modules, methods or classes within a program.

One testing strategy, called Basis Path Testing by McCabe who first proposed it, is to
test each linearly independent path through the program; in this case, the number of test
cases will equal the cyclomatic complexity of the program.[1

Description

A control flow graph of a simple program. The program begins executing at the red node,
then enters a loop (group of three nodes immediately below the red node). On exiting the
loop, there is a conditional statement (group below the loop), and finally the program
exits at the blue node. For this graph, E = 9, N = 8 and P = 1, so the cyclomatic
complexity of the program is 3.

The cyclomatic complexity of a section of source code is the count of the number of
linearly independent paths through the source code. For instance, if the source code
contained no decision points such as IF statements or FOR loops, the complexity would
be 1, since there is only a single path through the code. If the code had a single IF
statement containing a single condition there would be two paths through the code, one
path where the IF statement is evaluated as TRUE and one path where the IF statement is
evaluated as FALSE.
Mathematically, the cyclomatic complexity of a structured program[note 1] is defined with
reference to a directed graph containing the basic blocks of the program, with an edge
between two basic blocks if control may pass from the first to the second (the control
flow graph of the program). The complexity is then defined as:[2]

M = E − N + 2P

where

M = cyclomatic complexity
E = the number of edges of the graph
N = the number of nodes of the graph
P = the number of connected components

The same function as above, shown as a strongly-connected control flow graph, for
calculation via the alternative method. For this graph, E = 10, N = 8 and P = 1, so the
cyclomatic complexity of the program is still 3.

An alternative formulation is to use a graph in which each exit point is connected back to
the entry point. In this case, the graph is said to be strongly connected, and the cyclomatic
complexity of the program is equal to the cyclomatic number of its graph (also known as
the first Betti number), which is defined as:[2]

M=E−N+P

This may be seen as calculating the number of linearly independent cycles that exist in
the graph, i.e. those cycles that do not contain other cycles within themselves. Note that
because each exit point loops back to the entry point, there is at least one such cycle for
each exit point.

For a single program (or subroutine or method), P is always equal to 1. Cyclomatic

complexity may, however, be applied to several such programs or subprograms at the
same time (e.g., to all of the methods in a class), and in these cases P will be equal to the
number of programs in question, as each subprogram will appear as a disconnected subset
of the graph.

It can be shown that the cyclomatic complexity of any structured program with only one
entrance point and one exit point is equal to the number of decision points (i.e., 'if'
statements or conditional loops) contained in that program plus one.[2][3]

Cyclomatic complexity may be extended to a program with multiple exit points; in this
case it is equal to:

π-s+2

where π is the number of decision points in the program, and s is the number of exit
points.[3][4]
Cyclomatic complexity is generally measured in units of Issac

Formal definition

Formally, cyclomatic complexity can be defined as a relative Betti

number, the size of a relative homology group:

which is read as “the first homology of the graph G, relative to the terminal nodes t”. This
is a technical way of saying “the number of linearly independent paths through the flow
graph from an entry to an exit”, where:

• “linearly independent” corresponds to homology, and means one does not double-
count backtracking;
• “paths” corresponds to first homology: a path is a 1-dimensional object;
• “relative” means the path must begin and end at an entry or exit point.

This corresponds to the intuitive notion of cyclomatic complexity, and can be calculated
as above.

Alternatively, one can compute this via absolute Betti number (absolute homology – not
relative) by identifying (gluing together) all terminal nodes on a given component (or
equivalently, draw paths connecting the exits to the entrance), in which case (calling the
new, augmented graph , which is ), one obtains:

This corresponds to the characterization of cyclomatic complexity as “number of loops

plus number of components”.

Etymology / Naming

The name Cyclomatic Complexity presents some confusion, as this metric does not only
count cycles (loops) in the program. Instead, the name refers to the number of different
cycles in the program control flow graph, after having added an imagined branch back
from the exit node to the entry node.[2]

A better name for popular usage would be Conditional Complexity, as "it has been
found to be more convenient to count conditions instead of predicates when calculating
complexity".[5]

Applications
Limiting complexity during development

One of McCabe's original applications was to limit the complexity of routines during
program development; he recommended that programmers should count the complexity
of the modules they are developing, and split them into smaller modules whenever the
cyclomatic complexity of the module exceeded 10.[2] This practice was adopted by the
NIST Structured Testing methodology, with an observation that since McCabe's original
publication, the figure of 10 had received substantial corroborating evidence, but that in
some circumstances it may be appropriate to relax the restriction and permit modules
with a complexity as high as 15. As the methodology acknowledged that there were
occasional reasons for going beyond the agreed-upon limit, it phrased its
recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-
upon limit] or provide a written explanation of why the limit was exceeded."[6]

Implications for Software Testing

Another application of cyclomatic complexity is in determining the number of test cases

that are necessary to achieve thorough test coverage of a particular module.

It is useful because of two properties of the cyclomatic complexity, M, for a specific

module:

• M is an upper bound for the number of test cases that are necessary to achieve a
complete branch coverage.
• M is a lower bound for the number of paths through the control flow graph (CFG).
Assuming each test case takes one path, the number of cases needed to achieve
path coverage is equal to the number of paths that can actually be taken. But some
paths may be impossible, so although the number of paths through the CFG is
clearly an upper bound on the number of test cases needed for path coverage, this
latter number (of possible paths) is sometimes less than M.

All three of the above numbers may be equal: branch coverage cyclomatic complexity
number of paths.

For example, consider a program that consists of two sequential if-then-else statements.

if( c1() )
f1();
else
f2();

if( c2() )
f3();
else
f4();

The control flow graph of the source code above; the red circle is the entry point of the
function, and the blue circle is the exit point. The exit has been connected to the entry to
make the graph strongly connected.

In this example, two test cases are sufficient to achieve a complete branch coverage,
while four are necessary for complete path coverage. The cyclomatic complexity of the
program is 3 (as the strongly-connected graph for the program contains 9 edges, 7 nodes
and 1 connected component).

In general, in order to fully test a module all execution paths through the module should
be exercised. This implies a module with a high complexity number requires more testing
effort than a module with a lower value since the higher complexity number indicates
more pathways through the code. This also implies that a module with higher complexity
is more difficult for a programmer to understand since the programmer must understand
the different pathways and the results of those pathways.

Unfortunately, it is not always practical to test all possible paths through a program.
Considering the example above, each time an additional if-then-else statement is added,
the number of possible paths doubles. As the program grew in this fashion, it would
quickly reach the point where testing all of the paths was impractical.

One common testing strategy, espoused for example by the NIST Structured Testing
methodology, is to use the cyclomatic complexity of a module to determine the number
of white-box tests that are required to obtain sufficient coverage of the module. In almost
all cases, according to such a methodology, a module should have at least as many tests
as its cyclomatic complexity; in most cases, this number of tests is adequate to exercise
all the relevant paths of the function.[6]

As an example of a function that requires more than simply branch coverage to test
accurately, consider again the above function, but assume that to avoid a bug occurring,
any code that calls either f1() or f3() must also call the other.[note 2] Assuming that the
results of c1() and c2() are independent, that means that the function as presented above
contains a bug. Branch coverage would allow us to test the method with just two tests,
and one possible set of tests would be to test the following cases:

• c1() returns true and c2() returns true

• c1() returns false and c2() returns false

Neither of these cases exposes the bug. If, however, we use cyclomatic complexity to
indicate the number of tests we require, the number increases to 3. We must therefore test
one of the following paths:

• c1() returns true and c2() returns false

• c1() returns false and c2() returns true

Either of these tests will expose the bug.

Cohesion

One would also expect that a module with higher complexity would tend to have lower
cohesion (less than functional cohesion) than a module with lower complexity. The
possible correlation between higher complexity measure with a lower level of cohesion is
predicated on a module with more decision points generally implementing more than a
single well defined function. A 2005 study showed stronger correlations between
complexity metrics and an expert assessment of cohesion in the classes studied than the
correlation between the expert's assessment and metrics designed to calculate cohesion.[7]

Correlation to number of defects

A number of studies have investigated cyclomatic complexity's correlation to the number

of defects contained in a module. Most such studies find a strong positive correlation
between cyclomatic complexity and defects: modules that have the highest complexity
tend to also contain the most defects. For example, a 2008 study by metric-monitoring
software supplier Enerjy analyzed classes of open-source Java applications and divided
them into two sets based on how commonly faults were found in them. They found strong
correlation between cyclomatic complexity and their faultiness, with classes with a
combined complexity of 11 having a probability of being fault-prone of just 0.28, rising
to 0.98 for classes with a complexity of 74.[8]

However, studies that control for program size (i.e., comparing modules that have
different complexities but similar size, typically measured in lines of code) are generally
less conclusive, with many finding no significant correlation, while others do find
correlation. Some researchers who have studied the area question the validity of the
methods used by the studies finding no correlation.[9]

Les Hatton claimed recently (Key note at TAIC-PART 2008, Windsor, UK, Sept 2008)
that McCabe Cyclomatic Complexity has the same prediction ability as lines of code.[10]