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