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