CMMI

1. CMMI
Chapter 3
1

2. 2
Focus of CMMI
SW-CMM is applied here
CMMI is applied here

3. 3
Everyone realizes the importance of having a
motivated, quality work force but...
• ...even our finest people can’t
perform at their best when the
process is not understood or
operating
“at its best.”
PEOPLE
PROCESS
TECHNOLOGY
Quality Leverage Points
Major determinants of product cost,
schedule, and quality

4. 4
Why Focus on Process?
• Process provides a constructive, high-leverage
focus...
– as opposed to a focus on people
• Your work force, on the average, is as “good” as it is trained
to be.
• Working harder is not the answer.
• Working smarter, through process, is the answer.
– as opposed to a focus on technology
• Technology applied without a suitable roadmap will not
result in significant payoff.
• Technology provides the most benefit in the context of an
appropriate process roadmap.

5. 5
Underlying Premise of Process
Improvement
“The quality of a product is
largely determined by the quality
of the process that is used to
develop and maintain it.”

6. 6
Categories of Process Improvement
Benefits
• Process improvement benefits fall into eight general
categories:
– improved schedule and budget predictability
– improved cycle time
– increased productivity
– improved quality (as measured by defects)
– increased customer satisfaction
– improved employee morale
– increased return on investment
– decreased cost of quality

7. 7
What is a CMM?
• Capability Maturity Model:
A reference model of mature practices in a specified discipline,
used to assess a group’s capability to perform that discipline
• CMMs differ by
– Discipline (software, systems, acquisition, etc.)
– Structure (staged versus continuous)
– How Maturity is Defined (process improvement path)
– How Capability is Defined (institutionalization)

8. What is CMMI?
• CMMI (Capability Maturity Model Integration) is a proven industry
framework to improve product quality and development efficiency for
both hardware and software
– Sponsored by US Department of Defense in cooperation with Carnegie
Mellon University and the Software Engineering Institute (SEI)
– Many other companies involved in CMMI definition such as Motorola
and Ericsson
– CMMI has been established as a model to improve business results
• CMMI, staged, uses 5 levels to describe the maturity of the organization,
same as predecessor CMM
– Vastly improved version of the CMM
– Emphasis on business needs, integration and institutionalization
8

9. How can CMMI help?
• CMMI provides a way to focus and manage hardware and software development from
product inception through deployment and maintenance.
– ISO/TL9000 are still required. CMMI interfaces well with them. CMMI and TL are
complementary - both are needed since they address different aspects.
• TL9000 is a process compliance standard
• CMMI is a process improvement model
• Behavioral changes are needed at both management and staff levels. Examples:
– Increased personal accountability
– Tighter links between Product Management, Development, SCM, etc.
• Initially a lot of investment required – but, if properly managed, we will be more
efficient and productive while turning out products with consistently higher quality.
9

10. 10
So Many Models, So Little Time
Software
CMM
Software
CMM
Systems
Security
Engr CMM
Systems
Security
Engr CMM
Systems
Engr
CMM
Systems
Engr
CMM
People
CMM
People
CMM
IPD
CMM
IPD
CMM
Software
Acq
CMM
Software
Acq
CMM
• Different structures,
formats, terms, ways of
measuring maturity
• Causes confusion,
especially when using
more than one model
• Hard to integrate them
in a combined
improvement program
• Hard to use multiple
models in supplier
selection

11. 11
Bridging the Divide
CMMI:
•Integrates systems and
software disciplines into
one process
improvement
framework.
•Provides a framework
for introducing new
disciplines as needs
arise.

12. CMMI Models within the Framework
• Models:
– Systems Engineering + Software Engineering (SE/SW)
– Systems Engineering + Software Engineering + Integrated Product and Process
Development (IPPD)
– Systems Engineering + Software Engineering + Integrated Product and Process
Development + Supplier Sourcing (SS)
– Software Engineering only
• Representation options:
– Staged
– Continuous
• The CMMI definition of “Systems Engineering” -
“The interdisciplinary approach governing the total technical and managerial
effort required to transform a set of customer needs, expectations and
constraints into a product solution and to support that solution throughout the
product’s life.” This includes both hardware and software.
12

