Software Process Improvement

Capability Maturity Models

1
 Content
Process, product, people, quality
What are maturity models?
CMMI models
Operational use of the CMMI
People-CMM

2
The Capability Maturity Model (CMM) is a development model
created in 1986 after a study of data collected from
organizations that contracted with the U.S. Department of
Defense, who funded the research. The term "maturity" relates
to the degree of formality and optimization of processes, from ad
hoc practices, to formally defined steps, to managed result
metrics, to active optimization of the processes.
The model's aim is to improve existing software
development processes, but it can also be applied to other
processes.
In 2006, the Software Engineering Institute at Carnegie Mellon
University developed the Capability Maturity Model Integration,
which has largely superseded the CMM and addresses some of its
drawbacks
3
 Process and product quality
• Process is a term used to describe the people, methods, and
tools used to produce software products.
• Improving the quality of the product is believed to be based
on improving the process used to develop the product.
• Improvement of the process give benefits because the quality
of the product depends on its development process.
• For industrial production, process is the principal quality
determinant.
• For design-based activities, the capabilities of the designers
are also an important factor

4
Principal product quality factors

Development
technology

Process Product People

quality quality quality

Cost, time and

schedule

5
Software Process Improvement stages
• Process measurement
– Attributes of the current process are measured.
These are a baseline for assessing improvements
• Process analysis
– The current process is assessed and bottlenecks
and weaknesses are identified
• Process change
– Changes to the process that have been identified
during the analysis are introduced

6
Elements of an SPI framework

7
 What is a maturity model?
‘A maturity model is a model with which organizations can judge
their (software engineering, hrm, service, etc.) process (including
comparing it to other organizations) and based on this judgment can
improve their process.’
 started in 1986 by the Software Engineering Institute (SEI)
(Carnegie Mellon University) and the Mitre Corporation
SEI started with a Process Maturity Framework and a
maturity questionnaire
the software Framework developed into the Capability
Maturity Model (CMM) for Software (1991)
Revised maturity framework (CMMI) introduced in 2001

8
 Process Maturity Framework
Goal is the improvement of the software engineering process
– Success should not be based on incidental individual achievements
– Success should be based on repeatable and proven successful work
methods
Immature Mature
Software Software
Organization Organization

-No objective basis for judgment of -Organization wide knowledge to

product quality manage software development,
- No objective basis for improvement of employment and improvement
product or process quality - Processes are ‘fit-for-use’
- Reviews and tests are often skipped - Processes are being adapted to the
when projects run behind schedule situation
- Ad hoc management -Tasks and responsibilities are clear
for the project and anyone in the
organization
9
 Software Process
Software Process:

‘the whole of activities, methods, practices, communication

and changes that people use in order to develop and
maintain software and associated products (e.g. plans,
design documents, code, test cases and user manuals)’

CMM gives an organization a way

to get and improve control over the software
process and provides it with a route to achieve excellence
in software engineering

10
 Fundamental concepts for
Process Maturity
Software Process Capability
–How good it can predict the expected outcome of a next
software project
Software Process Performance
–Actual results of a software project
Software Process Maturity
–The level in which a software process is explicitly defined,
managed, measured and controlled in order to achieve results
Software Process Institutionalization
–The level in which the software process is institutionalized
with respect to methods, standards and organizational structure
11
 Levels of software maturity
Maturity level:
A well defined level on the way to achieve an adult, a mature
software process
A foundation for realizing continuous improvements
Every level contains a group of process goals that, when stable, form
an important part of the software process
Every level leads to the improvement of the process capability of the
organization

12
 The Software Engineering Institute (SEI) Capability Maturity Model
(CMM) specifies an increasing series of levels of a software
development organization. The higher the level, the better the software
development process, hence reaching each level is an expensive and
time-consuming process

 The CMM has four intended uses [Weber91] to help organizations

improve their software process capabilities:
 1. Identify improvements
 2. Identify risks in selecting contractors
 3. Implement a process improvement program
 4. Guide definition and development of the software process

13
The staged CMMI model

14
 Initial (1)
The software process can be described as ad-hoc, or even
chaotic
There are practically no processes defined
Success depends on individual input and achievements
The software process is not predictable regarding results
Schedules, budget, functionality and product quality is not
predictable
Works disastrous in crises situations
Can be successful in highly innovative environment
(e.g. start of the web-design world)

15
 Managed (2)
The basic project management procedures are used
Costs, schedules en functionality are ‘tracked’
Planning and managing of new projects are based on experience
with comparable projects
Needed process discipline is enforced such that earlier success can
be repeated with building an comparable application
Software requirements and work products are ‘baselined’
Disciplined environment in which planning and tracking are stable
and thus previous successes can be repeated

16
 Defined (3)
Processes for management and software engineering are
documented, standardized and integrated in a standard software
development process
All projects use an approved, adapted version of the standard
software process for the development and maintenance of software
Processes are used to let software managers and engineers be more
effective
There is a group responsible for the software process
There is training in the software process
The software process is stable and well defined and is able to
operate more effectively

17
 Quantitatively managed (4)
