1. 31 1
Brief Presentation on
Software Process Improvement
using the CMM Framework
and
How Some Development
Corporations See Themselves…
(in Jacksonville)
Robert F. Roggio
Pratibha Kashyap
2. 31 2
Background / Previous Work
This is a presentation emanating from a follow on paper to research
conducted and reported on at the Pacific Northwest Software
Quality Conference, October, 2000. The paper and this
presentation were extracted from Pratibha’s project for her M.S.
Survey and resulting statistics came from a survey in a large
metropolitan city in the South – two large, two medium, and two
small software developers – based on numbers of developers
Built questionnaire based primarily on the CMM and its Key Process
Areas (KPAs) and Key Practices (key terms in the CMM)
Reported results
Please note: There are newer and different versions of the CMM.
These slides reflect the ‘first’ CMM Framework. Nevertheless, the
thrust of the CMM slides presented herein still apply.
3. 31 3
Overview
1. Introduction to the CMM
• Maturity Levels, Key Process Areas, and
other terms in the CMM architecture.
2. Self-Organizational Assessment
3. Survey Instruments and Process
4. Factors affecting Software Process
Improvement (SPI)
4. 31 4
Capability Maturity Model (CMM)
CMM – a framework/model for undertaking
continuous process improvement of an organization’s
software process.
Organizations are assessed as to the ‘maturity’ their
software process exhibits.
Maturity levels consist of sets of process goals such
that when satisfied, stabilize an important component
of their software process.
– Higher the level implies an increased process capability.
– The framework prioritizes improvement actions for
increasing software process maturity.
– This all implies that an organization’s process must be
‘assessed.’
5. 31 5
Materials taken directly (or
almost directly) from The
Capability Maturity Model –
Guidelines for Improving the
Software Process, by several
authors most of whom are
affiliated with the SEI.
Lot of key words here…
6. 31 6
What do the level names mean?
Level 1: Initial Level:
– Software processes ad hoc; sometimes
chaotic. Laissez-faire.
– Successes dependent upon individual(s)
and heroics.
– Few processes, if any, are defined.
– Repeatable? only if same people assigned
– Capability is a characteristic of the
individuals and not the organization
7. 31 7
Maturity Levels - CMM
Level 2: Repeatable Level:
– Basic project management processes:
• established to track cost, schedule, and functionality.
– A necessary process discipline in place.
• repeat earlier successes on projects w/similar applications.
– Software process capability (Level 2 organizations)
Summarized as disciplined
– Planning and tracking of project is stable
– Earlier successes can be repeated.
– Project’s process - under the effective control of a
project management system w/realistic plans based
on the performance of previous projects.
– Emphasis: Project Management
8. 31 8
Maturity Levels (continued)
Level 3 – Defined Level:
– 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.
– An organization-wide training program is
implemented to ensure that the staff and
managers have the knowledge and skills
required to fulfill their assigned roles.
9. 31 9
Level 3 – Defined (continued)
Level 3 – Defined (continued)
– Projects tailor the organization’s standard software
process to develop their own defined software
process, for unique characteristics of a project.
• This tailored process is referred to in the CMM
as the project’s defined software process.
• This defined software process contains a coherent,
integrated set of well-defined software engineering and
management processes.
– A well-defined process will include:
• readiness criteria,
• inputs,
• standards and
• procedures for performing the work,
• verification mechanisms (such as peer reviews),
• outputs, and
• completion criteria.
10. 31 10
Level 3 – Defined (continued)
Level 3 – Defined (continued)
– Because process is well defined,
management has good insight into
technical progress on the project.
– Characteristics:
• The software process is standard and
consistent with both software engineering and
management activities
• Stable and repeatable.
– The process capability is based on a
common, organization-wide understanding
of the activities, roles, and responsibilities
in a defined software process.
11. 31 11
Maturity Levels (continued)
Level 4 – Managed:
– Organization’s set quantitative quality goals for both
software products and processes.
– All projects part of an organizational
measurement program.
– The capability is quantifiable and predictable
because the process is measured and operates
within quantitative limits.
– Because process - both stable and measured -
exceptional circumstances can address ‘special
causes’ of the variation.
– When predefined limits are exceeded, actions are
taken to understand and correct the situation.
– Software products are of predictably high quality.
12. 31 12
Maturity Levels (continued)
Level 5 – Optimized
– Focus: continuous process improvement
– At the Optimizing Level, the entire organization is
focused on continuous process improvement.
• The organization has the means to identify weaknesses
and strengthen the process proactively, with the goal of
preventing the occurrence of defects.
– Innovations that exploit the best software
engineering practices are identified and transferred
throughout the organization.
– These organizations continuously strive to
improve the range of their process capability,
thereby improving the process performance of their
projects.
13. 31 13
Structure of the Model
The CMM is a framework representing a path of
improvements recommended for software
organizations that want to increase their software
process capability.
The model describes essential (key) attributes that
would be expected to characterize an organization at
a particular maturity level.
A maturity level is a well-defined evolutionary plateau
toward achieving a mature software process.
The five maturity levels provide the top-level structure
of the CMM.
– Each level indicates a level of process capability.
15. 31 15
Key Process Areas
‘Maturity levels’ contain several KPAs
Each KPA has a set of goals that must
be satisfied to satisfy that KPA.
KPAs address a cluster of related
activities (Key Practices - ahead) that,
collectively when addressed, achieve a
set of goals.
Key Practices are the ‘whats’ (not hows)
that must be satisfied to meet the goals
of a specific maturity level.
16. 31 16
Initial
Requirements Management
Software Project Planning
Software project tracking and oversight
Software subcontract management
Software Quality Assurance
Software Configuration Management
Repeatable
Defined
Managed
Optimizing
Organization process focus
Organization process definition
Training Program
Integrated Software Management
Software Product Engineering
Intergroup coordination
Peer Reviews
Quantitative Process Management
Software Quality Management
Defect Prevention
Technology Change Management
Process Change Management
Key Process Areas (KPAs)
by Maturity Level
When the Key Practices
for each KPA are satisfied,
the goals for that KPAs
are met. For a given
maturity level,
all KPAs must be satisfied.
Levels and their
respective KPAs
are shown.
Notice Level 2
More to do with
Project Management
Notice Level 3
More to do with
Process Management
(also organizational thrust)
17. 31 17
Key Practices for a KPA
Each KPA - described in terms of Key Practices.
Satisfying the Key Practices = essential to
meeting the goals of that KPA.
– Equivalently, key practices describe the activities and
infrastructure that contribute most to the effective
implementation and institutionalism of the KPA.
Important to note: Key Practices evolve as
organization achieves higher level of maturity.
They do NOT go away.
A level-3 shop satisfies all KPAs of a level-2
shop
18. 31 18
Key Practice – Evolution Example
Many of the project estimating capabilities described in
the Software Project Planning KPA at Level 2 must
evolve to handle additional project data available at
Level 3, described in Integrated Software
Management, a level 3 KPA
Key Practices describe WHAT is to do – not how.
Again, satisfaction of KP necessary to meet goal of
KPA.
Each Key Practice consists of a single sentence often
followed by a more detailed description, which may
include examples and elaboration.
19. 31 19
2. Organizational Self-Assessment
Now a bit of Student Research
– 65 companies; 55 responses – with pressure!
Ms. Pratibha Kashyap surveyed a number of
business in Jax
– Size: (Six: two of each ‘size’, where size based on
number of developers)
– Self-perceptions as to how they met the maturity
levels (hence KPAs and then Key Practices…)
Analysis of their perceptions
20. 31 20
Organization's Position at CMM Level-2
0.0
1.0
2.0
3.0
4.0
5.0
1 2 3 4 5 6
Organizations
Range
(1-Never
Thru
5-Always)
Requirements management Project Planning
Project Tracking Software Quality Assurance
Configuration Management
Key Process Areas for Level 2
21. 31 21
Organization's Position at CMM Level-3
0.0
1.0
2.0
3.0
4.0
5.0
1 2 3 4 5 6
Organizations
Range
(1-Never
thru
5-Always)
Organization Process Focus Software Process Definition
Training program Integrated Software Managemen
Software Product Engineering Inter-group Coordination
Peer Reviews Defects are Tracked
Key Process Areas for Level 3
22. 31 22
KPAs:
Organization's Position at CMM Level-4
0.0
1.0
2.0
3.0
4.0
1 2 3 4 5 6
Organizations
Range
(1-Never
thru
5-Always)
Quantitative
Process
Management
Measurable
Quality Goals
are defined
Progress
towards these
Goals are
tracked
23. 31 23
Key Process Areas for Level 5
Organizations' Position at CMM Level-5
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
1 2 3 4 5 6
Organizations
Range
(1-Never
thru
5-Always)
Defect Prevention activities are planned
Common Causes of Defects are Identified
Technology Change Management
Appropriate New Technologies are transferred in to normal practice
Process Change Management to improve continually
KPAs:
24. 31 24
3. Survey Instruments and Process
Instruments divided into components
administered to
– Project Leaders and to
– Developers.
– Sometimes both.
Designed to ascertain their perceptions
of how well these companies perceived
themselves satisfying the KPAs of the
individual levels via the Key Practices.
26. 31 26
* Are software processes, procedures, and standards defined (what and how), documented,
validated for correctness, practiced (used), improved (new technology) etc.
Figure 3. Section 2 of Survey (Developers and Management)
30. 31 30
4. Factors Affecting
Software Process Improvement (SPI)
•Management’s commitment and support
• Dedicated group
• Projects driven by schedule
• Personal involvement in overseeing
• Middle management’s involvement
• Organizational structure and politics