13. CMMI Staged Representation - 5 Maturity Levels
Level 5
Initial
Level 1
Processes are unpredictable, poorly controlled, reactive.
Managed
Level 2
Processes are planned, documented, performed, monitored,
and controlled at the project level. Often reactive.
Defined
Level 3
Processes are well characterized and understood.
Processes, standards, procedures, tools, etc. are
defined at the organizational (Organization X ) level.
Proactive.
Quantitatively
Managed
Level 4
Processes are controlled using statistical
and other quantitative techniques.
Optimizing
ProcessM
aturity
Process performance continually
improved through incremental and
innovative technological
improvements.
13

14. 14
Behaviors at the Five Levels
Initial
Managed
Defined
Quantitatively
Managed
Optimizing
Process is unpredictable,
poorly controlled, and
reactive
Process is characterized
for projects and is often
reactive
Process is characterized
for the organization and
is proactive
Process is measured
and controlled
Focus is on continuous
quantitative improvement
Maturity Level Process Characteristics Behaviors
Focus on "fire prevention";
improvement anticipated and
desired, and impacts assessed.
Greater sense of teamwork and inter-
dependencies
Reliance on defined process. People
understand, support and follow the
process.
Over reliance on experience of good
people – when they go, the process
goes. “Heroics.”
Focus on "fire fighting";
effectiveness low – frustration high.

15. 15
CMMI Components
• Within each of the 5 Maturity Levels, there are basic functions that
need to be performed – these are called Process Areas (PAs).
• For Maturity Level 2 there are 7 Process Areas that must be
completely satisfied.
• For Maturity Level 3 there are 11 Process Areas that must be
completely satisfied.
• Given the interactions and overlap, it becomes more efficient to
work the Maturity Level 2 and 3 issues concurrently.
• Within each PA there are Goals to be achieved and within each
Goal there are Practices, work products, etc. to be followed that
will support each of the Goals.

16. 16
Maturity Level Project Managment Engineering Process Management Support
5
Optimizing
Organizational Innovation & Deployment Causal Analysis & Resolution
4
Quantitatively
Managed
Quantitative Project Mngt Organizational Process Performance
3
Defined
Integrated Project Mngt
Risk Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Decision Analysis & Resolution
2
Managed
Project Planning
Project Monitoring &
Control
Supplier Agreement Mngt
Requirements Mngt Measurement & Analysis
Process & Product Quality Assurance
Configuration Mngt
1
Initial
CMMI Process Areas

17. 17
CMMI Terminology & Structure
Maturity Levels (1 - 5)
Generic
Practices
Generic
Goals
Process Area 2
Common Features
Process Area 1 Process Area n
Verifying
Implementation
Specific
Goals
Specific
Practices
Ability
to Perform
Directing
Implementation
RequiredRequired
Sub practices , typical work products,
discipline amplifications, generic
practice elaborations, goal and
practice titles, goal and practice notes,
and references
Commitment
to Perform
Sub practices , typical work products,
discipline amplifications, generic
practice elaborations, goal and
practice titles, goal and practice notes,
and references
InformativeInformative
Required. Specific for
each process area.
Required. Common across
all process areas.

18. 18
Example
For the Requirements Management Process Area:
An example Goal (required):
“Manage Requirements”
An example Practice to support the Goal (required):
“Maintain bi-directional traceability of requirements”
Examples (suggested, but not required) of typical Work Products
might be
Requirements traceability matrix or
Requirements tracking system

19. Slide 19
Yet another CMMI term:
Institutionalization
• Building and reinforcement of corporate culture that supports
methods, practices and procedures so they are the ongoing way
of business……..
Required for all Process Areas

