Capability Maturity

Model
What is CMM

 CMM: Capability Maturity Model

 CMM was developed and is promoted by
the Software Engineering Institute (SEI), a research
and development center sponsored by the U.S.
Department of Defense (D o D)since 1987.
 A procedure which is used to analyze and refine
the development process of an organization’s
software.
What is CMM

 It provides guidelines to
further enhance the maturity of software development
process.
 This also describes an
evolutionary strategy for software process improvement
that should be followed by moving through 5 different
levels.
Why to use CMM

CMM

Capability Software Process

Evaluation Assessment
Why to use CMM

 Capability Evaluation
 A capability level is a well-defined evolutionary
process describing the organization's capability
relative to a process area.
 Therefore, the results of the software process
capability assessment can be used to select a
contractor.
Why to use CMM

 Software Process Assessment

 Software process assessment is used by an
organization to improve its process capability.
 This type of evaluation is for purely internal use.
CMM Levels:
(The five levels of software process
maturity)

 Different levels of SEI CMM have been designed so that it

is easy for an organization to slowly build its quality system
starting from scratch.
Levels :
 Initial
 Repeatable
 Defined
 Managed
 Optimizing
Higher the level, mature the process is .
Level 1: Initial

 Very few or no processes are described and

followed.
 Success depends on individual effort.
 Capability is a characteristic of the
individuals, not of the organization.
 Products developed are often over budget
and schedule
 Wide variations in cost, schedule, functionality
and quality targets.
Level 2: Repeatable

 At this level, the basic project management practices

such as tracking cost and schedule are established.
 Size and cost estimation techniques like function point
analysis, COCOMO, etc. are used.
 Experience with earlier projects is used for managing new
similar natured projects.

 Opportunity to repeat a process exists only when a

company produces a family of products.
Level 3: Defined

 The software process for both management and

development activities is defined and documented.
 All projects use an approved, tailored version of the
organization’s activities, roles and responsibilities.

 The processes though defined, the process and

product qualities are not measured.
 Level 4: Managed

 the focus is on software metrics (standards).

 Product metrics
 characteristics of the product being developed, such
as its size, reliability, time complexity, understandability,
etc.
 Process metrics
 effectiveness
of the process being used, such as
average defect correction time, productivity,
average number of defects found per hour inspection
etc.
 quantitative quality goals are set for the organization for
software products as well as software processes.
 Level 5: Optimizing

 This is the highest level of process maturity in

CMM. The key characteristic of this level is
focusing on continuous process improvement
in the organization using quantitative
feedback.
 Process change Management
 Technology Change Management
 Defect Prevention
 KEY PROCESS AREAS (KPAs)

 Except for level 1, each level is decomposed into key

process areas.
 Each maturity level is featured by several Key Process Areas
that contains the areas an organization should focus on
improving its software process to the next level.
 CMM Level Focus Key Process Areas
1. Initial Competent people No KPAs
2. Repeatable Project management Software project
Planning
Software configuration
management
3. Defined Definition of processes Process definition
Training program
Peer reviews
4. Managed Product and process quality Quantitative process
metrics
Software quality
management
5. Optimizing Continuous process Defect prevention
improvement Process change
management
Technology change
management
Benefits of CMM

 SEI CMM provides a list of key process areas (KPAs) on

which an organization at any maturity level needs to
concentrate to take it from one maturity level to the
next.
 Defines set of priorities for addressing software problems.
 Provides framework for consistency of processes and
product.
Applicability of CMM

 For large organizations

 Highly systematic and measured approach to software
development.
 suits large organizations dealing with negotiated
software, safety-critical software, etc.
 For small organizations
 small organizations typically handle small applications
like internet and e-commerce and don’t have
established product range.
 These organizations need to operate more efficiently at
the lower levels of maturity.
Personal Software Process
(PSP)

 Scaled down version of the industrial software

process.
 Suitable for individual use.
 The process for individual use is different from that
for a team.
 SEI CMM does not tell software developers how to
analyze, design, code, test, or document software
products.
 but assumes that engineers use effective personal
practices.
 PSP is a framework that helps engineers to measure
and improve the way they work.
PSP Time Measurement

 engineers should track the way they spend time.

 the actual time spent on a task should be measured
with the help of a stop-clock to get an objective
picture of the time spent.
 Because, boring activities seem longer than actual and
interesting activities seem short.
PSP Planning

 Engineers must estimate the maximum, minimum,

and the average LOC (lines of code) required for
the product.
 They must record the plan data in a project plan
summary.
Measurements

 Historical
 Plan
 Actual
 Projections
Examples of measurements for
size of work products

 Estimated number of requirements

 Actual number of requirements
 Estimated source lines of code (SLOC)
 Actual SLOC
 Estimated number of test cases
 Actual number of test cases
Example of measurements of
effort

 Estimated man-hours to design/code a given

module
 Actual man-hours expended for designing/coding
the module
 Estimated number of hours to run builds for a given
release
 Actual number of hours spent running builds for the
release
Consistent measurement
provide data for:

 Quantitatively expressing requirements, goals, and

acceptance criteria
 Monitoring progress and anticipating problems
 Predicting schedule, cost and quality