| |
The CMM is a framework representing a path of improvements recommended for
software organizations that want to increase their software process capability.
This operational elaboration of the CMM is designed to support the many
ways it will be used. There are at least four uses of the CMM that are supported:
- Assessments teams will use the CMM to identify strengths and weaknesses
in the organization.
- Evaluation teams will use the CMM to identify the risks of selecting
among different contractors for awarding business and to monitor contracts.
- Managers and technical staff will use the CMM to understand the activities
necessary to plan and implement a software process improvement program
for their organization.
- Process improvement groups, such as an SEPG, will use the CMM as a
guide to help them define and improve the software process in their
organization.
Because of the diverse uses of the CMM, it must be decomposed in sufficient
detail that actual process recommendations can be derived from the structure
of the maturity levels. This decomposition also indicates the processes
and their structure that characterizes software process maturity and software
process capability.
Each maturity level has been decomposed into constituent parts. With the
exception of Level 1, the decomposition of each maturity level ranges from
abstract summaries of each level down to their operational definition in
the key practices, as shown in Figure 3.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.
Figure 3.1 The CMM Structure
A maturity level is a well-defined evolutionary plateau toward achieving
a mature software process. Each maturity level indicates a level of process
capability, as was illustrated in Figure 2.1. For instance, at Level 2 the
process capability of an organization has been elevated from ad hoc to disciplined
by establishing sound project management controls.
Except for Level 1, each maturity level is decomposed into several key process
areas 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.
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 as shown in Figure 3.2. The path
to achieving the goals of a key process area may differ across projects
based on differences in application domains or environments. Nevertheless,
all the goals of a key process area must be achieved for the organization
to satisfy that key process area. When the goals of a key process area
are accomplished on a continuing basis across projects, the organization
can be said to have institutionalized the process capability characterized
by the key process area.
Figure 3.2 The Key Process Areas by Maturity Level
The adjective "key" implies that there are process areas (and processes)
that are not key to achieving a maturity level. The CMM does not describe
all the process areas in detail that are involved with developing and
maintaining software. Certain process areas have been identified as key
determiners of process capability; these are the ones described in the
CMM.
Although other issues affect process performance, the key process areas
were identified because of their effectiveness in improving an organization's
software process capability. They may be considered the requirements for
achieving a maturity level. Figure 3.2 displays the key process areas
for each maturity level. To achieve a maturity level, the key process
areas for that level must be satisfied. T 190 o satisfy a key process
area, each of the goals for the key process area must be satisfied. 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. [ Begin Footnote ] --- For a listing of the
goals for faf each key process area, refer to Appendix A. --- [ End Footnote
]
The specific practices to be executed in each key process area will
evolve as the organization achieves higher levels of process maturity.
For instance, many of the project estimating capabilities described in
the Software Project Planning key process area at Level 2 must evolve
to handle the additional project data available at Levels 3, 4, and 5.
Integrated Software Management at Level 3 is the evolution of Software
Project Planning and Software Project Tracking and Oversight at Level
2 as the project is managed using a defined software process.
The key process areas of the CMM represent one way of describing how
organizations mature. These key process areas were defined based on many
years of experience in software engineering and management and over five
years of experience with software process assessments and software capability
evaluations.
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 engineering 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 organizational
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 191 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 pr fac ovide 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
software 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 Reviews.
- 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.
- 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 191 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 fc7 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.
For convenience, the key process areas are organized by 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 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.
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
activities 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 area. The components of the detailed description are frequently
referred to as subpractices. Figure 3.3 provides an example of the structure
underlying a key practice for the Software Project Planning key process
area.
Figure 3.3 Building the CMM Structure: An Example of a Key Practice
As illustrated in Figure 3.3, to ensure consistent accomplishment of
the goal of documenting plans for planning and tracking the project, the
organization must establish a documented procedure for deriving estimates
of so 190 ftware size. If these estimates are not developed from a documented
procedure, they may vary wildly as differences in sizing assumptions are
never surfaced. The detailed description of what would be expected in
such a procedure includes using historical size data, documenting assumptions,
and reviewing the estimates. These criteria guide the judgment of whether
a reasonable size estimating proc f41 edure is followed.
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.
The key practices are contained in the "Key Practices of the Capability
Maturity Model, Version 1.1" [Paulk93b], along with guidance on their
interpretation.
|
|