20. 20
The Next Step Is CMM Integration
• The CMM Integration Project was formed to
– build an initial set of integrated models
– improve best practices from source models based on
lessons learned
– establish a framework to enable integration of future
models
– create an associated set of appraisal and training
products
• Collaborative endeavor (over 100 people involved)
– Industry
– Government
– Software Engineering Institute (SEI)

21. 21
Bodies of Knowledge Captured in CMMI Models
•An organization selects the bodies of knowledge
most relevant to achieving its business objectives.
Bodies of knowledge* available in CMMI models
include
–software engineering(sw)
–systems engineering(se)
–integrated product and process development (IPPD)
–supplier sourcing (SS)
•*Each body of knowledge related to product or process development in CMMI is considered a
discipline.

22. 22
Software Engineering (SW)
• SW covers the development of software
systems
• SW focus on applying systematic, disciplined,
and quantifiable approaches to the
– development,
– operation
– maintenance

23. 23
System Engineering (SE)
• Systems engineering covers the development
of total systems, which may or may not
include software
• Systems engineers focus on transforming
customer needs, expectations, and constraints
into product solutions and supporting these
product solutions throughout the life of the
product

24. 24
Supplier sourcing (SS)
• As work efforts become more complex,
projects may use suppliers to perform
functions or add modifications to products
that are specifically needed by the project.
When those activities are critical, the project
benefits from enhanced source analysis and
from monitoring supplier activities before
product delivery

25. 25
Integrated Product & process
development (IPPD)
• IPPD is a systematic approach that achieves a
timely collaboration of relevant stakeholders
throughout the life of the product to better
satisfy customer needs, expectations, and
requirements

26. 26
IPPD - Definition
IPPD provides a systematic approach to product development
that achieves a timely collaboration of relevant stakeholders
throughout the product life cycle to better satisfy customer
needs.

27. 27
About IPPD
Integrated Product and Process Development
• IPPD affects all process areas.
• IPPD is not a discipline like SE or SW.
• Rather, it is a way of doing business.
• IPPD is employed in conjunction with the CMMI disciplines
(software and systems engineering).
• Implementation of IPPD shapes how you perform the work
in these disciplines.

28. 28
CMMI Models
Source Models
• Capability Maturity Model
for Software V2, draft C
(SW-CMM V2C)
• EIA Interim Standard 731,
System Engineering
Capability Model (SECM)
• Integrated Product
Development Capability
Maturity Model, draft V0.98
(IPD-CMM)
CMMI-SE/SW
Staged
Representation
CMMI-SE/SW
Continuous
Representation
• Combined System Engineering / Software
Engineering model
• Can be applied to:
– Just the software engineering projects in
an organization
– Just the system engineering projects in
an organization
– Both
– IPPD/SS can be used in either/both

29. 29
Understanding CMMI Representations
• There are two types of representations in the
CMMI models:
– staged
– continuous
• A representation allows an organization to
pursue different improvement objectives
• The organization and presentation of the data
are different in each representation. However,
the content is the same.

30. 30
Staged Representation
• Provides a proven sequence of improvements, each
serving as a foundation for the next
• Permits comparisons across and among organizations by
the use of maturity levels
• Provides an easy migration from the SW-CMM to CMMI
• Provides a single rating that summarizes appraisal results
and allows comparisons among organizations
Indicates maturity of an organization’s standard
process -- to answer, “What is a good order for
approaching improvement across the
organization?”

31. 31
CMMI Model Representations

32. 32
Maturity Levels
• A maturity level is a well-defined evolutionary
plateau of process improvement.
• There are five maturity levels.
• Each level is a layer in the foundation for
continuous process improvement using a proven
sequence of improvements, beginning with basic
management practices and progressing through
a predefined and proven path of successive
levels.

33. 33
The Maturity Levels
1
2
3
4
5
Process unpredictable,
poorly controlled, and
reactive
Process characterized for
projects and is often reactive
Process characterized for
the organization and is
proactive
Process measured
and controlled
Focus on continuous process
improvement
Optimizing
Quantitatively
Managed
Defined
Initial
Managed
Optimizing
Defined

