1. Chapter 3 The Structure of the CMM
The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability.
The CMM is fairly abstract so that it will not unduly constrain how the software process is implemented by an organization.

2. The Operational Elaboration of the CMM
Assessment teams will use the CMM to identify strengths and weaknesses in the organization.
Evaluation teams will use CMM to identify the risks of selecting among different contractors for awarding business and to monitor contracts.
Appraisal method developers will use the CMM to develop other CMM-based appraisal methods that meet specific needs (e.g. the interim profile method – IPM)
Upper management will use the CMM to understand the activities necessary to launch a software process improvement program in their organization.
Technical staff and process improvement groups, such as SEPG, will use CMM as a guide to help them define and improve the software process in their organization.

3. Internal Structure of the Maturity Levels
Each maturity level is composed of several key process areas (KPA).
Each key process area is organized into five sections called common features.
The common feature contain the key practices that, when collectively addressed, accomplish the goals of the key process area.

4. The CMM Structure 5 4 3 2 RM PP PT SM QA CM Maturity Levels
Key Process Areas (18) RM PP PT SM QA CM
Goals (52)
Common Features
Activities Performed
Commitment to Perform
Ability to Perform
Measurement and Analysis
Verifying Implementation
Key
Practices
(300)

5. institutionalization
Maturity levels
Indicate
Contain
Process
capability
Key process areas
Achieve
Organized by
Goals
Common
features
Address
Contain
Implementation or
institutionalization
Key
Practices
Describe
Activities or
infrastructure

6. Key Process Area (KPA)
A key process area describes a fully implemented and institutionalized process.
Each KPA identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability.
The CMM does not describe all the process area that are involved with developing and maintaining software. Only those process areas identified as key determinants of process capability in CMM.
The goals of each key process area summarize its key practices and can be used in determining whether an organization or product has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.

7. Key Actions in 1987

8. Key Challenges in 1988

9. Chapters in 1989

10. CMM v0.2 in 1990

11. CMM v0.6 in 1990

12. CMM v1.0 in 1991

13. CMM v1.1 in 1993

14. Management Organizational Engineering 5 Optimizing 4 Managed 3 Defined
Levels/
Process Categories
Management
Organizational
Engineering
5 Optimizing
Technology Change Management
Process Change Management
Defect Prevention
4 Managed
Software Quality Management
Quantitative Software Management
Organization Process Focus
Organization Process Definition
Training Program
3 Defined
Integrated Software Management
Intergroup Coordination
Software Product Engineering
Peer Reviews
2 Repeatable
Requirements Management
Software Project Planning
Software Project Tracking and Oversight
Software Subcontract Management
Software Quality Assurance
Software Configuration Management
1 Initial
Ad Hoc Processes

15. Level 1: Just do it. Activity Results
to produce
Activity
Results
Level 2: Think before you act, and think after you act, just to make sure you did it right.
Planning
to produce
Activity
Results
input to
Evaluation
to improve

16. Use your lessons learned.
Level 3
Planning
input to
to produce
Activity
Standards
Results
input to
input to
Evaluation
to improve
Use your lessons learned.

17. Level 4 Planning Activity Standards Results Evaluation
input to
to forecast
to produce
Activity
Standards
Results
input to
input to
Evaluation
to improve
Predict the results you need and expect and then create opportunities to get those results

18. Level 5 Planning Activity Standards Results Evaluation
input to
to forecast
to produce
Activity
Standards
Results
input to
input to
Evaluation
to improve
to improve
Create lessons learned, and use lessons learned to create more lessons learned, and use more lessons learned to create even more lessons learned, and use even more lessons learned to create etc.

19. Key Process Areas at Level 2
Requirements
management
The purpose of SRM is o establish a common understanding between the customer and the software project of the customer’s requirements to be addressed by the software project.
Software project
planning
The purpose of SPP is to establish reasonable plans for performing the software engineering and for managing the software project.
Software project tracking & oversight
The purpose of SPTO is to establish adequate visibility into actual progress so that management can take effective actions when the software project’s performance deviates significantly from the software plans.
Software subcontract management
The purpose of SSM is to select qualified software subcontractors and manage them effectively.
Software quality assurance
The purpose of SQA is to provide management with appropriate visibility into the process being used by the software project and of the products being built.
Software configuration
The purpose of SCM is to establish and maintain the integrity of the products of the software project throughout the project’s software life cycle.

