cmm for it sectors

8/11/2019 CMM for IT Sectors

1/24

TOTAL QUALITY MANAGEMENT

(TQM)

CAPABILITY MATURITY MODEL

(CMM)

Devram Mahulkar

PGDM (Operations)


2/24

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 onpracticing that play many times.

Sometimes they fail to make the right play, but theyalmost always try to do the right thing.


3/24

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 dontknow 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,letsdo this instead."

SW development and baseball


4/24


5/24

Background

Begun in 1986 by US DoD to help improve governmentsoftware contractors.

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

Watts Humphrey was initial author, then Mark Paulk, BillCurtis, 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


6/24

What is CMM?

In the same way, high-quality SW organizations are differentfrom low-quality orgs.

CMM tries to capture and describe these differences.

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

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


7/24

What is CMM?

Provides guidance on how to gain control of processes fordeveloping and maintaining software and how to evolvetoward a culture of software engineering and managementexcellence.

Describes five levels of SW process maturity.


8/24

Process Maturity Concepts

Software Process

set of activities, methods, practices, and transformations

that people use to develop and maintain software and theassociated products (e.g., project plans, designdocuments, code, test cases, user manuals)

Software Process Capability

describes the range of expected results that can beachieved by following a software process

means of predicting the most likely outcomes to beexpected from the next software project the organizationundertakes


9/24

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


10/24

What are the CMM Levels?


11/24

Level 1: Initial

The software process is characterized as ad hoc, andoccasionally even chaotic. Few processes are defined, andsuccess depends on individual effort.

At this level, frequently have difficulty makingcommitments that the staff can meet with an orderlyprocess

Products developed are often over budget and schedule

Wide variations in cost, schedule, functionality and qualitytargets

Capability is a characteristic of the individuals, not of theorganization


12/24

Level 2: Repeatable

Basic process management processes are established to trackcost, schedule, and functionality. The necessary processdiscipline is in place to repeat earlier successes on projects withsimilar applications.

Realistic project commitments based on results observedon previous projects

Software project standards are defined and faithfullyfollowed

Processes may differ between projects

Process is disciplined

earlier successes can be repeated


13/24

Level 3: Defined

The software process for both management and engineeringactivities is documented, standardized, and integrated into astandard software process for the organization.

All projects use an approved, tailored version of theorganizations standard software process for developing anmaintaining software.


14/24

Level 4: Managed

Detailed measures of the software process and product qualityare collected. Both the software process and products arequantitatively understood and controlled.

Narrowing the variation in process performance to fallwithin acceptable quantitative bounds

When known limits are exceeded, corrective action can betaken

Quantifiable and predictable

predict trends in process and product quality


15/24

Level 5: Optimizing

Continuous process improvement is enabled by quantitativefeedback from the process and from piloting innovative ideasand 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


16/24

Internal Structure to Maturity Levels

Except for level 1, each level is decomposed into keyprocess areas (KPA)

Each KPA identifies a cluster of related activities that, whenperformed collectively, achieve a set of goals consideredimportant for enhancing software capability.

commitment

ability activity

measurement

verification


17/24

The KPA by maturity level


18/24

What are the benefits ?

Helps forge a shared vision of what software processimprovement means for the organization

Defines set of priorities for addressing software problems

Supports measurement of process by providing framework forperforming reliable and consistent appraisals

Provides framework for consistency of processes and product


19/24

Why measure software and software process?

Obtain data that helps us to better control

Schedule

Cost quality of software products

Quantitatively expressing requirements, goals, andacceptance criteria

Monitoring progress and anticipating problems

Quantifying tradeoffs used in allocating resources

Predicting schedule, cost and quality


20/24

SEI Core Measures

Unit of Measure Characteristics Addressed

Physical source lines of codeLogical source lines of code

Size, reuse, rework

Staff hours Effort, cost, resource allocationsCalendar dates for processmilestonesCalendar dates for deliverables

Schedule, progress

Problems and defects Quality, improvement trends,rework, readiness for delivery


21/24

Examples of measurements for size of workproducts

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


22/24

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


23/24

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 thework product


24/24

THANK YOU

QUESTIONS ?

cmm for it sectors

Documents