34. Maturity Level 1
Initial
• Maturity Level 1 deals with performed processes.
• Processes are unpredictable, poorly controlled, reactive.
• The process performance may not be stable and may not meet
specific objectives such as quality, cost, and schedule, but useful
work can be done.
34

35. Maturity Level 2
Managed at the Project Level
• Maturity Level 2 deals with managed processes.
• A managed process is a performed process that is also:
– Planned and executed in accordance with policy
– Employs skilled people
– Adequate resources are available
– Controlled outputs are produced
– Stakeholders are involved
– The process is reviewed and evaluated for adherence to
requirements
• Processes are planned, documented, performed, monitored, and
controlled at the project level. Often reactive.
• The managed process comes closer to achieving the specific
objectives such as quality, cost, and schedule.
35

36. Maturity Level 3
Defined at the Organization Level
• Maturity Level 3 deals with defined processes.
• A defined process is a managed process that:
– Well defined, understood, deployed and
executed across the entire organization.
Proactive.
– Processes, standards, procedures, tools, etc. are
defined at the organizational (Organization X )
level. Project or local tailoring is allowed,
however it must be based on the organization’s
set of standard processes and defined per the
organization’s tailoring guidelines.
• Major portions of the organization cannot “opt out.”
36

37. 37
Maturity Levels Should Not
Be Skipped
• Each maturity level provides a necessary foundation
for effective implementation of processes at the next
level.
– Higher level processes have less chance of success
without the discipline provided by lower levels.
– The effect of innovation can be obscured in a
noisy process.
• Higher maturity level processes may be performed by
organizations at lower maturity levels, with the risk of
not being consistently applied in a crisis.

38. 38
Continuous Representation
• Allows you to select the order of
improvement that best meets your
organization’s business objectives and
mitigates your organization’s areas of risk
• Enables comparisons across and among
organizations on a process-area-by-process-
area basis
• Provides an easy migration from EIA 731 (and
other models with a continuous
representation) to CMMI

39. 39
Capability Levels
• A capability level is a well-defined evolutionary
plateau describing the organization’s capability
relative to a process area.
• There are six capability levels.
• For capability levels 1-5, there is an associated
generic goal.
• Each level is a layer in the foundation for
continuous process improvement.
• Thus, capability levels are cumulative, i.e., a
higher capability level includes the attributes of
the lower levels.

40. 40
The Capability Levels
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
1 Performed
0 Incomplete

41. 41
Relating Process Area Capability and
Organizational Maturity
• Organizational maturity is the focus of the staged
representation, whereas process area capability is the
focus of the continuous representation.
• Organizational maturity and process area capability
are similar concepts.
• The difference between them is that organizational
maturity pertains to a set of process areas across an
organization, while process area capability deals with
a set of processes relating to a single process area or
specific practice.

42. 42
Comparison of Representations
Staged Continuous
• Process improvement is
measured using maturity
levels.
• Maturity level is the degree
of process improvement
across a predefined set of
process areas.
• Organizational maturity
pertains to the “maturity” of
a set of processes across an
organization
Process improvement is measured
using capability levels.
Capability level is the
achievement of process
improvement within an individual
process area.
Process area capability pertains to
the “maturity” of a particular
process across an organization.

43. 43
Advantages of Each Representation
• Staged
• Provides a roadmap for implementing
– groups of process areas
– sequencing of implementation
• Familiar structure for those transitioning from the
Software CMM
• Continuous
• Provides maximum flexibility for focusing on specific
process areas according to business goals and
objectives
• Familiar structure for those transitioning from EIA 731

44. 44
Benefits of Continuing Process
Improvement
•SEI Software CMM Level 5: For the Right Reasons*
–Defects are now nearly all found and fixed before
testing begins.
–Defects escaping into the field have been reduced
from 11% to practically 0%.
–Programs consistently reach customer satisfaction
and performance targets.
–Peer reviews increase total project costs by 4%,
but reduced rework during testing by 31%.
R.O.I. is 7.75:1.

