CAPABILITY MATURITY MODEL

for Software (CMM)

Version 1.1
INTRODUCTION
 Course Objectives

• Understand terms such as process, capability, and

maturity
• Discuss the 18 key process areas in the CMM
• Interpret the CMM and the key practices in the
different contexts
• Describe the fundamental concepts of the CMM
• Explain and use the structure of the CMM
 What can go wrong in a
project?
• Bad requirements
• Frequent changes to
requirements
• Wrong interpretation of
requirements
• Inaccurate estimation
• Inaccurate or bad planning
• Risks which materialized
• Attrition
• Bad implementation
• No reviews i.E., Inputs from
relevant people/ groups
• Mismatched resource skill
levels
• Miscommunication between
groups
• No defined method for
implementing a project
• No checks and balances
• Inadequate testing
• Incorrect source base and
so on
 Do we need processes?

Do we need processes? Such discipline may

stifle my creativity!

“Discipline enables creativity by FREEING the

most talented software professionals from the
many CRISES that others have created. A
disciplined process EMPOWERS the intellect...”
- Watts Humphrey
 What Is CMM ?

 A common sense application of process management

and quality improvement concepts to software
development and maintenance

 A community-developed guide

 A model for organizational improvement

 Other Capability Maturity
Models

Focus areas include :

 Software CMM
 People CMM
 CMMI - CMM integrated (new)
 A Mature Process

 Consistent with the way work actually gets done -

defined, documented, and continuously improving
 Understood
 Used
 Living
 Supported visibly by management and others
 Well controlled
 Constructive use of product and process
measurements
 Disciplined use of technology
 Institutionalized Process
“That is the way we do things around here”
 Organizational infrastructure contains
 Effective processes
 Usable processes
 Consistently applied processes
 Organizational culture
 Must convey the process
 Nurtured by management
 Is conveyed with role models and rewards
 Institutionalized processes ENDURES
( Even after people who originally defined them have gone)
 What CMM Does not
address?
 The CMM does not address specific software
process and quality improvement issues
 Issues that are addressed only indirectly,
or by implication, include
 Specific tools, methods, and
technologies
 System engineering, marketing, etc
 Human resources
 Organizational behavior
Structure of CMM
 CMM Maturity Level

Maturity level is
 Well-defined stages of evolution on the path
to becoming a mature software
organization
 Each level is a layer in the foundation for
continuous process improvement
 Achieving each level establishes a different
component of the software process
CMM Maturity Level
There are five maturity levels in CMM
 Intent of the Initial Level
-Level 1

 Performance driven by the competence of

the people doing the work
 High quality and exceptional performance
possible so long as the best people can be
hired
 The process is unpredictable - for good or bad
 The major problems facing the software
organization are managerial, not technical
 Intent of the Repeatable
Level - level 2

 The predominant need is to establish

effective software project management
 Software project management processes
are documented and followed
 Organizational policies guide the projects
in establishing management processes
 Successful practices developed on earlier
projects can be repeated
 Intent of the Defined Level
- Level 3
 This level builds on the software project
management foundation
 To control a process, it must be defined,
documented, and understood
 The outputs of one task flow smoothly in
to the inputs of the next task
 At this level, the organization builds
processes that empower the individuals
doing the work
 Intent of the Managed
level - Level 4
 Apply the principles of statistical process
control
 Address the special causes of process
variation
 Intent Of The Optimizing
level - Level 5

 Identify and eliminate chronic causes of

poor performance
 Continuously improve the software process
 Key Process Area (KPAs)
of Each Level

Maturity levels are described in terms of 18 key process areas (KPAs)

 Level 2 KPAs

 Software configuration management (SCM)

 Software quality assurance (SQA)
 Software subcontract management (SSCM)
 Software project tracking and oversight (SPTO)
 Software project planning (SPP)
 Requirements management (RM)
 Level 3 KPAs

 Organization process focus (OPF)

 Organization process definition (OPD)
 Peer reviews (PR)
 Intergroup coordination (IGC)
 Software product engineering (SPE)
 Integrated software management (ISM)
 Training program (TP)
 Level 4 KPAs

 Software quality management (SQM)

 Quantitative process management (QPM)
 Level 5 KPAs

 Process change management (PCM)

 Technology change management (TCM)
 Defect prevention (DP)
 Maturity levels cannot be
skipped
• Processes at higher maturity levels may
be performed, although perhaps
ineffectively, even by the organizations at
the initial level

• Process capability is built in stages, as

some processes are ineffective when others
are not stable
 Maturity levels

 Well-defined evolutionary plateaus on the

path to becoming a mature software
organization
 Each level is a layer in the foundation for
continuous process improvement
 There are five maturity levels in the CMM
 Achieving each level establishes a different
component of the software process
 Maturity levels are described in terms of 18
key process areas
 Goals

 Goals summarize the key practices of the

key process areas
 They are considered important for enhancing
process capability for that level of maturity
 They can be used to guide organizations
and appraisal teams in assessing alternative
ways to implement key process areas
 Each key process maps to one or more
goals
 Common features

• Used to organize the key practices in each

key process area
Common features are :
– Commitment to perform
– Ability to perform
– Activities performed
– Measurement and analysis
– Verifying implementation
 Commitment to perform

• Describes the actions the organization must

take to ensure that the process is
established and will endure

• Typically include

– Policies
– Leadership
 Ability to perform
• Describes the preconditions that must exist
in the project or organization to
implement the software process
competently
• Typically includes
– Function
– Resources
– Delegation
– Training
– Orientation
 Activities performed

• Describes the roles and procedures

necessary to implement a key process
area
• Typically includes
– Establishing plans and procedures
– Performing the work
– Tracking it
– Taking corrective actions as necessary
 Measurement and
analysis

• Describes the need to measure the

process and analyze the measurements
• Typically includes examples of the
measurements that could be taken to
determine the status and effectiveness of
the activities performed common feature
 Verifying implementation

• Describes the steps to ensure that the

activities are performed in compliance with
the process that has been established
• Typically includes reviews and audits by
– Senior management
– Project management
– Software quality assurance
 Key Practices

• State the fundamental policies, procedures,

and activities for a key process area
• Describe “what” is to be done, but they
should not be interpreted as mandating
“how”
• Are organized by common feature
• 316 key practices in CMM
End of Introduction to CMM