TOTAL QUALITY MANAGEMENT

(TQM)

CAPABILITY MATURITY MODEL
(CMM)



Devram Mahulkar
PGDM (Operations)
SW development and baseball
What happens when a ball is hit to a Little League team?

Everyone runs around at random.
They might do the right thing, or they might not.
The next time the ball is hit in the same place, they may
do something different.

What happens when a ball is hit to a professional team?

Everyone moves in a coordinated fashion, based on
practicing that play many times.
Sometimes they fail to make the right play, but they
almost always try to do the right thing.
What happens when the team loses a star player?

Little League team gets much worse.
Professional team often has someone waiting to fill in.

Self-improvement after a bad play

Little League players dont know what went wrong, or they
blame each other.
Professional teams discuss their play and look for ways to
improve. "The next time there is an infield hit with 2 outs,
lets do this instead."
SW development and baseball
A professional baseball team is more "mature" than a Little
League team (not referring to age).

A professional team has self-perpetuating quality. They

Make good plays
Develop new players like themselves
Find ways to make better plays

SW development and baseball
Background
Begun in 1986 by US DoD to help improve government
software contractors.

Work started at Mitre, then at Software Engineering Institute
(SEI) at Carnegie Mellon Univ.

Watts Humphrey was initial author, then Mark Paulk, Bill
Curtis, and others.

Borrows heavily from general Total Quality Management
(TQM) and work of Philip Crosby.

The CMMI software version 1.0 was published in 1991

What is CMM?
In the same way, high-quality SW organizations are different
from low-quality orgs.

CMM tries to capture and describe these differences.

CMM strives to create software development organizations
that are mature, or more mature than before applying CMM.

Describes an evolutionary improvement path for software
organizations from an ad hoc, immature process to a mature,
disciplined one.


What is CMM?
Provides guidance on how to gain control of processes for
developing and maintaining software and how to evolve
toward a culture of software engineering and management
excellence.

Describes five levels of SW process maturity.

Process Maturity Concepts
Software Process

set of activities, methods, practices, and transformations
that people use to develop and maintain software and the
associated products (e.g., project plans, design
documents, code, test cases, user manuals)

Software Process Capability

describes the range of expected results that can be
achieved by following a software process
means of predicting the most likely outcomes to be
expected from the next software project the organization
undertakes
Process Maturity Concepts
Software Process Performance

actual results achieved by following a software process

Software Process Maturity

extent to which a specific process is explicitly defined,
managed, measured, controlled and effective
implies potential growth in capability
indicates richness of process and consistency with which it
is applied in projects throughout the organization
What are the CMM Levels?
Level 1: Initial
The software process is characterized as ad hoc, and
occasionally even chaotic. Few processes are defined, and
success depends on individual effort.

At this level, frequently have difficulty making
commitments that the staff can meet with an orderly
process
Products developed are often over budget and schedule
Wide variations in cost, schedule, functionality and quality
targets
Capability is a characteristic of the individuals, not of the
organization

Level 2: Repeatable
Basic process management processes are established to track
cost, schedule, and functionality. The necessary process
discipline is in place to repeat earlier successes on projects with
similar applications.

Realistic project commitments based on results observed
on previous projects
Software project standards are defined and faithfully
followed
Processes may differ between projects
Process is disciplined
earlier successes can be repeated

Level 3: Defined
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
organizations standard software process for developing an
maintaining software.

Level 4: Managed
Detailed measures of the software process and product quality
are collected. Both the software process and products are
quantitatively understood and controlled.

Narrowing the variation in process performance to fall
within acceptable quantitative bounds
When known limits are exceeded, corrective action can be
taken
Quantifiable and predictable
predict trends in process and product quality

Level 5: Optimizing
Continuous process improvement is enabled by quantitative
feedback from the process and from piloting innovative ideas
and technologies.

Goal is to prevent the occurrence of defects
Causal analysis

Data on process effectiveness used for cost benefit analysis
of new technologies and proposed process changes

Internal Structure to Maturity Levels
Except for level 1, each level is decomposed into key
process areas (KPA)

Each KPA identifies a cluster of related activities that, when
performed collectively, achieve a set of goals considered
important for enhancing software capability.

commitment
ability
activity
measurement
verification

The KPA by maturity level
What are the benefits ?
Helps forge a shared vision of what software process
improvement means for the organization

Defines set of priorities for addressing software problems

Supports measurement of process by providing framework for
performing reliable and consistent appraisals

Provides framework for consistency of processes and product

Why measure software and software process?
Obtain data that helps us to better control

Schedule
Cost
quality of software products

Quantitatively expressing requirements, goals, and
acceptance criteria
Monitoring progress and anticipating problems
Quantifying tradeoffs used in allocating resources
Predicting schedule, cost and quality


SEI Core Measures
Unit of Measure Characteristics Addressed
Physical source lines of code
Logical source lines of code
Size, reuse, rework
Staff hours Effort, cost, resource allocations
Calendar dates for process
milestones
Calendar dates for deliverables
Schedule, progress
Problems and defects Quality, improvement trends,
rework, readiness for delivery
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

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

Example of measurements of effort
Number of issues raised at requirements inspection
Number of requirements issues open
Number of requirements issues closed
Number of issues raised during code inspection
Number of defects opened during unit testing
Number of defects opened during system testing
Number of defects opened during UAT
Number of defects still open
Number of defects closed
Total number of defects fixed for a given release
Total number of defects verified and accepted
Total number of defects verified and rejected


Examples of measurements of quality of the
work product
THANK YOU
QUESTIONS ?