45. 45
CMM“I” – Improvement
• The CMMI Product Suite provides a foundation
for enterprise-wide improvement and adds
– new emphasis on products and services as well
as process
– emphasis on both process capability and
organizational maturity
– early emphasis on measurement and analysis
• The CMMI model improves upon Software CMM
V1.1 and Software CMM V2.0 Draft C.

46. 46
CMM“I” – Integration
• Provides expanded model scope for
integration
– Integrated Product Management
– Integrated Supplier Management
– Decision Analysis and Resolution
– “Relevant Stakeholder” planning and execution
– Inclusion of the Integrated Product and Process
Development body of knowledge

47. 47
Improving on the Software CMM
• CMMI Models improve on the best practices in Software CMM Version 2.0
Draft C:
– Incorporates 4+ additional years of learning
– More explicitly links management and engineering activities to business
objectives
– Expands the scope of and visibility into the product life cycle and
engineering activities to ensure the product or service meets customer
expectations
– Incorporates additional areas of best practice (e.g., measurement, risk
management, bi-directional traceability in requirements management,
decision analysis and resolution, and supplier management)
– Captures more robust high-maturity practices
– Addresses additional generic practices needed for institutionalization
– More fully complies with relevant ISO standards

48. 48
CMMI Can Benefit You
• CMMI provides
– Efficient, effective assessment and improvement
across multiple process disciplines in an organization
– Improvements to best practices incorporated from
the Software CMM
– A common, integrated vision of improvement for all
elements of an organization
– A means of representing new discipline-specific
information in a standard, proven process-
improvement context

49. 49
Available Models
• The following CMMI Models exist:
– SE/SW Staged
– SE/SW Continuous
– SE/SW/IPPD Staged
– SE/SW/IPPD Continuous
– SE/SW/IPPD/SS Staged
– SE/SW/IPPD/SS Continuous
– SW Staged
– SW Continuous

50. 50
Selecting a Discipline to Use
• Different model versions exist
– CMMI-SW -- CMMI-SE/SW/IPPD
– CMMI-SE/SW -- CMMI-SE/SW/IPPD/SS
• You select which disciplines you wish to use, based on where you are trying to
improve
• Example – A company which engineers and builds computer systems, by acquisition
of COTS hardware and development of custom software, using integrated teams
– Use CMMI-SW applied only to the software development
– Use CMMI-SE/SW applied to the computer system and the software
– Use CMMI-SE/SW/IPPD applied to the system, software, and use of teams
– Use CMMI-SE/SW/IPPD applied to the system, software, teams, and COTS
acquisition

51. 51
CMMI Structure
one Model, Two Representations
Maturity Level 5
OID, CAR
Maturity Level 4
OPP, QPM
Maturity Level 3
REQD, TS, PI, VER,
VAL, OPF, OPD, OT,
IPM, RSKM, DAR
Overview
Introduction
Structure of the Model
Model Terminology
Maturity Levels, Common Features, and Generic Practices
Understanding the Model
Using the Model
Maturity Level 2
REQM, PP, PMC,
SAM, MA, PPQA, CM
Appendixes
Engineering
REQM, REQD, TS,
PI, VER, VAL
Project Management
PP, PMC, SAM
IPM, RSKM, QPM
Process Management
OPF, OPD, OT,
OPP, OID
Process Management
PAs
- Goals
- Practices
Support
CM, PPQA, MA,
CAR, DAR
Appendixes
CMMI-SE/SW
Staged
Overview
Introduction
Structure of the Model
Model Terminology
Capability Levels and Generic Model Components
Understanding the Model
Using the Model
CMMI-SE/SW
Continuous

52. 52
CMMI Model Structure

53. 53
Staged Representation:
Process Areas by Maturity Level
Organizational Innovation and Deployment
Causal Analysis and Resolution5 Optimizing
4 Quantitatively
Managed
3 Defined
2 Managed
Continuous
process
improvement
Quantitative
management
Process
standardization
Basic
project
management
Organizational Process Performance
Quantitative Project Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Integrated Supplier Management
Risk Management
Decision Analysis and Resolution
Organizational Environment for Integration
Integrated TeamingRequirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
1 Initial
Process AreasLevel Focus
(IPPD)
(IPPD)
(SS)

