Capability Maturity Model (CMM)

Birla Institute of Technology, Patna Campus

Computer Science and Engineering

Neeraj Kumar
BE/5699/08
[email protected]
+91-7549393020
Some Definitions

• Software Process
– set of activities, methods, practices, and transformations used to develop and maintain
software and associated products
• project plans, design documents, code, test cases, user manuals

• Software Process Capability

– knowing what the above will give you

• Software Process Performance

– actual results from the above

• Software Process Maturity

– how well the process is specific process is explicitly defined, managed, measured,
controlled, and effective
– also includes consistency and change
Software Process Improvement

• Six steps to improve software capabilities through

process improvements (one method)
1. Understand the current development process or
processes
2. Develop a vision of the desired process
3. List the required process improvement actions in order
of priority
4. Produce a plan to implement the actions
5. Commit the resources and execute the plan
6. Start over at step 1
Immature Software Organization

• Does not mean they produce poor code

• Characterized by
– ad-hoc/improvised processes (project dependant)
– process are not rigorously followed (if specified)
– reactionary to immediate crisis (“fighting fires”)
– quality and function compromised to meet schedule
• quality related activities often eliminated due to schedule pressures
– schedules and budgets routinely exceeded
– no objective basis for measuring quality
• hard to predict future events...
Mature Software Organizations

• Does not mean they produce good code, but

• Characterized by
– organization wide ability for managing software development and
maintenance
– process is integral to the organization
• communicated to staff + staff follow process
– process is useable and useful
– process is not static (evolves in controlled manner)
• “fit for use” + updated as necessary
– objective and quantitative quality metrics
– schedules and budgets based on historical data
• and thus usually achieved
The Birth of CMM

• 1986, the Software Engineering Institute (SEI), investigated

“maturity framework” (Watts Humphrey)

• 1987 questionaires
– software capability evaluation
– maturity questionaire

• 1991 - CMM
– a set of key processes and recommended practices
– guidance on how to gain control of their process and how to evolve
toward a culture of software engineering and management excellence
Observations that motivated CMM

• productivity and quality gains from methodologies and

technologies not near what was expected in the early 80s

• difficult to do better in a chaotic process

• in undisciplined organizations, most projects produce poor results

• in undisciplined organizations, some projects produce excellent

results
– usually the result of heroic effort
– repeating the result means repeating the heroics
Capability Maturity Model (CMM)

• used as a standard for appraising the current state of the

organization’s software process
• used as a guide for identifying and prioritizing the actions
comprising the software process improvement effort
• Made up of 5 levels and 18 key process areas (KPAs)

• a CMM-based maturity questionnaire may be used to

assess the software capability of a particular organization
– government may use this to assess the capability of potential
software development contractors
CMM Levels

1 Initial Competent People and Heroics

2 Repeatable Project Management process

3 Defined Engineering Process & Org Support

4 Managed Product and Process Quality

5 Optimizing Continuous Process Improvement

Basic descriptions of CMM levels
1. Initial • software process is ad hoc, maybe even chaotic; few
processes are defined; success depends on individual effort
and heroics

2. Repeatable • basic project management practices to track cost, schedule,

functionality; necessary process discipline is in place to
repeat earlier successes on projects with similar applications

• software process for both management and engineering

3. Defined activities is documented, standardized, integrated into a
standard software process; all projects use an approved,
tailored version of the organization’s standard software
process for developing and maintaining software

• detailed measures of the software process and product

4. Managed quality are collected; both the software process and
products are quantitatively understood and controlled

5. Optimizing • continuous process improvement is enabled by quantitative

feedback from the process and from piloting innovative
ideas and technologies
SW-CMM Structure
Common Features

• Commitment to Perform (CO)

– groups all generic practices related to creating policies and securing sponsorship for
process improvement efforts.

• Ability to Perform (AB)

– groups all generic practices related to ensuring that the project and/or organization
has the resources it needs to pursue process improvement.

• Directing Implementation (DI)

– groups the generic practices related to collecting, measuring, and analyzing data
related to processes. The purpose of these activities is to provide insight into the
performance of processes.

• Verifying Implementation (VE)

– groups all generic practices related to verifying that the projects and/or
organization’s activities conform to requirements, processes, and procedures.
Structure of CMM
Key Process Areas (KPAs)

• each maturity level (except 1) is decomposed

into several key process areas that indicate the
areas an organization should focus on to
improve its software process
• a cluster of related activities which collectively
achieve a set of important goals
• when the goals are accomplished on a
continuing basis, the KPA is said to be
institutionalized
Key Process Areas (cont’d)

• KPAs are enhanced in succeeding levels

• to achieve a maturity level, the KPAs for that
level must be satisfied
• there are other processes deemed to be not
key to achieving a maturity level; they are not
addressed by the model
Key Process Areas (KPAs)
SW-CMM Maturity Levels
The Initial Process (no KPA)

• Risk of Total Chaos

• No management mechanism in place to plan and
track the work of individuals
• If procedures are established they are
abandoned during a crisis
• PM = “Panic Management” (make the biggest fire smaller)
• tends to be continuous
• capability of org = characteristic of individuals
To Improve to Repeatable Process

• Understand the difference between speed and progress

• Basic project control:

• Project management
• project size estimation

• Management oversight
• quarterly review of process

• Quality assurance
• establish a QA organization ( 5-6 % of development org)

• Change control
The Repeatable Process

• Provides control over the way the organization

establishes its plan and commitments
• basic software management controls exist for tracking
cost, schedule and functionality
• Experienced at doing similar work
• realistic project commitments based upon previous
results
Repeatable (level 2) KPAs

• Software configuration management

• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management

• major risks to the organization at this level:

