27-12-2012, 03:02 PM
The Capability Maturity Model for Software
[attachment=45431]
Abstract
This paper provides an overview of the latest version of the Capability Maturity Model
for Software, CMM v1.1. Based on over six years of experience with software process
improvement and the contributions of hundreds of reviewers, CMM v1.1 describes the
software engineering and management practices that characterize organizations as
they mature their processes for developing and maintaining software. This paper
stresses the need for a process maturity framework to prioritize improvement actions,
describes the process maturity framework of five maturity levels and the associated
structural components, and discusses future directions for the CMM.
Introduction
After two decades of unfulfilled promises about productivity and quality gains
from applying new software methodologies and technologies, organizations
are realizing that their fundamental problem is the inability to manage the
software process. In many organizations, projects are often excessively late
and over budget, and the benefits of better methods and tools cannot be
realized in the maelstrom of an undisciplined, chaotic project.
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 their software process. In September
1987, the SEI released a brief description of the process maturity framework
[Humphrey 87a] which was later expanded in Humphrey's book, Managing
the Software Process [Humphrey89]. Two methods, software process
assessment1 and software capability evaluation2 and a maturity
questionnaire [Humphrey87b] were developed to appraise software process
maturity.
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 has been specified, it is not rigorously followed or
enforced. The immature software organization is reactionary, 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, product 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 possesses an
organization-wide ability for managing software development and
maintenance 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 usable 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 cost benefit analyses. Roles and responsibilities
within the defined process are clear throughout the project and across the
organization.
The Five Levels of Software Process Maturity
Continuous process improvement is based on many small, evolutionary steps
rather than revolutionary innovations. The staged structure of the CMM is
based on principles of product quality espoused by Walter Shewart, W.
Edwards Deming, Joseph Juran, and Philip Crosby. 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 and for evaluating its software process
capability. The levels also help an organization prioritize its improvement
efforts.
A maturity level is a well-defined evolutionary plateau toward achieving a
mature software process. Each maturity level comprises a set of process
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 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.
The Initial Level
At the Initial Level, the organization typically does not provide a stable
environment for developing and maintaining software. Such organizations
frequently have difficulty making commitments that the staff can meet with an
orderly engineering process, resulting in a series of crises. 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.
[attachment=45431]
Abstract
This paper provides an overview of the latest version of the Capability Maturity Model
for Software, CMM v1.1. Based on over six years of experience with software process
improvement and the contributions of hundreds of reviewers, CMM v1.1 describes the
software engineering and management practices that characterize organizations as
they mature their processes for developing and maintaining software. This paper
stresses the need for a process maturity framework to prioritize improvement actions,
describes the process maturity framework of five maturity levels and the associated
structural components, and discusses future directions for the CMM.
Introduction
After two decades of unfulfilled promises about productivity and quality gains
from applying new software methodologies and technologies, organizations
are realizing that their fundamental problem is the inability to manage the
software process. In many organizations, projects are often excessively late
and over budget, and the benefits of better methods and tools cannot be
realized in the maelstrom of an undisciplined, chaotic project.
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 their software process. In September
1987, the SEI released a brief description of the process maturity framework
[Humphrey 87a] which was later expanded in Humphrey's book, Managing
the Software Process [Humphrey89]. Two methods, software process
assessment1 and software capability evaluation2 and a maturity
questionnaire [Humphrey87b] were developed to appraise software process
maturity.
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 has been specified, it is not rigorously followed or
enforced. The immature software organization is reactionary, 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, product 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 possesses an
organization-wide ability for managing software development and
maintenance 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 usable 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 cost benefit analyses. Roles and responsibilities
within the defined process are clear throughout the project and across the
organization.
The Five Levels of Software Process Maturity
Continuous process improvement is based on many small, evolutionary steps
rather than revolutionary innovations. The staged structure of the CMM is
based on principles of product quality espoused by Walter Shewart, W.
Edwards Deming, Joseph Juran, and Philip Crosby. 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 and for evaluating its software process
capability. The levels also help an organization prioritize its improvement
efforts.
A maturity level is a well-defined evolutionary plateau toward achieving a
mature software process. Each maturity level comprises a set of process
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 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.
The Initial Level
At the Initial Level, the organization typically does not provide a stable
environment for developing and maintaining software. Such organizations
frequently have difficulty making commitments that the staff can meet with an
orderly engineering process, resulting in a series of crises. 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.