54. 54
Requirements Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Engineering
Project
Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Integrated Project Management(IPPD)
Integrated Supplier Management (SS)
Integrated Teaming (IPPD)
Risk Management
Quantitative Project Management
Organizational Process Focus
Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment
Process
Management
Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Causal Analysis and Resolution
Decision Analysis and Resolution
Organizational Environment for Integration (IPPD)
Support
Continuous Representation:
Organization of Process Areas
Category Process Area

55. SW-CMM V1.1 vs. CMMI V1.1
Defect Prevention Causal Analysis and Resolution
Technology Change Mgmt Organizational Innovation & Deployment
Process Change Management
Quantitative Process Mgmt Organizational Process Performance
Software Quality Mgmt Quantitative Project Management
Organization Process Focus Organization Process Focus
Organization Process Definition Organization Process Definition
Training Program Organizational Training
Integrated Software Mgmt Integrated Project Management
Risk Management
Software Product Engr Requirements Development
Technical Solution
Product Integration
Intergroup Coordination Verification
Peer Reviews Validation
Decision Analysis and Resolution
Requirements Management Requirements Management
Software Project Planning Project Planning
Software Project Tracking & Oversight Project Monitoring and Control
Software Subcontract Mgmt Supplier Agreement Management
Software Quality Assurance Product & Process Quality Assurance
Software Configuration Mgmt Configuration Management
Measurement and Analysis
LEVEL 5
OPTIMIZING
LEVEL 4
MANAGED
LEVEL 3
DEFINED
LEVEL 2
REPEATABLE
55
Key Process Areas (KPAs) Process Areas (PAs)
55

56. 56
Support Process Areas
There are 5 Support Process Areas:
– Configuration Management (L2)
– Process and Product Quality Assurance (L2)
– Measurement and Analysis (L2)
– Causal Analysis and Resolution (L5)
– Decision Analysis and Resolution (L3)

57. 57
Understanding Support Processes
• Support process areas cover the practices that support
product development, maintenance, and acquisition.
• They provide essential processes used by all the CMMI
process areas, and are typically used in the context of
performing other processes.

58. Casual Analysis and Resolution
– The purpose of Causal Analysis and Resolution (CAR) is to identify
causes of defects and other problems and take action to prevent them
from occurring in the future.
SG 1 Determine Causes of Defects
– SP 1.1 Select Defect Data for Analysis
– SP 1.2 Analyze Causes
SG 2 Address Causes of Defects
– SP 2.1 Implement the Action Proposals
– SP 2.2 Evaluate the Effect of Changes
– SP 2.3 Record Data
58

59. Configuration Management
• The purpose of Configuration Management (CM) is to establish and
maintain the integrity of work products using configuration identification,
configuration control, configuration status accounting, and configuration
audits.
Specific Goal and Practice Summary
SG 1 Establish Baselines
– SP 1.1 Identify Configuration Items
– SP 1.2 Establish a Configuration Management System
– SP 1.3 Create or Release Baselines
SG 2 Track and Control Changes
– SP 2.1 Track Change Requests
– SP 2.2 Control Configuration Items
SG 3 Establish Integrity
– SP 3.1 Establish Configuration Management Records
– SP 3.2 Perform Configuration Audits
59

60. Decision Analysis and Resolution
• The purpose of Decision Analysis and Resolution (DAR) is to analyze
possible decisions using a formal evaluation process that evaluates
identified alternatives against established criteria.
Specific Goal and Practice Summary
SG 1 Evaluate Alternatives
– SP 1.1 Establish Guidelines for Decision Analysis
– SP 1.2 Establish Evaluation Criteria
– SP 1.3 Identify Alternative Solutions
– SP 1.4 Select Evaluation Methods
– SP 1.5 Evaluate Alternatives
– SP 1.6 Select Solutions
60

