This document provides an overview of the Capability Maturity Model Integration (CMMI) version 1.2. It discusses the history and development of CMM models. CMMI version 1.2 integrates different CMM models and focuses on systems engineering and software engineering. It describes the staged maturity levels from initial to optimizing, and the key process areas addressed at each level. Finally, it notes that organizations should not skip maturity levels, as each level provides foundations for continuous process improvement.

1. CMMI: Version 1.2
Basics
A presentation by QAI
INDIA | USA | UK © QAI India Limited. All rights|reserved.
| CHINA | MALAYSIA
SINGAPORE

2. CMMI Version 1.2
Basics

3. History of CMMs
• CMM v1.0 (Software) was the first to
be developed
• Others were developed subsequently:
– SE CMM (Systems Engineering) CMM
– Integrated Product Development CMM
– SA (Software Acquisition) CMM
– People CMM
3

4. Why Integrate?
• Adaptability to enterprise needs
– designed for evolution to meet current
and future enterprise-wide process
improvement needs
– can add new process areas, generic
improvement approach still applies
4

5. CMMI - SE/ SW
• Systems Engineering
– Covers the development of total systems,
which may or may not include software
– Focus on transforming customer needs,
expectations, and constraints into
product solutions and supporting those
product solutions throughout the product
life cycle
• Software Engineering
– Covers the development of software
systems
– Focus on applying systematic, disciplined,
and quantifiable approaches to the
development, operation and
maintenance of software
• CMMI - SE/SW covers both
5

6. Why Use CMMI SE/SW?
• Increased dependency between
systems engineering and software
engineering
• Low maturity of the interfaces
between systems engineering and
software engineering
6

7. What’s New in CMMI Ver 1.2
7

8. CMMI® Framework
• Constellation: Collection of CMMI® components that includes the
model, its training materials and appraisal-related documents for an
area of interest. CMMI models for development, services and
acquisition
• Model for development provides amplifications for the systems
engineering, software engineering, and hardware engineering
disciplines
• “Additions” used to expand constellations for specific additional
content - CMMI® Dev has one such addition (CMMI® - Dev + IPPD) (In
V1.1, IPPD was a discipline.)
• Based on the initial efforts to maximize commonality among CMMI
models, 16 of the 22 process areas of CMMI-DEV comprise the
process improvement core for the three areas of interest currently
being pursued: development, acquisition, and services.
8

9. Concept of Constellations
• Latest version of CMMI i.e. CMMI
ver 1.2 for Development was
launched in Aug’06
• Constellation: Collection of CMMI®
components that includes the
model, its training materials and
appraisal-related documents for
an area of interest
• Other constellations in making
– Acquisition
– Services
9

10. Concept of Maturity
• Software Process Maturity
– Extent to which a specific process is explicitly defined, managed, measured,
controlled and effective
– Implies a potential growth in capability and indicates both the richness of an
organization’s software process and the consistency with which it is applied in
projects throughout the organization
• Maturity Level
– A well defined evolutionary plateau toward achieving a mature software process
– Each level provides a layer in the foundation for continuous process improvement
10

11. Staged Approach
• Proven sequence of typical areas to
focus on for improvement
• Permits comparison across
organizations - assessment results can
be summarized into a single rating
• Easy migration from SW-CMM SM
11

12. The Five Levels of Process
Maturity
Continuous Improvement
Optimizing Institutionalize
Process
Improvement (5) d
Quantitatively Process measured
Quantitative Managed and controlled
Management
(4)
Process characterized
Process Defined for the organization
Standardization (3) and is proactive
Managed Process characterized for
Basic Project projects and is often
Management (2) reactive
Process unpredictable,
Initial poorly controlled and
(1) reactive
© Software Engineering Institute
12

13. Level 1 Process Areas
There are no Process Areas at Level 1
13

14. The Initial Level (1)
• Environment not stable for developing and
maintaining systems
• Inadequate management and engineering
practices
• Ineffective planning
• Reaction-driven commitment systems
• Emphasis on development and testing during crisis
• Success depends on having exceptional people
• Unpredictable process capability
• Unpredictable schedules, budgets, functionality,
and quality
• Few stable processes
14

15. Level 2 Process Areas
• Focus is on enabling institutionalizing Project Management
Practices
Instilling basic
discipline
into project
management Requirements Management
practices. Project Planning
Each project
may follow Project Monitoring and Control
their own Supplier Agreement Management
set of processes. Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
15

