2. Introduction
Definition
It is a reference model for inducting the software process maturity Into different
levels.
It can be used to predict the most likely outcome to be expected from the next
project that the organization undertakes.
Actually the capability of organizations associated with software development is
evaluated by this model.
That’s why model is called
Software Engineering Institute
Capability maturity model
3. Background
•First proposed by Software Engineering Institute , Carnegie Mellon
University , USA.
•Patterned after the pioneering work of Philip Crosby published in the book
Quality is Free , the
maturity grid for five evolutionary stages for adopting quality practices in an
organization.
Now a days it is called
Capability maturity model integration
4. SEI CMM : Two Ways Of Use
CMM
Capability
Evaluation
Capability
Evaluation
Software Process
Assessment
Software Process
Assessment
5. Capability Assessment
•This is a way to assess the software process capability of an organization.
•The results of Capability Assessment indicate the likely contractor performance
If it is awarded a project .
So the results of Capability Assessment can be used to
Select a contractor for completing a project
6. Software Process Assessment
•Software Process Assessment is the assessment of any organization’s software
process capability.
• It is used by the organization with the objective to improve its process capability
Hence , Software Process Assessment
Is for purely internal use of the organization.
7. The need for software processes prior to CMM
Organizations began to adopt computerized information systems, and the
demand for software development grew significantly.
The processes for software development were in their infancy, with few
standard or "best practice" approaches defined.
As a result, the growth was accompanied by growing pains: project failure was
common and the ambitions for project scale and complexity exceeded the
market capability to deliver.
8. Individuals such as Edward Yourdon, Larry Constantine, Gerald Weinberg,
Tom DeMarco, and David Parnas began to publish articles and books with research
results in an attempt to professionalize the software development process.
In the 1980s, several US military projects involving software subcontractors ran
over-budget and were completed much later than planned, if they were completed
at all.
In an effort to determine why this was occurring, the United States Air Force
funded a study at the SEI.
9. Precursor to CMM
The Quality Management Maturity Grid was developed by Philip Crosby in
his book "Quality Is Free“.
Note that the first application of a staged maturity model to IT was not by
CMM/SEI, but rather by Richard L. Nolan, who, in 1973 published the
Stages of growth model for IT organizations.
Watts Humphrey began developing his process maturity concepts during
the later stages of his 27 year career at IBM.
10. Watts Humphrey's Capability Maturity Model (CMM) was published in 1988 and as a
book in 1989, in Managing the Software Process.
Organizations were originally assessed using a process maturity questionnaire and
a Software Capability Evaluation method devised by Humphrey and his colleagues
at the Software Engineering Institute (SEI).
The full representation of the CMM as a collection of defined process areas and
practices at each of the five maturity levels was initiated in 1991, with Version 1.1
being completed in January 1993. The CMM was published as a book in 1995 by its
primary authors, Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth
Chrissis.
11. Maturity model
A maturity model can be viewed as a set of structured levels that describe how
well the behaviors, practices and processes of an organization can reliably and
sustainably produce required outcomes.
A maturity model may provide, for example :
a place to start
the benefit of a community’s prior experiences
a common language and a shared vision
a framework for prioritizing actions.
a way to define what improvement means for your organization.
A maturity model can be used as a benchmark for comparison and as an aid to
understanding - for example, for comparative assessment of different organizations where
there is something in common that can be used as a basis for comparison. In the case of the
CMM, for example, the basis for comparison would be the organizations' software development
processes.
12. Capability Maturity Model structure
Maturity Levels: a 5-Level process maturity continuum - where the uppermost
(5th) level is a notional ideal state where processes would be systematically
managed by a combination of process optimization and continuous process
improvement.
Key Process Areas: a Key Process Area (KPA) identifies a cluster of related
activities that, when performed collectively, achieve a set of goals considered
important.
Goals: the goals of a key process area summarize the states that must exist for
that key process area to have been implemented in an effective and lasting way.
The extent to which the goals have been accomplished is an indicator of how much
capability the organization has established at that maturity level. The goals signify
the scope, boundaries, and intent of each key process area.
13. Common Features: common features include practices that implement and
institutionalize a key process area. There are five types of common features:
commitment to Perform, Ability to Perform, Activities Performed, Measurement
and Analysis, and Verifying Implementation.
Key Practices: The key practices describe the elements of infrastructure and
practice that contribute most effectively to the implementation and
institutionalization of the KPAs.
14. The Maturity Levels
SEI CMM classifies software development organizations into FIVE Maturity Levels.
•LEVEL 1 : Initial
•LEVEL2 : Repeatable
•LEVEL 3 : Defined
•LEVEL 4 : Managed
• LEVEL 5 : Optimizing
15. CMM Model
Performed
Process
Performed
Process
Level 2 Managed
Process
Managed
Process
Level 3 Defined
Process
Defined
Process
Level 4 Quantitatively
Managed
Process
Quantitatively
Managed
Process
Level 5 Optimizing
Process
Optimizing
Process
Capability
Level 1
16. Level 1 : Initial
• The organization is characterized by ad hoc activities.
• Either very few or no process is defined in this level.
• Engineers follow their own processes for development.
• The development becomes chaotic , sometimes the level is called CHAOTIC level.
• The success of project depends on own efforts .
• As soon as the development team leaves the successors fall into great difficulty
to understand the process that has been followed.
• As a result the developed product is of low quality .
17. Level 2 : Repeatable
• Basic project management practices like tracking cost and schedule are established.
• Size and Cost estimation techniques like Function Point Analysis and COCOMO are
used.
• The necessary process disciplines are in place to repeat the earlier successes on
projects with similar applications .
• We have to remind that repeat of process only exists when the organization has
developed a group of products.
18. Level 3 : Defined
• Here the processes for both the management and development activities are
defined and documented.
• There is a common organization wide understanding of activities , roles and
responsibilities.
• Although the processes are defined the process and product quality are not
measured.
• ISO 9000 aims at achieving this level.
19. Level 4 : Managed
•Primary focus concentrated on software metrics , the metrics are Product
metrics and Process metrics.
•Product metrics deals with size, reliability , time complexity , understandability of
the product deals with product quality .
• Process metrics deals with effectiveness of the process that is being used such
as average number of defects found per hour of inspection , average number of
failures detected during testing per LOC.
• Various tools are used – Pareto Charts , Fishbone Diagram.
•Result of process measurements is used to evaluate the project rather to improve
the process .
20. Level 5 : Optimizing
• Process and Product metrics are collected first.
• Process and Product measurement data are analyzed to improve the process
that is being followed.
• Continuous Process Improvement is achieved through following steps
-Analyzing the quantitative feedback from process measurements
-Invoking innovative methods and technologies.
22. Key Process Areas
CMM LEVEL FOCUS KPA
Initial Competent people
Repeatable Project management Software project planning
Software configuration management
Defined Definition of process Process definition
Training program
Managed Product and process
quality
Quantitative process management
Software quality management
Optimizing Continuous process
improvement
Defect prevention
Process change management
Technology change management
23. Software process framework for SEI's
Capability Maturity Model
TYPESD DESCRIPTION
Policy
Describes the policy contents and KPA
goals recommended by the CMM.
Standard
Describes the recommended content of
select work products described in the
CMM.
24. Process
•Describes the process information
content recommended by the CMM. The
process checklists are further refined
into checklists for: roles
•entry criteria
•inputs
•activities
•outputs
•exit criteria
•reviews and audits
•work products managed and controlled
•measurements
•documented procedures
•training
•tools
25. Level overview
•Provides an overview of an entire
maturity level. The level overview
checklists are further refined into
checklists for: KPA purposes (Key Process
Areas)
•KPA Goals
•policies
•standards
•process descriptions
•procedures
•training
•tools
•reviews and audits
•work products managed and controlled
•measurements
Procedure
Describes the recommended content of
documented procedures described in the
CMM.
26. Don’t Mix Up with ISO 9000
ISO 9000 is an external document, where as CMM is purely internal document.
CMM only for software industry.
CMM shows a way for achiving gradual quality improvement
