CAPABILITY MATURITY

MODEL
(CMM)
By: Nazish Nouman

Basic rules in
improvements (1)
If you dont know

where you are,

a map wont help
Watts Humprey

Basic rules in
improvements (2)
You need to know

where you are,

before you can decide
where to go!
Grosby

Common problems in SW projects

Project having always resource problems
Quality criterias not always met
Not enough competence in all projects
Unexpected surprises in projects
(technical & administrative)
Unstable input documents/products
Improvements not meeting the real work
...

SW crisis

Factors leading to the establishment of the SEI

(Software Engineering institute) and later on creation of
CMM:
Increasing cost of SW
Quality problems in SW products
Cost of SW maintenance
Government put billions of dollars in SW acquisition
Increasing rate of change in technology and SW
environment
Typical SW project was a year late and exceeded two times
the
budget
Increasing SW complexity

CMM

CMM was developed and is promoted by the Software

Engineering Institute (SEI), a research and development
center

The Software Engineering Institute (SEI) at Carnegie Mellon

University has created the Capability Maturity Model (CMM)
which systematically defines and refines software
development efforts

In 1991, SEI released the Capability Maturity Model for

Software version 1.0.

In 2001, SEI released the Capability Maturity Model

Integrated(CMMI), superseding the CMM for software.
6
of
31

What is the CMM?

The CMM for Software (SW-CMM) is a framework

that described the key elements of an effective
software process.
The CMM guides software organizations striving
to gain control of their processes for developing
and maintaining software, evolve toward a
software engineering culture, and management
excellence.
The CMM describes an evolutionary improvement
path for software organizations from an ad hoc,
immature process to a mature, disciplined one.

What is CMM??

The Capability Maturity Model (CMM) is a methodology

used to develop and refine an organization's software
development process.

Strategy for improving the software process

Describes principles and practices
Helps organizations to create useful software efficiently

and consistently

The model describes a five-level evolutionary path of

increasingly organized and systematically more mature
processes.

Why CMM?

Organized as a set of maturity levels.

Provides organizations with guidance on how to gain

control of their processes.

how to evolve toward a culture of software engineering

and management excellence.

well-defined incremental stages

software process maturity.

Focuses on
processes.

the

development

toward

of

the

effective

goal

of

software

9
of
31

Mature vs immature software organization

The difference between immature and

mature software development
organizations is the existence and
maturity of their software processes.

10
of
31

Immature vs. Mature Software

Organizations

Immature
No objective basis for judging product quality
Activities that enhance qualities are curtailed when the project falls
behind on schedule

Mature
Well-planned and communicated process of managing and
maintaining software
Mandated processes are documented, usable, updated and consistent
Realistic estimates (cost and time) and active involvement by
everyone
managers monitor the quality of the software products and customer
satisfaction in a quantitative manner, and have continuous
refinement built into the process.

Maturity Levels

Levels 1 through 5 of the SW-CMM define a path toward

organizational improvement. The practices are 'graduated' in
the sense that the levels build on one another.

Bearing in mind that change cannot occur overnight, the

CMM induces change incrementally.

Five different levels are of maturity are defined and an

organization then advances slowly in a series of small,
evolutionary steps toward the higher levels of process
maturity
12
of
31

5-Levels of CMM
1.
2.
3.
4.
5.

Initial ------------ Ad hoc Process

Repeatable------ Basic Project management
Defined----------- Process definition
Managed===== Process Measurement
Optimizing==== Process Control

13
of
31

Maturity steps

Continuous
Level
process
Level5:
5:
Optimising
Optimising
improvement
Process
Level
Level4:
4:
control
Managed
Change
Managed
Process
managemen
Level
definition
Level3:
3:
Defined
Standard,
Defined
Quantitative
consistent process
management

Process
discipline

Level
Level1:
1:
Initial
Initial

Level2:
Level2:
Repeatable
Repeatable

Engineering
management

Project
management

CMM structure
Level
5
Optimizing
4
Managed

3
Defined

Key Process Areas

Defect Prevention
Technology Innovation
Process Change Management

Continuous process
improvement

Quantitative Process Management Product and process

quality managed by facts
SW Quality Management
Organisation Process Focus
Organisation Process Definition
Peer Reviews
Training Program
Intergroup Coordination
SW Product Engineering
Integrated SW Management