Detailed metrics of the software processes and quality of products
are gathered
Quantitative goals are set for the software process and the product
quality
Use is made of a software process database in which the metrics
are gathered and analyzed
Projects have a control over the software process and product
quality such that the can work in defined limits
Risks of development in new technical environments are
recognized and managed
Software process is predictable and trends can be predicted

18
 Optimizing (5)
Continuously software process improvements are realized by
quantitatively feedback of the process and by trying out of
innovative ideas and technologies
The whole organization is focused on continuous improvement
Data regarding performance of the processes are used for cost-
benefit analyses
Innovations that make use of the best software engineering
practices are identified and spread over the whole organization
Software project teams analyze errors in order to find out how to
improve
‘Lessons learned’ are shared with other projects (team rooms,
Communities of Practice)

19
 Maturity level and changing predictability
Chance

Goal N-z
Level 5: Optimizing
Chance

Goal N-y

Level 4: Quantitatively Managed

Chance

Goal N-x

Level 3: Defined
Chance

Goal N+a

Level 2: Managed
Chance

Goal N

Level 1: Initial

Time/Money/… 20
 Operational use of CMM
How do you determine in practice the maturity of an organization?

Maturity
Level
Indicate Contain
Process
Capability Key Process
Achieve Areas
Organized by
Goals
Common
Features
Address Contain
Implementation or Key
Institutionalization
Practices
Describe
Infrastructure or
Activities
21
 Key Process Areas
Optimizing (5)

-Process change management

-Technology change management
-Defect prevention
Quantitatively
Managed (4) -Software quality management
-Quantitative process management
-Peer reviews
-Intergroup coordination
Defined (3) -Software product engineering
-Integrated software management
-Training program
-Organization process definition
Managed (2) -Organization process focus

-Software Configuration Management

-Software Quality Assurance
-Software Subcontract Management
Initial (1) -Software project tracking & oversight
-Software project planning
-Requirements Management 22
 Example

Maturity Level 2

Managed
Indicates Contains Key Process Area
Disciplined
Processes Software
Achieves Project Planning
Organized by Common
Software estimates are Feature
Activities
documented for use
Performed
in planning and tracking Address Contain Key Practice

Implementation Activity 9. Estimates for the size of the

Describe software work products (or changes to it)
are derived according to
Activity a documented procedure
23
 Continuous CMM model
Project monitoring
and control

Supplier ag
reement
management

Risk
management

Configuration
management

Requirements
management

e
Vrification

a
Vlidation

1 2 3 4 5

A process capability profile

24
 Remarks
Maturity Models are helpful to indicate the maturity of a software
organization
The CMM(I) model is the most used
Organizations ‘benchmark’ themselves to position them relative to
others based on the CMM-level
CMM-level should give an indication of the quality level of a
software organization
Specially “new” countries (India, China) qualify themselves
strongly in this area
It is not a “sacred cow” and it should be used prudently

25
 People- Capability Maturity Model (P-CMM)

• Improvement of the capabilities of the software

organization by improvement of the skills of the
individuals
• Assure that the ability in software development is an
attribute of the organization and not of a number of
individuals
• Keeping people with critical knowledge and skills in
the organization
• Assure that the goals and direction of the individuals
is the same as that of the organization
26
P-CMM Architecture

27
P-CMM levels and process areas

28
Process Area & Maturity Levels

29
 Process Goals & Process Practice
• Process area goal is an organizational state to be
achieved by implementing the practices of a process
area.

• Process practice is a sub process within a process area

that contributes to achieving a process area goal.

30
Implementation & Institutionalization
Practices

31
 Other SPI frameworks
• SPICE— a international initiative to support the
International Standard ISO/IEC 15504 for (Software)
Process Assessment [ISO08]
• Bootstrap—a SPI framework for small and medium
sized organizations that conforms to SPICE [Boo06],
• PSP and TSP—individual and team specific SPI
frameworks ([Hum97], [Hum00]) that focus on
process in-the-small, a more rigorous approach to
software development coupled with measurement
• TickIT—an auditing method [Tic05] that assesses an
organization compliance to ISO Standard 9001:2000
32
 SPI trends
• future SPI frameworks must become significantly
more agile
• Rather than an organizational focus (that can take
years to complete successfully), contemporary SPI
efforts should focus on the project level
• To achieve meaningful results (even at the project
level) in a short time frame, complex framework
models may give way to simpler models.
• Rather than dozens of key practices and hundreds of
supplementary practices, an agile SPI framework
should emphasize only a few pivotal practices
33
The five Software Capability Maturity levels have been defined
as

• 1. Initial
• The software process is characterized
as ad hoc, and occasionally even
chaotic. Few processes are defined, and
success depends on individual effort
and heroics.

34
• 2. Repeatable
• Basic project 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

35
• 3. Defined
• The software process for both management and
engineering activities is documented,
standardized, and integrated into all processes for
the organization. All projects use an approved
version of the organization's standard software
process for developing and maintaining software

36
• 4. Managed
• Detailed measures of the software process and
product quality are collected. Both the software
process and products are quantitatively
understood and controlled.

37
• 5. Optimizing
• Continuous process improvement is enabled by
quantitative feedback from the process and from
piloting innovative ideas and technologies.

38