20. Key Process Areas at Level 3
Organization process
focus
The purpose of OPF is to establish the organizational responsibility for software activities that improve the organization’s overall software process capability.
definition
The purpose of OPD is to develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for defining meaningful data for quantitative PM.
Training program
The purpose of TP is to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently.
Integrated software management
The purpose of ISM is to integrate the software engineering and management activities into a coherent, defined software process that is tailored from the org’s standard SP and related process assets.
Software product engineering
The purpose of SPE is to perform consistently a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently.
Intergroup coordination
The purpose of IC is to establish a means for the software engineering group to participate actively with the other engineering groups so the project is able to satisfy the customer’s needs effectively and efficiently.
Peer reviews
The purpose of PR is to remove defects from the software work products early and efficiently.

21. Key Process Areas at Level 4
Quantitative
Process
Management
The purpose of QPM is to control the process performance of the software product quantitatively.
Software
Quality
The purpose of SQM is to develop a quantitative understanding of the quality of the project’s software products and achieve specific quality goals.

22. Key Process Areas at Level 5
Defect prevention
The purpose of DP is to identify the causes of defects and prevent them from recurring.
Technology change
management
The purpose of TCM is to identify beneficial new technology (e.g. tools, methods, and processes) and transfer them into organization in an orderly manner.
Process change
The purpose of PCM is to improve continually the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle
Time for product development.

23. Key Practices
Each key process area is described in terms of key practices.
The key practices describe the activities and infrastructure that contribute most to the effective implementation and institutionalization of the key process area.
Each key practice consists of a single sentence, often followed by a more detail description, which may include examples and elaboration.

24. “What” Versus “How to” The CMM is intended to be
descriptive of software engineering and management practices
prescriptive for process improvement priorities
Key Process Area describe “what” not “how”
Ignorance of “how” to implement processes can lead to “ticking off” CMM key practices.
The key practices describe “what” is to be done, but they should not be interpreted as mandating “how” the process should be implemented.

25. Common Features: Factors in Implementation and Institutionalization
Commitment to Perform: Institutionalization Are the activities supported by the organization through documented policies, processes, or procedures?
Ability to Perform: Institutionalization Are the activities supported by adequate training and resources?
Activities Performed: Implementation Are effective activities performed to satisfy the goals?
Measurement and Analysis: Institutionalization Are measurements used to determine the status of activities, and can those measurements be used to analyze the process for improvement?
Verifying Implementation: Institutionalization Are there processes or mechanisms for verifying that the activities are being performed?

26. Common Features Commitment To Perform Ability to Perform Activity to
(1)It describes the actions the organization must take to ensure that the
process is established and will ensure. (2) It typically involves establishing
organizational policies and leadership.
Ability to
Perform
(1)It describes the preconditions that must exist in the project or organization to implement the software process competently. (2) It typically involves resources, organizational structures, and training.
Activity to
(1)It describes the activities, roles, and procedures necessary to implement a key process area. (2)It typically involves establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.
Measurement
And Analysis
(1)It describes the basic measurement practices that are necessary to determine status related to the process. These measurements are used to control and improve the process. (2)It typically includes examples.
Verifying
Implementa-tion
(1)It describes the steps to ensure that the activities are performed in compliance with the process that has been established. (2)It typically encompasses reviews and audits by management and SQA.

27. Key Points The CMM is a Framework of Software Process Improvement
The CMM provides a framework for organizing these
evolutionary steps into five maturity levels that lay successive
foundations for continuous process improvement.
(1) Initial (2) Repeatable (3) Defined (4) Managed (5) Optimizing
Except for Level 1, each maturity level is decomposed into
several key process areas that indicate where an organization
should focus to improve its software process.
Each key process area is described in terms of key practices.
The key practices describe “what” is to be done, but they
should not be interpreted as mandating “how” the process
should be implemented.

28. Acknowledgement
Part of contents in the presentation comes from the following references:
> SEI Mark’s presentations on CMM
> CMM Implementation Guide, by Kim Caputo,
Addison-Wesley, 1998