61. Measurement and Analysis
• The purpose of Measurement and Analysis (MA) is to develop and sustain
a measurement capability that is used to support management
information needs.
SG 1 Align Measurement and Analysis Activities
– SP 1.1 Establish Measurement Objectives
– SP 1.2 Specify Measures
– SP 1.3 Specify Data Collection and Storage Procedures
– SP 1.4 Specify Analysis Procedures
SG 2 Provide Measurement Results
– SP 2.1 Collect Measurement Data
– SP 2.2 Analyze Measurement Data
– SP 2.3 Store Data and Results
– SP 2.4 Communicate Results
61

62. Process and Product Quality
Assurance
• The purpose of Process and Product Quality Assurance (PPQA) is to
provide staff and management with objective insight into processes and
associated work products.
Specific Goal and Practice Summary
SG 1 Objectively Evaluate Processes and Work Products
• SP 1.1 Objectively Evaluate Processes
• SP 1.2 Objectively Evaluate Work Products and Services
SG 2 Provide Objective Insight
• SP 2.1 Communicate and Ensure Resolution of Noncompliance
Issues
• SP 2.2 Establish Records
62

63. 63
Project Management
Process Areas
• There are eight Project Management Process Areas.
– Project Planning (L2)
– Project Monitoring and Control (L2)
– Integrated Project Management (IPPD) (L3)
– Risk Management (L3)
– Supplier Agreement Management (L2)
– Quantitative Project Management (L4)

64. Project Planning
• The purpose of Project Planning (PP) is to establish and maintain plans
that define project activities.
SG 1 Establish Estimates
• SP 1.1 Estimate the Scope of the Project
• SP 1.2 Establish Estimates of Work Product and Task Attributes
• SP 1.3 Define Project Lifecycle
• SP 1.4 Determine Estimates of Effort and Cost
SG 2 Develop a Project Plan
• SP 2.1 Establish the Budget and Schedule
• SP 2.2 Identify Project Risks
• SP 2.3 Plan for Data Management
• SP 2.4 Plan for Project Resources
• SP 2.5 Plan for Needed Knowledge and Skills
• SP 2.6 Plan Stakeholder Involvement
• SP 2.7 Establish the Project Plan
SG 3 Obtain Commitment to the Plan
• SP 3.1 Review Plans That Affect the Project
• SP 3.2 Reconcile Work and Resource Levels
• SP 3.3 Obtain Plan Commitment
64

65. Project Monitoring and control
• The purpose of Project Monitoring and Control (PMC) is to provide an
understanding of the project’s progress so that appropriate corrective
actions can be taken when the project’s performance deviates
significantly from the plan.
SG 1 Monitor Project Against Plan
• SP 1.1Monitor Project Planning Parameters
• SP 1.2Monitor Commitments
• SP 1.3Monitor Project Risks
• SP 1.4Monitor Data Management
• SP 1.5Monitor Stakeholder Involvement
• SP 1.6Conduct Progress Reviews
• SP 1.7Conduct Milestone Reviews
SG 2 Manage Corrective Action to Closure
• SP 2.1Analyze Issues
• SP 2.2Take Corrective Action
• SP 2.3Manage Corrective Action
65

66. 66
Engineering Process Areas
• There are six Engineering Process Areas.
– Requirements Management (L2)
– Requirements Development (L3)
– Technical Solution (L3)
– Product Integration (L3)
– Verification (L3)
– Validation (L3)

67. Requirements Development
• The purpose of Requirements Development (RD) is to produce and
analyze customer, product, and product component requirements.
SG 1 Develop Customer Requirements
– SP 1.1 Elicit Needs
– SP 1.2 Develop the Customer Requirements
SG 2 Develop Product Requirements
– SP 2.1 Establish Product and Product Component Requirements
– SP 2.2 Allocate Product Component Requirements
– SP 2.3 Identify Interface Requirements
SG 3 Analyze and Validate Requirements
– SP 3.1 Establish Operational Concepts and Scenarios
– SP 3.2 Establish a Definition of Required Functionality
– SP 3.3 Analyze Requirements
– SP 3.4 Analyze Requirements to Achieve Balance
– SP 3.5 Validate Requirements
67

