|
2 Overview of the Capability Maturity Model
The Capability Maturity Model for Software (CMM) is a framework that describes
the key elements of an effective software process. The CMM describes an
evolutionary improvement path from an ad hoc, immatu fdd re process to a
mature, disciplined process.
The CMM covers practices for planning, engineering, and managing software
development and maintenance. When followed, these key practices improve
the ability of organizations to meet goals for cost, schedule, functionality,
and product quality.
The CMM establishes a yardstick against which it is possible to judge,
in a repeatable way, the maturity of an organization's software process
and compare it to the state of the practice of the industry [Kitson92].
The CMM can also be used by an organization to plan improvements to its
software process.
The Software Engineering Institute (SEI) developed an initial version of
a maturity model and maturity questionnaire at the request of the government
and with the assistance of the MITRE Corporation. Throughout the development
of the model and the questionnaire, the SEI has paid attention to advice
from practitioners who are involved in developing and improving software
processes. Our objective has been to provide a model that:
- is based on actual practices;
- reflects the best of the state of the practice;
- reflects the needs of individuals performing software process improvement,
software process assessments, or software capability evaluations;
- is documented; and
- is publicly available.
Additional knowledge and insight into software process maturity has been
gained since the earlier versions of the maturity model. This insight has
been gained by:
- studying non-software organizations,
- performing and observing software process assessments and software
capability evaluations,
- soliciting and analyzing change requests to the model,
- participating in meetings and workshops with industry and government
representatives, and
- soliciting feedback from industry and government reviewers.
Using this additional knowledge, the Capability Maturity Model and its practices
have been revised, creating CMM v1.1.
The CMM is composed of five maturity levels. With the exception of Level
1, each maturity level is composed of several key process areas. Each key
process area is organized into five sections called common features. The
common features specify the key practices that, when collectively addressed,
accomplish the goals of the key process area. This structure of the CMM
is illustrated in Figure 2.1.
Figure 2.1 The Structure of the Capability Maturity Model
The components of the CMM include:
Maturity levels
A maturity level is a well-defined evolutionary plateau toward achieving
a mature software process. The five maturity levels provide the top-level
structure of the CMM.
Process capability
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.
Key process areas
Each maturity level is composed of key process areas. Each key process
area identifies a cluster of related activities that, when performed collectively,
achieve a set of goals considered important for establishing process capability
at that maturity level. The key process areas have been defined to reside
at a single maturity level. For example, one of the key process areas
for Level 2 is Software Project Planning.
Goals
The goals summarize the key practices of a key process area and can
be used to determine whether an organization or project has effectively
implemented the key process area. The goals signify the scope, boundaries,
and intent of each key process area.
An example of a goal from the Software Project Planning key process
194 area is "Software estimates are documented for use in planning and
tracking the software project." See "Capability Maturity Model for Software,
Version 1.1" [Paulk93a] and Section 4.5, Applying Professional Judgment,
of this document for more information on interpreting the goals. (kp PP.GO.1)
Common features
The key practices are divided among five Common Features sections: Commitme
fba nt to Perform, Ability to Perform, Activities Performed, Measurement
and Analysis, and Verifying Implementation. The common features are attributes
that indicate whether the implementation and institutionalization of a
key process area is effective, repeatable, and lasting.
The Activities Performed common feature describes implementation activities.
The other four common features describe the institutionalization factors,
which make a process part of the organizational culture.
Key practices
Each key process area is described in terms of key practices that, when
implemented, help to satisfy the goals of that key process area. The key
practices describe the infrastructure and activities that contribute most
to the effective implementation and institutionalization of the key process
area.
For example, one of the practices from the Software Project Planning
key process area is "The project's software development plan is developed
according to a documented procedure." (kp PP.AC.6)
As organizations establish and improve the software processes by which they
develop and maintain their software work products, they progress through
levels of maturity. Figure 2.2 shows the five maturity levels of the CMM.
Each maturity level provides a layer in the foundation for continuous
process improvement. Each key process area comprises a set of goals that,
when satisfied, stabilize an important component of the software process.
Achieving each level of the maturity model institutionalizes a different
component in the software process, resulting in an overall increase in
the process capability of the organization.
Figure 2.2 The Five Levels of Software Process Maturity
2.4.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 and varies with their innate skills, knowledge,
and motivations. There are few stable software processes in evidence,
and performance can be predicted only by individual rather than organizational
capability.
2.4.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 processes for software
projects, which allow organizations to repeat successful practices developed
on earlier projects, although the specific processes implemented by the
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 m 190
anagement controls. Realistic project commitments are based on the results
observed on previous projects and on the requirements of the current project.
The software managers for 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 the fab ir 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. The project's process is
under the effective control of a project management system, following
realistic plans based on the performance of previous projects.
2.4.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 the organization's standard software process. Processes established
at Level 3 are used (and changed, as appropriate) to help the software managers
and technical staff perform more effectively. The organization exploits
effective software engineering practices when standardizing its software
processes. There is a group that is responsible for the organization's software
process activities, e.g., a software engineering process group, or SEPG
[Fowler90]. An organization-wide training program is implemented to ensure
that the staff and managers have the knowledge and skills required to fulfill
their assigned roles.
Projects tailor the organization's standard software process to develop
their own defined software process, which accounts for the unique characteristics
of the project. This tailored process is referred to in the CMM as the
project's defined software process. A defined software process contains
a coherent, integrated set of well-defined software engineering and management
processes. A well-defined process can be characterized as including readiness
criteria, inputs, standards and procedures for performing the work, verification
mechanisms (such as peer reviews), outputs, and completion criteria. Because
the software process is well defined, management has good insight into
technical progress on all projects.
The software process capability of Level 3 organizations can be summarized
as standard and consistent because both software engineering and management
activities are stable and repeatable. Within established product lines,
cost, schedule, and functionality are under control, and software quality
is tracked. This process capability is based on a common, organization-wide
understanding of the activities, roles, and responsibilities in a defined
software process.
2.4.4 Level 4 - The Managed Level
At the Managed Level, the organization sets quantitative quality goals for
both software products and processes. Productivity and quality are measured
for important software process activities across all projects as part of
an organizational measurement program. An organization-wide software process
database is used to collect and analyze the data available from the projects'
defined software processes. Software processes are instrumented with well-defined
and consistent measurements at Level 4. These measurements establish the
quantitative foundation for evaluating the projects' software processes
and products.
Projects achieve control over their products and processes by narrowing
the variation in their process performance to fall within acceptable quantitative
boundaries. Meaningful variations in process performance can be distinguished
from random variation (noise), particularly within established product
lines. The risks involved in moving up the learning curve of a new application
domain are known and carefully managed.
The software process capability of Level 4 organizations can be summarized
as predictable because the process is measured and op 193 erates within
measurable limits. This level of process capability allows an organization
to predict trends in process and product quality within the quantitative
bounds of these limits. When these limits are exceeded, action is taken
to correct the situation. Software products are of predictably high quality.
2.4.5 Level 5 - The Optimizing Level
At the Optimizing Level, the entire fba organization is focused on continuous
process improvement. The organization has the means to identify weaknesses
and strengthen the process proactively, with the goal of preventing the
occurrence of defects. Data on the effectiveness of the software process
is used to perform cost benefit analyses of new technologies and proposed
changes to the organization's software process. Innovations that exploit
the best software engineering practices are identified and transferred throughout
the organization.
Software project teams in Level 5 organizations analyze defects to determine
their causes. Software processes are evaluated to prevent known types
of defects from recurring, and lessons learned are disseminated to other
projects.
The software process capability of Level 5 organizations can be characterized
as continuously improving because Level 5 organizations are continuously
striving to improve the range of their process capability, thereby improving
the process performance of their projects. Improvement occurs both by
incremental advancements in the existing process and by innovations using
new technologies and methods.
Figure 2.3 lists the key process areas for each maturity level in the CMM.
Each key process area identifies a cluster of related activities that,
when performed collectively, achieve a set of goals considered important
for enhancing process capability. The key process areas have been defined
to reside at a single maturity level. The key process areas are building
blocks that indicate the areas an organization should focus on to improve
its software process. Key process areas identify the issues that must be
addressed to achieve a maturity level.
Figure 2.3 The Key Process Areas by Maturity Level
The key process areas at Level 2 focus on the software project's concerns
related to establishing basic project management controls. Descriptions
of each of the key process areas for Level 2 are given below:
- The purpose of Requirements Management is to establish a common understanding
between the customer and the software project of the customer's requirements
that will be addressed by the software project. This agreement with
the customer is the basis for planning (as described in Software Project
Planning) and managing (as described in Software Project Tracking and
Oversight) the software project. Control of the relationship with the
customer depends on following an effective change control process (as
described in Software Configuration Management).
- The purpose of Software Project Planning is to establish reasonable
plans for performing the software engineering and for managing the software
project. These plans are the necessary foundation for managing the software
project (as described in Software Project Tracking and Oversight). Without
realistic plans, effective project management cannot be implemented.
- The purpose of Software Project Tracking and Oversight is to establish
adequate visibility into actual progress so that management can take
effective actions when the software project's performance deviates significantly
from the software plans.
- The purpose of Software Subcontract Management is to select qualified
software subcontractors and manage them effectively. It combines the
concerns of Requirements Management, Software Project Planning, and
Software Project Tracking and Oversight for basic management control,
along with necessary coordination of Software Quality Assurance and
Software Configuration Management, and applies this control to the subcontractor
as appropriate.
- The purpose of Software Quality Assurance is to provide management
with appropriate visibility into the process being used by the software
project and of the products being built. Software Quality Assurance
is an integral part of most software e 194 ngineering and management
processes.
- The purpose of Software Configuration Management is to establish and
maintain the integrity of the products of the software project throughout
the project's software life cycle. Software Configuration Management
is an integral part of most software engineering and management processes.
The key process areas at Level 3 address both project and or fb4 ganizational
issues, as the organization establishes an infrastructure that institutionalizes
effective software engineering and management processes across all projects.
Descriptions of each of the key process areas for Level 3 are given below:
- The purpose of Organization Process Focus is to establish the organizational
responsibility for software process activities that improve the organization's
overall software process capability. The primary result of the Organization
Process Focus activities is a set of software process assets, which
are described in Organization Process Definition. These assets are used
by the software projects, as is described in Integrated Software Management.
- The purpose of Organization Process Definition is to develop and maintain
a usable set of software process assets that improve process performance
across the projects and provide a basis for cumulative, long-term benefits
to the organization. These assets provide a stable foundation that can
be institutionalized via mechanisms such as training, which is described
in Training Program.
- The purpose of Training Program is to develop the skills and knowledge
of individuals so they can perform their roles effectively and efficiently.
Training is an organizational responsibility, but the software projects
should identify their needed skills and provide the necessary training
when the project's needs are unique.
- The purpose of Integrated Software Management is to integrate the
software engineering and management activities into a coherent, defined
software process that is tailored from the organization's standard software
process and related process assets, which are described in Organization
Process Definition. This tailoring is based on the business environment
and technical needs of the project, as described in Software Product
Engineering. Integrated Software Management evolves from Software Project
Planning and Software Project Tracking and Oversight at Level 2.
- The purpose of Software Product Engineering is to consistently perform
a well-defined engineering process that integrates all the software
engineering activities to produce correct, consistent software products
effectively and efficiently. Software Product Engineering describes
the technical activities of the project, e.g., requirements analysis,
design, code, and test.
- The purpose of Intergroup Coordination is to establish a means for
the software engineering group to participate actively with the other
engineering groups so the project is better able to satisfy the customer's
needs effectively and efficiently. Intergroup Coordination is the interdisciplinary
aspect of Integrated Software Management that extends beyond software
engineering; not only should the software process be integrated, but
the software engineering group's interactions with other groups must
be coordinated and controlled.
- The purpose of Peer Reviews is to remove defects from the software
work products early and efficiently. An important corollary effect is
to develop a better understanding of the software work products and
of the defects that can be prevented. The peer review is an important
and effective engineering method that is called out in Software Product
Engineering and that can be implemented via Fagan-style inspections
[Fagan86], structured walkthroughs, or a number of other collegial review
methods [Freedman90].
The key process areas at Level 4 focus on establishing a quantitative understanding
of both the software process and the software work products being built.
The two key process areas at this level, Quantitative Process Management
and Software Quality Management, are highly interdependent, as is described
below:
- The purpose of Quantitative Process Management is to control the process
performance of the software project quantitatively. Software process
performance represents the actual results achieved from following a
sof 190 tware process. The focus is on identifying special causes of
variation within a measurably stable process and correcting, as appropriate,
the circumstances that drove the transient variation to occur. Quantitative
Process Management adds a comprehensive measurement program to the practices
of Organization Process Definition, Integrated Software Management,
Intergroup Coordination, and Peer Revie fb9 ws.
- The purpose of Software Quality Management is to develop a quantitative
understanding of the quality of the project's software products and
achieve specific quality goals. Software Quality Management applies
a comprehensive measurement program to the software work products described
in Software Product Engineering.
The key process areas at Level 5 cover the issues that both the organization
and the projects must address to implement continuous and measurable software
process improvement. Descriptions of each of the key process areas for Level
5 are given below:
- The purpose of Defect Prevention is to identify the causes of defects
and prevent them from recurring. The software project analyzes defects,
identifies their causes, and changes its defined software process, as
is described in Integrated Software Management. Process changes of general
value are transitioned to other software projects, as is described in
Process Change Management.
- The purpose of Technology Change Management is to identify beneficial
new technologies (i.e., tools, methods, and processes) and transfer
them into the organization in an orderly manner, as is described in
Process Change Management. The focus of Technology Change Management
is on performing innovation efficiently in an ever-changing world.
- The purpose of Process Change Management is to continually improve
the software processes used in the organization with the intent of improving
software quality, increasing productivity, and decreasing the cycle
time for product development. Process Change Management takes the incremental
improvements of Defect Prevention and the innovative improvements of
Technology Change Management and makes them available to the entire
organization.
By definition, key process areas are expressed at a single maturity level.
There are, however, relationships between the key process areas, and improvements
in a specific management or technical area need not be restricted to a single
key process area. Figure 2.4 illustrates these relationships. Organizations
may work on higher level key process areas before they have achieved lower
level maturity levels, and attention must continue to be focused on lower
level key process areas even when key process areas at higher maturity levels
have been achieved.
Figure 2.4 The Key Process Areas Assigned to Process Categories
The key process areas are categorized in Figure 2.4 into three broad
categories: Management, Organizational, and Engineering processes. The
Management process category contains the project management activities
as they evolve from planning and tracking at Level 2, to managing according
to a defined software process at Level 3, to quantitative management at
Level 4, to innovative management in a constantly changing environment
at Level 5. The Organizational process category contains the cross-project
responsibilities as the organization matures, beginning with a focus on
process issues at Level 3, continuing to a quantitative understanding
of the process at Level 4, and culminating with the management of change
in an environment of continuous process improvement at Level 5. The Engineering
process category contains the technical activities, such as requirements
analysis, design, code, and test, which are performed at all levels, but
that evolve toward an engineering discipline at Level 3, statistical process
control at Level 4, and continuous measured improvement at Level 5.
Note that at Levels 4 and 5 there are key process areas that span these
process categories. This helps identify potential new key process areas
for CMM v2 as Levels 4 and 5 become better understood.
Each key process area is described in terms of the key practices that contribute
to satisfying its goals. The key practices describe the infrastructure and
activiti 191 es that contribute most to the effective implementation and
institutionalization of the key process area.
Each key practice consists of a single sentence, often followed by a
more detailed description, which may include examples and elaboration.
These key practices, also referred to as the top-level key practices,
state the fundamental policies, procedures, and activities for the key
process a fe4 rea. The components of the detailed description are frequently
referred to as subpractices.
The key practices describe "what" is to be done, but they should not
be interpreted as mandating "how" the goals should be achieved. Alternative
practices may accomplish the goals of the key process area. The key practices
should be interpreted rationally to judge whether the goals of the key
process area are effectively, although perhaps differently, achieved.
2.7 Goals
The goals summarize the key practices of a key process area and can be used
to determine whether an organization or project has effectively implemented
the key process area. The goals signify the scope, boundaries, and intent
of each key process area. In adapting the key practices of a key process
area to a specific project situation, the goals can be used to determine
whether the adaptation is a reasonable rendering of the practices. Similarly,
when assessing or evaluating alternative ways to implement a key process
area, the goals can be used to determine if the alternatives satisfy the
intent of the key process area. Please refer to "Capability Maturity Model
for Software, Version 1.1" [Paulk93a] and Section 4.5, Applying Professional
Judgment, of this document for more information on interpreting the goals
in an organization.
2.8 Common Features
The key practices in each key process area are organized by a set of common
features. The common features are attributes that indicate whether the implementation
and institutionalization of a key process area is effective, repeatable,
and lasting. The common features also group and order the key practices
in a sequence helpful for organizations using them. The five common features
are listed below:
Commitment to Perform
Commitment to Perform describes the actions the organization must take
to ensure that the process is established and will endure. Commitment
to Perform typically involves establishing organizational policies and
senior management sponsorship.
Ability to Perform
Ability to Perform describes the preconditions that must exist in the
project or organization to implement the software process competently.
Ability to Perform typically involves resources, organizational structures,
and training.
Activities Performed
Activities Performed describes the roles and procedures necessary to
implement a key process area. Activities Performed typically involve establishing
plans and procedures, performing the work, tracking it, and taking corrective
actions as necessary.
Measurement and Analysis
Measurement and Analysis describes the need to measure the process and
analyze the measurements. Measurement and Analysis typically includes
examples of the measurements that could be taken to determine the status
and effectiveness of the Activities Performed.
Verifying Implementation
Verifying Implementation describes the steps to ensure that the activities
are performed in compliance with the process that has been established.
Verification typically encompasses reviews and audits by management and
software quality assurance.
The practices in the common feature Activities Performed describe what
must be implemented to establish a process capability. The other practices,
taken as a whole, form the basis by which an organization can institutionalize
the practices described in the Activities Performed common feature. The
Activities Performed by projects or the organization provide the largest
category of key practices because they describe the actual implementation
of the key process area. Key practices under the other common features
are equally important, however, for they address what must be done to
support and institutionalize the key process area.
|
|