16. The Managed Level (2)
• Policies for managing projects
• Planning and managing based on experience
• Allows repeatability of successful practices
• Specific processes implemented by the projects
may differ
• Realistic project commitments
• Costs, schedules and functionality tracked
• Requirements and work products are baselined
• Standards defined and conformed to
• Strong customer-supplier relationship with
subcontractors
• A measurement process is in place
16

17. Level 3 Process Area
• Focus is on developing technical/ engineering practices
integrating it with management practices and institutionalizing
it.
Developing Requirements Development
engineering
practices, integrating Technical Solution
them with management Product Integration
practices and Verification
standardizing Validation
processes across Organizational Process Focus
the organization Organizational Process Definition + IPPD
Organizational Training
Integrated Project Management + IPPD
Risk Management
Decision Analysis and Resolution
17

18. The Defined Level (3)
• Organization-wide standard processes
• Effective engineering practices
• Integration of engineering and management processes
• Reuse of organizational learning
• Process Engineering Group (PEG)
• Organization-wide training program
• Project’s “Defined Process”
• Good management insight into the technical progress on all
projects
18

19. Level 4 Process Area
• Focus is on quantitatively managing project and organization
wide performance
Quantitatively
manage
organizational
processes
Organizational Process Performance
Quantitative Project Management
19

20. The Quantitatively Managed
Level (4)
• Quantitative goals for projects and processes
• Variation in process performance narrowed
• Meaningful variations can be distinguished from random
variation
• Products are of high quality
• Projects are controlled quantitatively
20

21. Level 5 Process Area
• Focus is on continuously improving project and organizational
capability
Continuously
improve project
and
organizational Organizational Innovation and
capability Deployment
through
innovations & Causal Analysis and Resolution
do root cause
analysis for
common causes
21

22. The Optimizing Level (5)
• Organization focused on process improvement
– incremental advances in existing
processes
– innovations using new technologies and
methods
• Proactive identification of weaknesses to strengthen
processes
• Goal of preventing occurrence of defects through error-cause
removal
• Cost-Benefit analyses of introducing new technologies and
proposed process changes
22

23. Skipping Maturity Levels
• Counter-productive
• Each level builds a foundation for
succeeding levels
• Required leverage for implementing
processes effectively and efficiently
• However, processes described at a
higher maturity level can be used
23

24. Continuous Model
• Allows you to select the order of
improvement that best meets your
organization’s business objectives
• Enables comparisons across and
among organizations on a process-
area-by-process-area basis
• Provides an easy migration from
models with a continuous
representation to CMMI
• Uses predefined sets of process
areas to define an improvement
path for an organization
24

25. Structure of PA
No common
features
25

26. http://www.qaiglobal.com
INDIA
USA
UK
CHINA
MALAYSIA
SINGAPORE
Click here for more on Software
Process Improvement
CONTACT
US
QAI India: QAI USA: QAI Malaysia:
1010 - 1012, Ansal Towers, 38 Nehru Windsor at Metro Center, 2101 Park Level 36, Menara Citibank, 165, Jalan
Place Center Dr., Suite 200, Orlando, FL Ampang, 50450 Kuala Lumpur,
New Delhi - 110019, India 32835-7614 Malaysia
Phone: +91- 11- 26219792, 26220580 Phone: +407-363-1111 Phone: +603 2169 6241
conferences@qaiglobal.com conferences@qaiglobal.com conferences@qaiglobal.com
QAI UNICOM / UK: QAI Singapore: QAI China:
Unicom R&D House, One Oxford 391B Orchard Road #23-01, Rm. 1211, No. 498 Guoshoujing Rd.
Road Ngee Ann City Tower B, Shanghai
Uxbridge, Middlesex, London, United Singapore - 238874 Zhangjiang Hi-Tech Park, Pudong New
Kingdom, Zip: UB9 4DA Phone:+65-6225-8139 Area,
Phone : +44 (0)1895 256484 conferences@qaiglobal.com Shanghai, China Zip: 201203
conferences@qaiglobal.com Phone : +86-21-51314155
conferences@qaiglobal.com
www.qaiglobal.c © QAI India Limited. All rights QAI
© reserved.
All rights reserved. No part of this document may be reproduced or distributed in any form or by
any means, or stored in a database or retrieval system, without prior written permission of QAI