Capability
Maturity
Model
What is CMM?
CMM: Capability Maturity Model
Developed by the Software Engineering
Institute of the Carnegie Mellon University
Framework that describes the key elements of
an effective software process.
What is CMM?
Describes an evolutionary improvement path for
software organizations from an ad hoc, immature
process to a mature, disciplined one.
Provides guidance on how to gain control of processes
for developing and maintaining software and how to
evolve toward a culture of software engineering and
management excellence.
Process Maturity
Concepts
Software Process
setof activities, methods, practices, and
transformations that people use to develop
and maintain software and the associated
products (e.g., project plans, design
documents, code, test cases, user manuals)
Software Process Capability
describes the range of expected results that
can be achieved by following a software
process
means of predicting the most likely outcomes
to be expected from the next software
project the organization undertakes
Process Maturity
Concepts
Software Process Performance
actual
results achieved by following a
software process
Software Process Maturity
extent to which a specific process is
explicitly defined, managed,
measured, controlled and effective
implies potential growth in capability
indicates richness of process and
consistency with which it is applied in
projects throughout the organization
What are the CMM
Levels?
(The five levels of software
process maturity)
Maturity level indicates level of process capability:
Initial
Repeatable
Defined
Managed
Optimizing
Level 1: Initial
Initial : The software process is
characterized as ad hoc, and occasionally.
Few processes are defined, and success
depends on individual effort.
At this level, frequently have difficulty making
commitments that the staff can meet with an
orderly process
Products developed are often over budget and
schedule
Wide variations in cost, schedule, functionality
and quality targets
Capability is a characteristic of the individuals,
not of the organization
Level 2: Repeatable
Basic 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.
Realistic project commitments based on results
observed on previous projects
Software project standards are defined and
faithfully followed
Processes may differ between projects
Process is disciplined
earlier successes can be repeated
Level 3: Defined
The software process for both management and
engineering activities is documented,
standardized, 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.
Level 4: Managed
Detailed measures of the software process
and product quality are collected. Both the
software process and products are
quantitatively understood and controlled.
Narrowing the variation in process performance
to fall within acceptable quantitative bounds
When known limits are exceeded, corrective
action can be taken
Quantifiable and predictable
predict trends in process and product quality
Level 5: Optimizing
Continuous process improvement is
enabled by quantitative feedback
from the process and from piloting
innovative ideas and technologies.
Goal is to prevent the occurrence of
defects
Data on process effectiveness used
for cost benefit analysis of new
technologies and proposed process
changes
Internal Structure to
Maturity Levels
Except for level 1, each level is
decomposed into key process areas (KPA)
Each KPA identifies a cluster of related
activities that, when performed
collectively, achieve a set of goals
considered important for enhancing
software capability.
commitment
ability
activity
measurement
verification
What are the benefits ?
Helps to produce a shared vision of
what software process improvement
means for the organization
Defines set of priorities for addressing
software problems
Supports measurement of process by
providing framework for performing
reliable and consistent evaluations
Provides framework for consistency of
processes and product
Why measure software
and software process?
Obtain data that helps us to better control
schedule
cost
quality of software products
Measurements
Historical
Plan
Actual
Projections
SEI Core Measures
Unit of Measure Characteristics Addressed
Physical source lines of code Size, reuse, rework
Logical source lines of code
Staff hours Effort, cost, resource allocations
Calendar dates for process Schedule, progress
milestones
Calendar dates for deliverables
Problems and defects Quality, improvement trends,
rework, readiness for delivery
Examples of
measurements for size of
work products
Estimated number of requirements
Actual number of requirements
Estimated source lines of code (SLOC)
Actual SLOC
Estimated number of test cases
Actual number of test cases
Example of
measurements of effort
Estimated man-hours to design/code a given
module
Actual man-hours expended for
designing/coding the module
Estimated number of hours to run builds for a
given release
Actual number of hours spent running builds for
the release
Examples of
measurements of quality
of the work product
Number of issues raised at requirements
inspection
Number of requirements issues open
Number of requirements issues closed
Number of issues raised during code inspection
Number of defects opened during unit testing
Examples of
measurements of quality
of the work product
Number of defects opened during system
testing
Number of defects opened during Unit Testing
Number of defects still open
Number of defects closed
Defect age
Examples of
measurements of quality
of the work product
Total number of build failures
Total number of defects fixed for a given
release
Total number of defects verified and accepted
Total number of defects verified and rejected