SW Project Planning
SW Project Tracking
2
Repeatable SW Subcontract Management
SW Quality Assurance
SW Configuration Management
Requirements Management
1
Initial

Focus

Standardised SW
engineering process

Disciplined project
management
The commitment
process
Heroes

(Version 1.1)

Level 1: Initial

At theinitiallevel, processes are disorganized, even chaotic. Success is likely

to depend on individual efforts, and is not considered to be repeatable,
because processes would not be sufficiently defined and documented to
allow them to be replicated.

No formal procedures

No cost estimates

No project plans

No key processes

Weak management practices

Poorly controlled commitments

processes are ad hoc

practices are sacrificed for schedule

Practitioners resist discipline

Results are unpredictable

16
of
31

Level 1: the Initial Level

Success depends on heroes
Good performance is possible but

Requirements often misunderstood, uncontrolled

No change control
Teams not coordinated, not trained
Defects proliferate(grow)

Software installation and maintenance often

present serious problems

No design and code reviews
No test data analysis
17
of
31

Level 2: Repeatable

At therepeatablelevel, basic project management techniques are established, and

successes could be repeated, because the requisite processes would have been
made established, defined, and documented.

Project

management structures and controls begin here.

Basic

project management processes are established to track cost, schedule, and

functionality.

Project management is strong and lays foundation for

process discipline

Project activities are planned and followed

Project ensures that practices are performed

Corrective actions are made when necessary

Project own its commitments

Commitments are clear and communicated

Necessary baselines are build and controlled

What Happens During

Level 2

Processes become easier to digest and

understand
Managers and team members spend less time
explaining how things are done and more time
doing
Projects are better estimated, better planned, and
more flexible
Quality is integrated into the project
Costs may go up initially, but do go down over
time
And yes, there may be more documentation and
paper

The key components of project

management at level -2 are:

Requirements Management

Software Project Planning

Software Project Tracking and Oversight

Software Quality Assurance

Software Configuration Management

21
of
31

Level 3: Defined

At thedefinedlevel, an organization has

developed its own standard software
process through greater attention to
documentation, standardization, and
integration.

22
of
31

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.

Activities include peer reviews, product engineering, CASE tool usage,

testing standards, and full lifecycle configuration management.

Software methodology is customized for each specific project

Training program is implemented

All projects use an approved, tailored version of the organization's

standard software process for developing and maintaining software.

Training plans are created and followed
(project and organisation levels)
More systematic technical coordination between different project
groups

23

What Happens During

Level 3
Process Improvement becomes the
standard Cross-Functional teams look for
ways to short-cut the system
Solutions go from being coded to being
engineered
Quality gates appear throughout the
project effort with the entire team involved
in the process, reducing rework
Risks are managed and dont take the
team by surprise

key process areas at level

3
The key process areas at level 3 address both
project and organizational issues. The
expected activities are:
Organization Process Definition
Training Program
Intergroup Coordination
Peer Reviews

25

Level 4: Managed

At themanagedlevel, an organization monitors

and controls its own processes through data
collection and analysis.

Detailed time, cost, defect rates and other

metrics are collected and used to quantitatively
manage software development throughout the
software process of every project. The
organization has a quality focus, with tools and
training to support development.

26

Level 4: Managed

Processes and products are on statistical control

The process information is stored in a central repository

Quantitative limits are established for process performance

Process performance is managed (I.e. quantitatively controlled)

Organizations predict software development efforts and quality

Data is actively used as a base in decision making

Detect and correct variations from the expected performance.

This level sets the foundations of a truly quality oriented

organization.

Level 5: Optimizing
At the optimizing level, processes are constantly being improved through
monitoring feedback from current processes and introducing innovative
processes to better serve the organization's particular needs.

Continuous process improvement in place through quantitative management

At

this level the entire organization is structured around a quality focus.

Processes

and technology are continuously evaluated

Processes

such as software inspection, code walkthroughs, automatic metrics

collection, and technology review are part of the standard development methodology.

Individuals are empowered to improve their processes

The causes of defects are eliminated as part of preventive quality work

New technologies can be utilized effectively to improve process capability

The

knowledge gained from each from each project is utilized in future projects.

The process incorporates a positive feedback loop, resulting in a steady improvement

in productivity and quality.

CMMI
New version of CMM

CMMI is the successor of the Capability

Maturity Model (CMM) or Software CMM.
The CMM was developed from 1987 until
1997. In 2002, CMMI Version 1.1 was
released.