• introduction of new tools will affect process
• entering new territory, by trying new products
• can be developing new types of products
• major organizational changes can be disruptive
Getting to the Defined Process

• Establish a process group

•  1-3 % of development org

• Establish a development process architecture

• describes the technical and management activities for proper
execution of the development process

• Introduce a family of software engineering methods and

technologies
• design and code inspection
• formal/semi-formal design methods
• library control systems
• comprehensive testing methods
The Defined Process

• Processes for development and maintenance of software is

standardized across the corporation
• software engineering is integrated into the larger engineering
management processes

• The “Acid-test”
• When faced with a crisis they will continue to use the process that has
been defined (might happen at level 2 as well)
• But only qualitative
• Little data to support the effectiveness of the process
• need to move to a quantitative process
Defined (level 3) KPAs

• Organization Software process definition

• Organization Software process focus
• Training program
• Integrated software management
• Peer reviews (including inspections)
• Intergroup coordination
• Software product engineering
Managed (level 4) KPA

• Quality management

• Quantitative process management

 To Improve to the Optimizing Process

• Causal analysis
– eliminate the causes of defects

• Orderly transition of new technologies into the

organization

• Use process data to analyze and change the process

– continuous improvement
• of process to improve product quality
• of productivity
• of time needed to develop
The Optimizing Process

• Organizational focus is on continuous process improvement is

supported by quantitative trend analysis as to process strengths
and weaknesses

• Process innovations and new technologies are introduced when

supported by cost benefit analysis

• Data is available to tune the process itself

• Ability to put the resources where it counts

Optimizing KPA

• Process change management

• Technology change management

• Defect prevention
CMM vs XP
CMM representations

• two representations
– provide alternative approaches to process
improvement for familiarity with either approach

• represent two different philosophical

approaches to process improvement
CMM Representations (cont’d)

• Representation 1. focus on the organization as a whole and

provide a road map of successive stages aimed at
improving the organization’s ability to understand and
control its process
–staged view (comparable to SW-CMM)

• Representation 2. focus on individual processes, allowing

the organization to choose which process or set of
processes need to have more capability
–continuous view (comparable to systems engineering and IPD
models)
Representations (cont’d)

• each representation is a 600 page document

• equivalent staging
– sometimes desirable to convert an organization’s
capability level achievements into a maturity level

• can’t translate from maturity level back

capability level
Continuous Representation

• groups process areas into

– process management
– project management
– engineering
– support

• for each group, assigns a rating from 0 to 5,

according to an organization’s performance on
process areas in that group
Staged Representation

• groups process areas by maturity level

• allows an overall assessment leading to an

assessment of the maturity level observed in
an organization
Some Differences between Representations

• Continuous • Staged
• process areas organized by • process areas organized by
process area categories maturity levels

• six capability levels (0-5) per • five maturity levels (1-5)

category
• improvement is measured using • improvement is measured using
capability levels that reflect maturity levels that reflect the
incremental implementation of a concurrent implementation of
particular process area multiple process areas
• additional appendix describing • no equivalence concept to go from
equivalent staging; allows maturity level to a target profile
translation of a target profile into
a maturity level
Issues with the CMM

• key process areas (KPAs) focus mostly on activities

and supporting artifacts associated with a
conventional waterfall process
–requirements specifications, documented plans, quality
assurance audits and inspections, and documented
processes and procedures
• very few of the KPAs address the evolving results
(i.e., the software product) and associated
engineering artifacts (use case models, design
models, source code, or executable code)
Issues (cont’d)

• no emphasis on the architecting/design process,

assessment process, or deployment process
–which have proven to be key discriminators for project
success
• also overemphasizes peer reviews, inspections and
traditional Quality Assurance “policing” methods
–although manual reviews and inspections may be
capable of uncovering 60% of errors, they rarely
uncover the architecturally significant flaws…
Issues (cont’d)

• most implementations of CMM drive organizations

to produce more documents, more checkpoints,
more artifacts, more traceability, more reviews, and
more plans

– thicker documents, more detailed information, and

longer meetings are considered better

– however, agile methods may be able to be mapped on to

CMM … stay tuned!
State of the Industry Carnagie Melon Software Enginieering Institute
Sofware CMM - CBA, IPI, SPA and SCAMPI Appraisal
Results
Short-comings and Future of CMM

• Surprise, surprise - CMM is not a silver bullet

– a mature process is no guarantee of a quality product

• Not well suited for smaller companies / projects

– Personal Software Process (PSP) is one attempt to address this need

• Crude and harsh 5-point scale

– if you fail just one of the KPAs, you fail the level

• CMMs now exist for software, people, software acquisition, systems engineering
and integrated product development
– latest initiative: CMM Integration (CMMI)
Evolution of CMM

• initial Capability Maturity Model was developed specifically

to address software process maturity

• it was successfully adopted and used in many domains

• other CMMs were developed for other disciplines and

functions

• CMMs now exist for software, people, software acquisition,

systems engineering, and integrated product development
Not Just Software CMM
Decoding abbreviations

• SCE: Software Capability Evaluation

• SCDE: Software Development Capability Evaluation
• SA-CMM: Software Acquisition
• P-CMM: People
• SE-CMM: Systems Engineering
• SSE-CMM: Systems Security Engineering
• IPD-CMM: Integrated Product Development
• CMMI: CMM Integration
References
• Paulk, Mark C.; Weber, Charles V; Curtis, Bill; Chrissis, Mary Beth (1995).
The Capability Maturity Model: Guidelines for Improving the Software Proc
ess
. Boston: Addison Wesley

• Nolan, Richard (July 1973).

"Managing the computer resource: a stage hypothesis". Communications
of the ACM (Association for Computing Machinery)

• Humphrey, Watts (March 1988).

"Characterizing the software process: a maturity framework“.(IEEE
Software achinery)