68. Product Integration
• The purpose of Product Integration (PI) is to assemble the product from
the product components, ensure that the product, as integrated,
functions properly, and deliver the product.
SG 1 Prepare for Product Integration
– SP 1.1 Determine Integration Sequence
– SP 1.2 Establish the Product Integration Environment
– SP 1.3 Establish Product Integration Procedures and Criteria
SG 2 Ensure Interface Compatibility
– SP 2.1 Review Interface Descriptions for Completeness
– SP 2.2 Manage Interfaces
SG 3 Assemble Product Components and Deliver the Product
– SP 3.1 Confirm Readiness of Product Components for Integration
– SP 3.2 Assemble Product Components
– SP 3.3 Evaluate Assembled Product Components
– SP 3.4 Package and Deliver the Product or Product Component
68

69. 69
Process Management Process Areas
• There are five Process Management Process Areas:
– Organizational Process Focus (L3)
– Organizational Process Definition (L3)
– Organizational Training (L3)
– Organizational Process Performance (L4)
– Organizational Innovation and Deployment (L5)

70. Organizational Process Focus
• The purpose of Organizational Process Focus (OPF) is to plan, implement, and
deploy organizational process improvements based on a thorough understanding
of the current strengths and weaknesses of the organization’s processes and
process assets.
SG 1 Determine Process Improvement Opportunities
• SP 1.1Establish Organizational Process Needs
• SP 1.2Appraise the Organization’s Processes
• SP 1.3Identify the Organization's Process Improvements
SG 2 Plan and Implement Process Improvements
• SP 2.1Establish Process Action Plans
• SP 2.2Implement Process Action Plans
SG 3 Deploy Organizational Process Assets and Incorporate Lessons Learned
• SP 3.1Deploy Organizational Process Assets
• SP 3.2Deploy Standard Processes
• SP 3.3Monitor Implementation
• SP 3.4Incorporate Process-Related Experiences into the Organizational Process
Assets
70

71. Organizational Process
Performance
• The purpose of Organizational Process Performance (OPP) is to establish and
maintain a quantitative understanding of the performance of the organization’s
set of standard processes in support of quality and process-performance
objectives, and to provide the process-performance data, baselines, and models to
quantitatively manage the organization’s projects.
SG 1 Establish Performance Baselines and Models
– SP 1.1 Select Processes
– SP 1.2 Establish Process-Performance Measures
– SP 1.3 Establish Quality and Process-Performance Objectives
– SP 1.4 Establish Process-Performance Baselines
– SP 1.5 Establish Process-Performance Models
71

72. 72
Process Areas Organized by Category
Process Management
Organizational Process Focus
Organizational Process Definition
Organizational Training
Organizational Process Performance
Organizational Innovation and Deployment
Project Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Integrated Project Management
Risk Management
Quantitative Project Management
Engineering
Requirements Development
Requirements Management
Technical Solution
Product Integration
Verification
Validation
Support
Configuration Management
Process and Product Quality Assurance
Measurement and Analysis
Decision Analysis and Resolution
Causal Analysis and Resolution
analyze
empower analyze
employ measure & assist
standardize
processes

73. 73
Summary
• There is one CMMI Model with two representations, Staged
and Continuous
• The material in both representations is the same just organized
differently
• Each representation provides different ways of implementing
processes
• Equivalent Staging provides a mechanism for relating Maturity
Levels to Capability Levels
• The CMMI model should be applied using intelligence, common
sense, and professional judgment

74. 74
For More Information About
CMMI–Go to CMMI Website
• http://sei.cmu.edu/cmmi
• http://seir.sei.cmu.edu/seir/
• http://www.ndia.org/ (annual CMMI Conference)
• www.google.com

75. 75
Further Reading