Maturity Levels and Key Process Areas


To frame our discussion, consider:

What is the role of KPAs in the CMM?

How do the KPAs distribute over CMM levels?

What appears to be the major stumbling block(s) to CMM adoption by industry?


OUTLINE


Material in this lecture was taken from SEI (1993) The Capability Maturity Model: A Tutorial.

Key Process Areas

Identify a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability

Defined to reside at a single maturity level

Identify the issues that must be addressed to achieve a maturity level

Repeatable (2)

Defined (3)

Managed (4)

Optimizing (5)

Project Responsibilities

The project will have primary responsibility for acting on:

Organizational Responsibilities

The organization will have primary responsibility for acting on:

Understanding the Initial Maturity Level

Performance driven by the competence and heroics of the people doing the work

Consistency and compliance to standards driven by management priorities - usually schedule is the top priority

High quality and exceptional performance possible so long as the best people can be hired Unpredictability Ð for good or ill Ð characterizes the initial level organization

Understanding the Repeatable Maturity Level

Management must "walk the talk" to initiate an improvement effort.

Only with management discipline will good software engineering practices be retained in the crunch.

Management processes establish role models for process improvement.

Management Ð and process Ð discipline empowers the engineering processes and the technical staff.

KPA - Requirements Management (RM)

Purpose is to establish a common understanding between the customer and the software project of the customer's requirements that will be addressed by the software project

Involves establishing and maintaining an agreement with the customer on the requirements for the software project

Agreement is the basis for estimating, planning, performing, and tracking the project's software activities

KPA - Software Project Planning (PP, SPP)

Purpose is to establish reasonable plans for performing the software engineering and for managing the software project

Involves:

Plan provides the basis for initiating the software effort and managing the work

KPA - Software Project Tracking and Oversight (PT, PTO)

Purpose is to provide adequate visibility into actual progress so that management can take effective actions when performance deviates significantly from the plan

Involves:

KPA - Software Subcontract Management (SM)

Purpose is to select qualified software subcontractors and manage them effectively

Involves:

KPA - Software Quality Assurance (QA, SQA)

Purpose is to provide management with appropriate visibility into the process being used and the products being built

Involves:

KPA - Software Configuration Management (CM, SCM)

Purpose is to establish and maintain the integrity of the products of the software project throughout the software life cycle

Involves:

Understanding the Defined Maturity Level

To control a process, it must be well understood.

Identify the inputs, how they will affect the process, and their readiness criteria.

Identify the outputs and the completion criteria for the outputs.

Establish a shared understanding of how the process works and the role of each participant.

KPA - Organization Process Focus (PF, OPF)

Purpose is to establish the organizational responsibility for software process activities that improve the organization's overall software process capability

Involves:

KPA - Organization Process Definition (PD, OPD)

Purpose is to develop and maintain a usable set of software process assets that improve process performance and provide a basis for cumulative, long-term benefits

Involves developing and maintaining the organization's standard software process and related process assets

KPA - Training Program (TP)

Purpose is to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently

Involves:

KPA - Integrated Software Management (IM, ISM)

Purpose is to integrate the project's software engineering and management activities into a coherent, defined software process tailored from the organization's software process assets

Involves:

KPA - Software Product Engineering (PE, SPE)

Purpose is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently

Involves performing the engineering tasks to build and maintain the software using appropriate tools and methods

KPA - Intergroup Coordination (IC)

Purpose is to establish a means for the software engineering group to participate actively with the other engineering groups so the project is better able to satisfy the customer's needs effectively and efficiently

Involves the disciplined interaction and coordination of the project engineering groups with each other to address system-level requirements, objectives, and plans

KPA - Peer Reviews (PR)

Purpose is to remove defects from the software work products early and efficiently

Important corollary is to develop a better understanding of the software work products and of defects that might be prevented

Involve a methodical examination of work products by the producer's peers to identify defects and areas where changes are needed

Understanding the Managed Maturity Level

Applying the principles of statistical process control, address special causes of process variation.

Explicitly address the customer's needs as part of a philosophy of quality management.

KPA - Quantitative Process Management (QP, QPM)

Purpose is to control the process performance of the software project quantitatively

Involves:

KPA - Software Quality Management (QM, SQM)

Purpose is to develop a quantitative understanding of the quality of the project's software products and achieve specific quality goals

Involves:

Understanding the Optimizing Maturity Level

Automate, pilot new technologies, do technology transition.

Identify and eliminate chronic causes of poor performance.

Continually improve the software process.

KPA - Defect Prevention (DP)

Purpose is to identify the cause of defects and prevent them from recurring

Involves:

KPA - Technology Change Management (TM, TCM)

Purpose is to identify new technologies (i.e., tools, methods, and processes) and transfer them into the organization in an orderly manner

Involves:

KPA - Process Change Management (PC, PCM)

Purpose is to continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development

Involves:

SEI Data

From Section 3.4 of The Capability Maturity Model For Software, Version 1.1

LevelProject
Maturity
(N=296)
Site
Maturity
(N=27)
188%81%
25%12%
35%7%
40%0%
52%0%
(1991 data)

Impact of Level on Performance

SEI
Level
Quality
Defects /KSLOC
Productivity
SLOC /Hour
Cost
$ Millions
Cost
$/SLOC
Development
Time
19.0+1.0$33 M$6640 Months
23.03.0$15 M$30 32 Months
31.05.0$ 7 M$1425 Months
40.38.0$ 3 M$619 Months
50.112.0$ 1 M$216 Months

SEI
Level

DurationEffortFaults Detected
during Development
Faults DeliveredTotal Cost
129.5593.5134861$5,440,00 0
218.5143.0328121,311,000
315.279.51827728,000
412.542.8975392,000
59.016.0371146,000

(From Schach, p. 74)
(Model for a 200K data processing application)


Go To Lecture [Outline] [Overview]

Go To [311 Course Outline] [CIS Department Page]


References

Paulk, M. C., B. Curtis, M. B. Chrissis, & C. V. Weber (1993) The Capability Maturity Model For Software, Version 1.1. Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-24.

Schach (1996) Classical and Object Oriented Software Engineering.

SEI (1993) The Capability Maturity Model: A Tutorial.