Capability Maturity Model for Software, Version 1.1

Full text

AD-A263
403
Capability Maturity
Model
for
Software,
Version
1.1
Mark
C.
Paulk
Bill.
Curtis
Mary
Beth
Chrissis
Charles
V.
Weber
D
AP,?
93-08746
• 0~~~~~K;
L
5
(II
I
Il
llIII'J,',
j

February
1993
CMU/SEI-93-TR-24
ESC-TR-93-177
Capability
Maturity
Model
for
Software,
Version
1.1
Mark
C.
Paulk
Bill
Curtis
Mary
Beth
Chrissis
Charles
V.
Weber
Approved
for
public
ielease
Distribution
unlimited
Software
Engineering
Institute
Carnegie
Mellon
University
Pittsburgh,
Pennsylvania
15213

This technical
report
was prepared
for
the
SEI
Joint Program
Office
ESC/AVS
Hanscom
AFB,
MA
01731
The
ideas
and
findings
in
this
report
should
not
be
construed
az
an
official
DoD
position.
It
is
published
in
the
interest
of
scientific
and
technica!
information
exchange.
Review
and
Approval
This report
has been
reviewed
and
is
approved
for
publication.
FOR
THE
COMMANDER
Thomas
R.
Miller,
Lt
Col,
USAF
SEI
Joint Program
Office
The Software
Engineering
Institute
is
sponsored
by
the
U.S.
Department
of
Defense.
This
report
was
funded
by
the
U.S.
Department
of
Defense.
Copyright
©
1993
by
Carnegie
Mellon
University.
This
document
Is
available
through
the
Defense
Technical
Information
Center.
DTIC
provides
access
to
and
transfer
of
scientific
and
technical
information
for
DoD
personnel,
DoD
contractors and
potential
contractors,
and
other
U.S.
Government
agency
personnel and
their
contractors.
To
obtain
a
copy,
please
contact
DTIC
directly:
Defense
Technical
Information
Center,
Attm:
FDRA,
Cameron
Station,
Alexandria,
VA
22304-6145.
Copies
of
this
document
are
also
available
through
the
National
Technical
Informat'on
Service.
For
information
on
nrdering,
please
contact
NTIS
directly: National
Technical
Information
Service,
U.S.
Department
of
Commerce,
Springfield,
VA
22161.
Copies
of
this
document are also
available
from
Research
Access,
Inc.,
3400
Forbes
Avenue,
Suite
302,
Pittsburgh,
PA
15213.
Use
of
any
trademarks
in
this
report
is
not
intended
in
any
way
to
infringe on
the
rights
of
the trademark
holder.
W

_ _
Carnegie
Mellon
University
-
Software
Engineering Institute
Permission
to
reproduce,
in
whole
or
in
part,
the
volume
of
materials
released
by
the
Software
Engineering
Institute
under
the
title
Capability
Maturity
Model
for
Software
is
granted
under
the
following
conditions:
1.
This
letter
must
be
reproduced
with
each
copy.
2.
All
copies
must
include
the
copyright
notice.
3.
The
materials
are
not
to
be
used
for
commercial
gain.
4.
The
materials
are
not
to
be
distributed
beyond
your
organization.
Refer
such
requests
to
the
SEI.
5.
The
materiais
are
to
be
used
in
a
manner
consistent
with
the
framework
and
methodology
advanced
by
the
SEI.
6.
Carnegie
Mellon
University
and
the
Software
Engineering
Institute
are
not
to
be
construed
as
responsible
for
the
results
of
analyses
conducted
as
a
result
of
this
permini,.ion.
In
other
words,
neither
CMU
nor
the
SEI
is
to
be
held
liable
for
your
use
of
this material.
Sincec
Purvis
M.
Jackson
Sr.
Editor
and
Director
SEI
Information
Management
A.Ooession
F#or
NTTS'.A~
DTTcýi.B
J:•:t
t;
[:;;. •
Pittsburgh,
Pennsylvania
15213-3890
(412)
268-7700
I I
"(412)-68-7700.-.,,• •

*
Table
of
Contents
A
cknow
ledgm
ents
.......................................................................................................
v
T
o
the
R
ead
ey%
..........................................................................................................
v
ii
W
hat
is
tite
Purpose
of
This
Paper?
.....................................................................
viii
W
ho
Should
Read
This
Paper?
............................................................................
viii
I-low
is
This
Paper
Organized?
...........................................................................
ix
.Vhat
Are the
Other
CMM
Products?
................................................................
x
How
Do
You
Receive
More
Information?
..
'...........................................
.
xi
1
The
Process
Maturity Framework
............................. 1
1.1
Immature
Versus
Mature
Sodfware
Organizations
..........................
I
'
Fundamental
Concepts
Underlying
Process
Maturity
.....................
3
Overview
'hf ehe
C
lixh'y
Maturity
Model
.....................................
4
2
.e
Five
Levels
.f
Soft.
e Proce,•s
Maturity
..........................................
7
2.1
Behavioral
Charact
zation
of
the
Maturity
Levels
.......................
9
2.1.1
Level
1 -
The
initial
Level
.......................................................
10
2.1.2
Level
2
-
The
Repeatable
Level
...............................................
10
2.1.3
Level
3
-
The
Defined
Level
...........................................................
11
2.1.4
Level
4
-
The
Managed
Level
..................................................
12
2.1.5
Level
5
-
The
Optimizing
Level
.............................................
13
2.2
Understanding
the
Maturity
Levels
..................................................
14
2.2.1
Understanding
the Initial
Level
.............................................
15
2.2.2
Understanding
the
Repeatable
and
Defined
Levels
............
15
2.2.3
Understanding
the
Managed
and
Optimizing
Levels
..... 16
2.3
Visibility
Into
the
Software
Process
....................................................
19
2.4
Process
Capability
and
the
Prediction
of
Performance
...................
22
2.5
Skipping
M
aurity
Levels
........................................
.............................
25
3
Operational
Definition
of
the
Capability Maturity
Model
.....................
27
3.1
Internal
Structure
of
the
Maturity
Levels
........................................
27
3.2
Maturity
Levels
............................................
30
3.3
Key
Process
A
reas
..................................................................................
30
3.4
Com
m
on
Features
.................................................................................
37
3.5
K
ey Practices
...........................................................................................
39
4
U
sing
the
C
M
M
................................................................................................
43
4.1
Software Process
Assessment
and
Software
Capability
Evaluation
M
ethods
.............................................................................. 44
4.2
Differences Between
Software
Process
Assessments
and
Software
Capability
Evaluations
........................................................
47
4.3
Other
Uses
of
the
CMM
in
Process
Improvement
.........................
49
CMUISEI-93-TR-24
Capability
Maturity
Model
* i

Table
of
Contents
-
5
Future
Directions
of
the
CMM
.....................................................
51
5.1
What
the
CMM
Does
Not
Cover
............................................
51
5.2
Near-Term
Activities
..........................................................
51
5.3
Long-Term Activities
..........................................................
52
5.4
Conclusion.......................................................................
53
6
References...............................................................................
55
Appendix
A:
Goals for
Each
Key
Process
Area
.................................
59
A.1
The
Key
Process
Areas
for Level
2:
Repeatable
..........................
59
A.2
The
Key
Process
Areas
for
Level
3:
Defi
1
ied..............................
61
A.3
The
Key
Process Areas
for
Level
4:
Managed
............................
62
A.4
The
Key
Process
Areas
for
Level
5:
Optimizing.........................
63
*i
Capability
Maturity
Model
CMLUISEI-91-TR-24

*
List
of
Figrures
Figure
2.1
The
Five Levels
of
Software
Process
Maturity
........................
8
Figure
2.2
The
Juran
Trilogy
Diagram:
Quality
Planning,
Quality
Control,
and Quality
Improvement....................................
17
Figure
2.3
A
Management
View
of
Visibility
into
the
Software
Proce~ss
at
Each
Maturity
Level
....................................................
20
Figure
2.4
Process
Capability
as
Indicated
by
Maturity
Level
...................
23
Figure
3.1
The
CMM
Structure
.......................................................
29
Figure
3.2
The
Key
Process
Areas
by
Maturity
Level
..............................
31
Figure
3.3
Building
the
CMM
Structure:
An
Example
of
a
Key
Practice
....
40
Figure
4.1
Common
Steps
in
Software
Process
Assessments
and
Software
Capability
Evaluations.........................................
45
* CM
UISEI-93-TR-24
Capability
Maturity
Model
m
iii

List
of Figures
iv
*
Capability
Maturity
Model
CMUI/SEI-91-TR-24

*
Acknowledgments
The
description
of
the
Capability Maturity
Model for Software
was
initially
produced
by
a
dedicated
group
of
people
who
spent
many
hours
discussing
the
model
and its features
and
then
trying
to
document
it in
CMM
vl.0.
This
group
consisted
of
Mark
Paulk,
Bill
Curtis,
Mary
Beth
Chrissis,
Edward
Averill,
Judy
Bamberger,
Tim Kasse, Mike
Konrad,
Jeff
Perdue,
Charlie
Weber,.
and
Jim
Withey.
This
paper
is
based
on
the
vision of
Watts
Humphrey,
first
director
of
the
SEI's
Software
Process
Program.
It
took
several
drafts
to
evolve
this
paper
into
the
final
product.
Jim
Withey,
Mark
Paulk,
and
Cynthia
Wise
produced
an
early
draft
in
1990.
Watts
Humphrey
provided
a
second
draft
of
the
document,
and
Mark
Paulk
then
took
over
the
paper
and
remained
book
boss
until
the
end.
Mary
Beth
Chrissis
and
Bill
Curtis
helped
Mark
preduce
the
CMM
vl.0
revision
of
this
paper
in
August,
1991.
Mark
Paulk
produced
the
CMM
v1.1
revision
of
the
paper,
which
is
this
technical
report.
0
At
various
stages,
several
people
contributed
to
the
concepts
expressed
in
this
paper.
They
inchde
Joe
Besselman,
Marilyn
Bush,
Anita Carleton,
Marty
Carlson,
Betty
Deimel,
Suzie
Garcia,
Richard
Kauffold,
Steve
Masters,
Mary
Merrill,
Jim
Over,
George
Pandelios,
Jane
Siegel
and
Charlie Weber.
We
appreciate
the
administrative
help
from
Todd
Bowman,
Dorothy
Josephson,
Debbie
Punjack,
Carolyn
Tady,
Marcia
Theoret,
Andy
Tsounos,
and
David
White;
and
the
editorial
assistance from
Mary
Beth
Chrissis,
Suzanne
Couturiaux, and
Bill
Pollak.
Renne
Dutkowski
from
the
American
Institutes
for
Research
provided
suggestions
for
the
design
of
the
document.
S
CMU/SEI-93-TR-24
Capability
Maturity
Model
m
v

Acknowledgments
vi
m
Capability
Maturity
Model
CMUISEI-93-TR-24

*
To
the
Reader
In
November
1986,
the
Software
Engineering
Institute
(SEI),
with
assistance
from
the
Mitre
Corporation,
began
developing
a
process
maturity
framework
that
would help
organizations improve
"'teir
software
process.
This
effort
was
initiated
in
response
to
a
request
to
provide
the
federal
government
with
a
method
for
assessing
the
capability
of
its
software
contractors.
In
September
1987,
the
SEI
released
a
brief
description
of
the
process
maturity
framework
[Humphrey
87a]
and
a
maturity
questionnaire
[Humphrey82'b].
The
SEI
intended
the
maturity
questionnaire
to
provide
a
simple
tool
for
identifying
areas
where
an
organization's
software process
needed
improvement. Unfortunately,
the
maturity
questionnaire
was
too
often
regarded
as
"the
model"
rather
than
as
a
vehicle
for
exploring
process
maturity
issues.
After
four
years
of
experience
with
the
software
process
maturity
framework
and
the
preliminary
version
of the
maturity
questionnaire,
the
SEI
evolved
the software
process
maturity
framework
into
the
Capability
Maturity
Model
for
Software
(CMM)
[Paulk9l,
Weber9l].
The CMM
is
based
on
knowledge
acquired
from
software
process
assessments
and
extensive
feedback
from
both
industry
and government.
By
elaborating the
maturity
framework,
a
model
has
emerged
that
provides
organizations
with
more
effective
guidance
for
establishing
process
improvement
programs.
The
initial
release
of
the
CMM,
Version
1.0,
was
reviewed
and
used
by
the
software community
during
1991
and
1992.
A
workshop
was
held
in
April,
1992
on
CMM
v1.0,
which
was
attended
by
about
200
software
professionals.
This
version
of
the
CMM,
Version
1.1,
is
the
result
of
the
feedback from
that
workshop
and
ongoing
feedback
from
the
software
community.
The
CMM
is
the
foundation
for
systematically
building
a
set
of
tools,
including
a
maturity
questionnaire,
which
are
useful
in
software process
improvement.
The
essential
point
to
remember
is
that
the
model, not
a
questionnaire,
is
the
basis
for
improving
the
software
process.
This
paper
is
intended
to
introduce
the
reader
to
CMM
v1.1.
.
CM
LI/SEI-93-TR-24
Capability
Maturity
Model
ovii

To
the
Reader
What is
the
Purpose
of
This Paper?
This
paper
provides
a
technical
overview
of
the
Capability
Maturity
Model
for
Software
and
reflects Version
1.1.
Specifically,
this
paper
describes
the
process
maturity
framework
of
five
maturity
levels,
the
structural
components
that
comprise
the
CMM,
how
the
CMM
is
used
in
practice,
and
future
directions
of
the
CMM.
This
paper
serves
as
one
of
the
best
sources
for
understanding
the
CMM,
and
it
should
clear
up
some
of
the
misconceptions
associated
with
software
process
maturity
as
advocated
by
the
SEI.
The
SEI
has
worked
with
industry
and government
to
refine
and
expand
the
model,
and
software
organizations
are
encouraged
to
focus
on
the
CMM
rather
than
on
the
maturity
questionnaire.
The
SEI
has
developed,
and
is
developing,
a
suite
of
process
products
to
encourage
this
focus.
This
paper
[Paulk93a],
in
combination
with
the
"Key
Practices
of
the
Capability
Maturity
Model,
Version
1.1"
[Paulk93b],
comprises
CMM
vl.1.
The
"Key
Practices
of
the
Capability
Maturity
Model,
Version
1.1"
describes the
key practices
for
each
level
of
the
CMM.
This
paper
describes
the
principles
underlying
software
process
maturity
and
is
intended
to help
software
organizations
use
CMM
vI.1
as
a
guide
to
improve
the
maturity
of
their
software
processes.
Who
Should
Read
This
Paper?
This
paper
presents
an
introduction
to
the
CMM
and
its
associated
products.
Therefore,
anyone
who
is
interested
in
learning about
the
CMM
should
read
this
paper.
However,
this
paper
assumes
that
the
reader
has some
knowledge
of,
and
experience
in,
developing
and/or
maintaining
software,
as well as
an
understanding
of
the
problems
that
the
software
community
faces
today.
viii
E
Capability Maturity
Model
CMU/SEI-93-TR-24

To
the
Reader
This
document
can
be
used
in
several ways.
El
by
anyone
wanting
to
understand
the
key
practices
that
are
part
of
effective
processes
for
developing
or
maintaining
software,
Q
by
anyone
wanting
to
identify
the
key
practices
that
are
needed
to
achieve
the
next
maturity
level
in
the
CMM,
L3
by
organizations
wanting
to
understand
and
improve
their
capability
to
develop
software
effectively,
O
by
acquisition
organizations
or
prime
contractors
wanting
to
know
the
risks;
of
having
a
particular
software
organization
perform
the
work
of
a
contract,
O
by
the
SEI
as
the
basis
for
developing
questions
for
the
maturity
questionnaire,
and
D
by
instructors
preparing
teams
to
perform
software
process
assessments
or
software
capability
evaluations.
How
is
This
Paper
Organized?
This
paper
has
five
chapters:
Chapter
1
Defines the
concepts
necessary
to
understand
the
CMM
and
the
motivation
and
purpose
behind
it.
.
CM
UISEI-93-TR-24
Capability
Maturity
Model
n
ix

To
the
Reader
Chapter
2
Describes
the
five
levels
of
the
CMM
and
the
principles
that
underlie
them.
Chapter
3
Describes
how
the
CMM
is
structured
into
key
process
areas,
organized
by
common
features,
and
described
in
terms
of
key
practices.
Cha
pter
4
Provides
a
high-level
overview
of
how
the
CMM
provides
guidance
for
software
process
assessments, software capability
evaluations,
and process
improvement
programs.
Chapter
5
Concludes
by
providing
a
description
of
future
directions
for
the
CMM
and
its
related
products.
What
Are
the
Other
CMM
Products?
Although
this
paper
can
be
read
in
isolation,
it
is
designed
to
be
the
launching
point
for
other
products.
This
paper
and
the
associated
products
help
the
reader
understand
and
use the
CMM.
All
of
the
CMM-based
products
have
been,
or will
be,
systematically
derived
from the
model.
At
the
time
of
this
writing,
most
of
these
products
are
not
available
in
their
final form,
although
preliminary
versions
are
in
various
stages
of
pilot
testing
and
release.
x
m
Capability
Maturity
Model
CMLI/SEI-93-TR
.24

0
To
the
Reader
The
CMM-based
set
of
products
includes
several
diagnostic
tools,
which
are
used
by
software
process assessment1
and
software capability
evaluation
2
teams
to
identify
strengths,
weaknesses,
and
risks
of
an
organization's
software process.
Probably
the
best
known
of
these
is
the
maturity
questionnaire.
The
software
process
assessment
and
software
capability
evaluation
methods
and training
also
rely
on
the
CMM.
The
users
of
these
products
form
a
community
dedicated
to
improving
the
maturity
of
their
software
process.
The
SEI
will
continue
to
work
with
the
software community
to
enhance
the
model
and
its
associated
products.
How
Do
You
Receive
More
Information?
For
further
information
regarding
the
CMM
and
its
associated
products,
including training
on
the
CMM
and
how
to
perform
software
process
assessments
and
software
capability
evaluations,
contact:
SEI
Customer
Relations
Software
Engineering
Institute
Carnegie
Mellon
University
Pittsburgh,
PA
15213-3890
(412)
268-5800
Internet:
customer-relations@sei.crnu.edu
1
A
software process assessment
is
an
appraisal
by
a
trained
team
of
software professionals
to
determine
the
state
of
an
organization's current
software process,
to
determine
the
high-priority
software
process-related
issues
facing
an
organization,
and
to
obtain
the
organizational
support
for
Foftware
process
improvement.
2
A
software capability
evaluation
is
an
appraisal
by
a
trained
team of
professionals
to
identify
contractors who
are
qualified
to
perform the
software
work
or
to
monitor
the
state
of
the
software
process
used
on
an
existing software
effort.
OCMUSEI-93-TR-24
Capability Maturity
Model
a
xi

To
the
Reader
SEI
technical
reports,
such
as
this
paper
and
the
"Key
Practices
of
the
Capability
Maturity
Model,
Version
1.1,"
are
directly
available
from
the
Defense
Tcchnical
Information
Center
(DTIC),
the
National
Technical
Information
Service
(NTIS),
and
Research
Access Inc.
(RAI).
These
documents
can
be
obtained by
contacting:
RAI:
Research
Access
Inc.
3400
Forbes
Avenue
Suite
302
Pittsburgh,
PA
15213
Telephone:
(800)
685-6510
FAX:
(412)
682-6530
NTIS:
National
Technical
Information
Service
U.S.
Department
of
Commerce
Springfield,
VA
22161-2103
Telephone:
(703)
487-4600
DTIC:
Defense
Technical
Information
Center
ATTN:
FDRA
Cameron
Station
Alexandria,
VA 22304-6145
Telephone:
(703)
274-7633
xii
*
Capability Maturity
Model
CMU/SEI-93-TR-24

__ _To
the
Reader
SEI
technical
reports
are
also
available
via
Internet.
To
use
anonymous
ftp
from
a
Unix
system
on
Internet:
ftp
ftp.sei.cmu.edu
3
login:
anonymous
password:
<your
user
id
or
any
string>
cd
pub/cmm
get
READ.ME
get
<files>
quit
The
file READ.ME
contains
information
on
what
files
are
available.
Other
SEI
publications
are available
in
a
similar
manner.
3
The
SEI
ftp
machine
address
is
128.237.2.179.
*
CMUISEI-93-TR-24
Capability Maturity
Model
mxiii

To
the
Reader
xiv
.
Capability Maturity
Model
CMU/SEI-93-TR-24

*
I
The
Process
Maturity
Framework
After
two
decades
of
unfulfilled promises
about
productivity
and
quality
gains
from
applying
new software
methodologies
and
technologies,
industry
and
government
organizations
are
realizing
that
their
fundamental
problem
is
the
inability
to
manage
the
software
process
[DoD87].
The
benefits
of
better
methods
and
tools
cannot
be
realized
in
the
maelstrom
of
an
undisciplined,
chaotic project.
In
many
organizations,
projects
are
often excessively
late
and double
the
planned budget
[Siegel9O].
In
such
instances,
the
organization frequently
is
not
providing
the
infrastructure and
support
necessary
to
help
projects
avoid
these
problems.
Even
in
undisciplined
organizations,
however,
some
individual
software
projects
produce
excellent
results.
When
such
projects succeed,
it
is
generally
through
the heroic
efforts of
a
dedicated
team,
rather
than
through
repeating
the
proven
methods
of
an
organization with
a
mature
software
process.
In
the
absence
of
an
organization-wide
software
process,
repeating
results
depends
entirely
on
having
the
same
individuals
available
for
the
next
project.
Success
that
rests
solely
on
the
availability
of specific
individuals
provides
no
basis
for
long-term
productivity and
quality
improvement
throughout
an
organization.
Continuous improvement
can
occur only
through
focused
and
sustained
effort
towards
building
a
process
infrastructure
of effective
software
engineering
and
management
practices.
1.1
Immature
Versus
Mature
Software
Organizations
Setting
sensible
goals
for
process
improvement
requires
an
understanding
of
the
difference
between
immature and
mature
software
organizations.
In
an
immature
software
organization,
software
processes
are
generally
improvised
by
practitioners and their
management
during
the
course of the
project.
Even
if
a
software
process
iia-s
been specified,
it
is
not
rigorously
followed
or
enforced.
The
immature
software
organization
is
reactionary,
.CM
U/SEI-93-TR-24
Capability
Maturity
Model
*
1I

The
Process
Maturity
Framework
and
managers
are
usually
focused
on
solving
immediate
crises
(better
known
as
fire
fighting). Schedules
and
budgets
are
routinely
exceeded
because
they
are
not
based
on
realistic
estimates.
When
hard
deadlines
are
imposed,
product
functionality and
quality
are
often
compromised
to
meet
the
schedule.
In
an
immature
organization,
there
is
no
objective
basis
for
judging product
quality
or
for
solving
product
or
process
problems.
Therefore,
prodt'ct
quality
is
difficult to
predict.
Activities
intended
to
enhance
quality
such
as
reviews
and
testing
are
often
curtailed
or
eliminated
when
projects
fall
behind
schedule.
On
the
other
hand,
a
mature
software
organization
posses:
es
an
organization-wide
ability
for
managing
software
development
and
mainteitance
processes.
The
software process
is
accurately
communicated
to
both
existing
staff
and new
employees,
and work
activities are
carried
out
according
to
the
planned
process.
The
processes
mandated
are
fit
for
use
[Humphrey9lb] and
consistent
with
the
way
the
work actually
gets done.
These
defined
processes
are
updated
when
necessary,
and
improvements
are
developed through
controlled pilot-tests
and/or
co
st
banefit
analyses.
Roles
and
responsibilities
within
the defi:ied
process
are
clear
t•,
oughout
the
project
and
across
the
organization.
In
a
mature
organization,
managers
monitor
the
quality
of
the
software
products
and
customer
satisfaction.
There
is
an objective,
quantitative
basis
for
judging
product
quality
and
analyzing
problems
with
tl'e product
and
process.
Schedules
and budgets
are
based
on
historical
performance
and
are
realistic;
the
expected
results
for cost,
schedule. functionality,
and
quality
of
the
product
are
usually
achieved.
In
general,
a
disciplined
process
is
consistently
followed
because
all
of
the
participants
understand
the
value
of
doing
so,
and
the
necessary
infrastructure
exists
to
support
the
process.
Capitalizing
on these
observations
about
immature
and
mature
software
organizations
requires
construction
of
a
sof'.ware
process
maturity
2
m
Capability
Maturity
Model
CMUISEI-93-TR-24

The
Process
Maturity
Framnewo'rk
framework.
This
framework
describes
an
evolutionary
path
from
ad
hoc,
chaotic
processes
to
mature,
disciplined software
processes.
Without
this
framework,
improvemen.' programs
may
prove
ineffective
because
the
necessary
foundation
for
supporting
successive
improvements
has not
been
established.
The
software
process
maturity
framework
emerges
from
integrating
the
concepts
of
software
process,
software
process capability,
software
process
performance,
and
software
process
maturity,
all
of
which
are
defined
in
succeeding
paragraphs.
1.2
Fundamental
Concepts
Underlying
Process
Maturity
According
to
Webster's
dictionary,
a
process
is
"a
system
of
operations
in
producing
something
...
a
series
of
actions, changes,
or functions
that
achieve
an
end
or
result."
The
IEEE
defines
a
process
as
"'a
sequence
of
steps
performed
for
a
given
purpose"
[IEEE-STD-610].
A
software
process
can
be
defined
as
a
set
of activities,
me6-hods,
practices,
and transformations
that
0
people
use
to
develop and
maintain
software
and
the
associated
products
(e.g.,
project
plans,
design documents,
code,
test
cases,
and user
manuals).
As
an
organization matures,
the
software process
becomes
better
defined
and
more
consistently
implemented
throughout
the
organization.
Software
process
capability
describes
the
range
of
expected
results
that
can
be
achieved
by
following
a
software
process.
The
software process
capability
of
an
organization
provides
one
means
of
predicting
the
most
likely
outcomes
to be
expected
from
the
next software
project
the
organization
undertakes.
Software
process
performance
represents
the
actual
results
achieved
by
following
a software
process.
Thus,
software
process
performance
focuses
on
the
results
achieved,
while
software
process
capability
focuses
on
results
expected.
Based
on
the
attributes
of
a
specific
project
and
the
context
within
which
it
is
conducted,
the actual
performance
of
the
project
may not
reflect
the
full
process
capability
of
the
organization;
i.e.,
the
capability
of
the
,
CM
UISEI-93-TR-24
Capability
Maturity
Model
R
3

The
Process
Maturity
Framework
project
is
constrained
by
its
environment.
For
instance, radical
changes
in
the
application
or
technology
undertaken
may
place
a
project'
s
staff
on
a
learning
curve
that
causes
their
project's
capability,
and
performance,
to
fall
short
of
the organization's
full
process
capability.
Software
process
maturity
is
the
extent
to
which
a
specific
process
is
explicitly
defined,
managed, measured,
controlled,
and
effective.
Maturity
implies
a
potential
for
growth
in
capability
and
indicates
both
the
richness
of
an
organization's
software
process
and
the
consistency
with which
it
is
applied
in
projects
throughcut
the
organization.
The
software
process
is
well-understood
throughout
a
mature organization,
usually through
documentation
and
training,
and
the
process
is
continually
being
monitored
and
improved
by
its
users.
The
capability
of
a
mature
software
process
is
known.
Software
process
maturity
implies
that
the
productivity
and
quality resulting
from
an
organization's
software process
can
be
improved
over
time
through
consistent
gains
in
the discipline
achieved
by
using
its
software
process.
As
a
software
organization
gains
in
software
process
maturity,
it
institutionalizes
its
software
process
via
policies,
standard:s,
and
organizational
structures.
Institutionalization
entails
building
an
infrastructure
and
a
corporate culture
that
supports
the
methods,
practices,
and
procedures
of
the
business so
that
they
endure
after
those
who
originally
defined
them
have
gone.
1.3
Overview
of
the
Capability Maturity
Model
Although software
engineers
and
managers
4ften
know
their
problems
in
great
detail,
they
may
disagree
on
which
•',p-oveme1ts
are
most
important.
Without
an
organized
strategy
for
improveme
u,.
it
is
difficult
to
achieve
consensus
between management
and
the
professIcL.al
staff
on what
improvement
activities
to
undertake
first,.
To
achieve
,
results
from
process
improvement
efforts, it
is
necessary
to
design
an
c.,olutionary
path
4
m
Capability
Maturity
Model
CMU/SEI-93-TR-24

The Process
Maturity
Framework
that
increases
an organization's
software
process
maturity
in
stages.
The
software
process
maturity
framework
[Humphrey
87a]
orders
these
stages
so
that
improvements
at
each
stage
provide
the
foundation
on
which
to
build
improvements
undertaken
at the
next
stage.
Thus,
an
improvement
strategy
drawn
from
a
software
process
maturity
framework
provides
a
roadmap
for
continuous
process
improvement.
It
guides
advancement
and
identifies
deficiencies
in
the
organization;
it
is
not
intended
to
provide
a
quick
fix
for
projects in
trouble.
The
Capability
Maturity
Model
for
S-ftware
provides
software
organizations
with
guidance
on
how
to
gain
control
of
their
procr-ses
for
developing
and
maintaining
software
and
how
to
evolve
toward
a
culture
of
software
engineering
and
management
excellence.
The
CMM
was
designed
to
guide
software organizations
in
selecting
process
improvement
strategies
by
determining current
process
maturit,
and
identifying
the
few
iLsues
most
critical
to
software quality
and process
improvement.
By
focusing
on
a
limited set
of
acti
Aties
and
working
aggressively
to
achieve
them,
an
organization
can
steadily
improve
its
organization-wide
software
process
to
enable
continuous
and
lasting gain-
in
software
process
capability.
The
staged
structure
of
the
CMM
is
based on
principles
of
product
quality
that
have existed
for
the last
sixty
years. In
the
1930s,
Walter
Shewart,
promulgated
the
principles
of
statistical
quality
control. His
principles
were
further
developed
and
successfully
demonstrated
in the
work
of
W.
Edwards
Deming
[Deming86]
and
Joseph
Juran
[Juran88, Juran89].
These
principles
have
been
adapted
by
the
SEI
into
a
maturity
framework
that
establishes
a
project
management
and engineering
foundation
for
quantitative
control
of
the
software
process, which
is
the basis
for
continuous
process
improvement.
The
maturity
framework
into
which
these
quality principles
have
been
adapted
was
first
inspired
by
Philip
Crosby
of
in
his book
Quality
is
Free
[Crosby79].
Crosby's
quality
management
maturity grid
describes
five
evolutionary
stages
in
adopting
quality
practices.
This
maturity
framework
was
adapted
to
the
software
process
by
Ron
Radice
and
his
colleagues,
CMU/SEI-93-TR-24
Capability
Maturity
Model
*
5

The
Process
Maturity
Framework
working
under
the
direction
of
Watts
Humphrey
at
IBM
[Radice85].
Humphrey brought
this
maturity
framework
to
the
Software
Engineering
Institute
in
198C,
added
the
concept
of
maturity
levels,
and developed
the
foundation
for
its
current
use
throughout
the
software
industry.
Early
versions
of
Humphrey's
maturity
framework
are
described in
SEI
technical
reports
[Humphrcy87a,
Humphrey87b],
papers
[Humphrey88],
and
in
his
book,
Managing
the Software
Process
[Humphrey89].
A
preliminary
maturity
questionnaire
[Humphrey87b]
was
released in
0987
as
a
tool
to
provide
organizations
with
a
way to characterize
the
inaturity
of
their
software
processes.
Two
methods,
software
process
assessment
and
software
capability evaluation,
were
developed
to
appraise
software
process
maturity
in
1987.
Since
1990,
the
SEI,
with
the
help
of
many
people
from
government and
industry,
has
further expanded and
refined
the model
based
on
several
years
of
experience
in
its
application
to
software
process
improvement.
6
n
Capability Maturity
Model
CMU/SEI-93-TR-24

*
2
The
Five Levels
of
Software
Process
Maturity
Continuous
process
improvement
is
based
on
many
small,
evolutionary
steps
rather
than
revolutionary
innovations
[Imai86].
The
CMM
provides
a
framework
for
organizing
these
evolutionary
steps
into
five
maturity
levels
that
lay
successive
foundations
for
continuous
process
improvement.
These
five
maturity
levels
define
an
ordinal
scale
for
measuring
the
maturity
of an
organization's
software
process
a-nd
for
evaluating
its
software
process
capability.
The
levels
also
help an
orga
nization prioritize
its
improvement
efforts.
A
maturity
level
is
a
well-defined
evolutionary
plateau
toward
achieving
a
mature
software
process.
Each
maturity
level
provides
a
layer.
in
the
foundation
for
continuous
process
improvement.
Each
level
comprises
a
set
of
pro
:,ess
goals
that,
when
satisfied, stabilize
an
important
component
of
the software
process.
Achieving
each
level
of
the
maturity
framework
establishes
a
different
component
in
the
software
process,
resulting
in
an
0 increase
in
the
process
capability
of
the
organization.
Organizing
the
CMM
into
the
five
levels
shown
in
Figure
2.1
prioritizes
improvement
actions
for
increasing
software
process
maturity.
The
labeled
arrows
in
Figure
2.1
indicate the
type
of
process
capability
being
institutionalized
by
the
organization
at
each
step
of
the
maturity
framework.
.
CM
U/SEI-93-TR-24
Capability Maturity
Model
0
7

The
Five
Levels of
Software
Process
Maturity
Continuousl
Opiizn
improving
I
(5)
J
process(
PredictableMage
process(4
Standard,Deid
consistent
f
(3)1
process~
DisciplinedR
e
~
I
ta
process(2
Figure
2.1.
The
Five
Levels
of
Software
P'rocess
Maturity
The
following
characterizations
of
the
five
maturity
levels
highlight
the
primary
process changes
made
at
each
level:
1)
Initial
The
software process
is
cha;
acterized
as
ad
hoc,
and
occasionally
even
chaotic.
Few
processes
are
defined,
and
success
depends
on
individual
effort.
8
n
Capability
Maturity
Model
CMUISEI-93-TR-24

The
Five
Levels
of
Software
Process
Maturity
2)
Repeatable
Basic
project
management
processes
are
established
to
track
cost,
schedule, and
functionality.
The
necessary
process
discipline
is
in
place
to
repeat
earlier
successes
on
projects
'with
similar
applications.
3)
Defined
The
software
process
for
both
management
and
engineering
activities
is
documented,
standardiz2d,
and
integrated
into
a
standard
software
process
for
the
organization.
All
projects
use
an
approved,
tailored
version
of
the
organization's
standard
software
process
for
developing
and
maintaining
software.
4)
Managed
Detailed
measures
of
the
software
process
and
product
quality
are collected.
Both the
software
process and
products
are
quantitatively
understood
and
controlled.
5)
Optimizing
Continuous
process
improvement
is
enabled
by
quantitative
feedback
from the
process
and
from.
piloting
innovative
ideas
and
technologies.
2.1
Behavioral
Characterization
of
the
Maturity
Levels
Maturity
Levels
2
through
5
can
be
characterized
through
the
activities
performed
by
the
organization
to
establish
or
improve
the
software
process,
by
activities
performed
on
each
project,
and
by
the
resulting
process
capability
across
projects.
A
behavioral characterization
of
Level
1
is
included
to
establish
a
base
of
comparison
for
process
improvements
at
higher maturity
levels.
dk
CMUISEI-93-TR-24
Capability
Maturity
Model
* 9

The
Five
F-evels
of
Software
Process
Maturity
2.1.1
Level
1
-
The
Initial
Level
At
the
Initial
Level,
the
organization
typically
does
not provide
a
stable
environment
for
developing and
maintaining
software.
When
an
organization
lacks
sound
management
practices, the
benefits
of good
software engineering
practices
are
undermined
by
ineffective
planning
and
reaction-driven
commitment
systems.
During
a
crisis,
projects
typically
abandon
planned
procedures
and
revert
to
coding
and
testing.
Success
depends
entirely
on
having
an
exceptional
manager
and
a
seasoned
and
effective
software
team.
Occasionally,
capable
and
forceful
software
managers
can
withstand
the
pressures
to
take
shortcuts
in
the
software
process;
but
when
they
leave
the
project,
their
stabilizing
influence
leaves
with
them.
Even
a
strong
engineering
process
cannot
overcome
the
instability
created
by
the
absence
of
sound
management
practices.
The
software
process
capability
of
Level
1
organizations
is
unpredictable
because
the software process
is
constantly
changed or
modified
as
the
work
progresses
(i.e.,
the
process
is
ad
hoc).
Schedules,
budgets,
functionality,
and
product
quality
are
generally
unpredictable. Performance
depends
on
the
capabilities
of
individuals
ai.
1
'aries
with
their
innate
skills,
knowledge,
and
m'otivations.
There
are few
stable
software processes
in
evidence,
and
performance
can be
predicted
only
by
individual rather
than
organizational
capability.
2.1.2
Level
2
-
The
Repeatable
Level
At
the
Repeatable
Level,
policies
for
managing
a
software
project
and
procedures
to
implement
those
policies
are
established.
Planning
and
managing
new
projects
is
based
on
experience
with
similar
projects.
An
objective
in
achieving
Level
2
is
to
institutionalize
effective
management
10
m
Capability
Maturity
Model
CM
UISEI-93-TR-24

The
Five
Levels
of
Software
Process
Maturity
processes
for
software
projects,
which
allow
organizations
to
repeat
successful
practices
developed
on
earlier
projects,
although
the specific
processes
implemented
by
tiiC
projects
may
differ.
An effective
process
can
be
characterized
as
practiced,
documented,
enforced,
trained, measured,
and
able to
improve.
Projects
in
Level
2
organizations
have
installed
basic
software
management
controls.
Realistic
project
commitments
are
based
on
the
results
observed
on
previous
projects
and
on
the
requirements
of
the
current
project.
The
software
managers
fc'-
a
project
track
software
costs,
schedules, and
functionality;
problems
in
meeting commitments
are
identified
when
they
arise.
Software
requirements
and
the
work
products
developed
to
satisfy
them
are
baselined,
and
their
integrity
is
controlled.
Software
project
standards
are
defined,
and
the
organization
ensures
they are
faithfully
followed.
The
software
project
works
with
its
subcontractors,
if
any,
to
establish
a
strong customer-supplier
relationship.
The
software
process
capability
of
Level
2
organizations
can
be
summarized
as
disciplined
because
planning
and
tracking
of
the
software
project
is
stable
and
earlier
successes
can be
repeated.
Thte
project's
process
is
under
the
effective
control
of
a
project
management
system,
following
realistic
plans
based
on
the performance
of
previous
projects.
2.1.3
Level
3
-
The
Defined
Level
At the
Defined
Level,
the
standard
process
for
developing
and
maintaining
software
across
the
organization
is
documented, including both
software
engineering and
management
processes,
and
these
processes
are
integrated
into
a
coherent
whole.
This
standard
process
is
referred
to
throughout
the
CMM
as