Introduction to the CMMI

1
Introduction to the Capability Maturity Model
Integration (CMMI)
2
Quality Leverage Points
Everyone realizes the importance of having a
motivated, quality work force but...
PEOPLE

• ...even our finest people cant perform at their
  best when the process is not understood or
  operating at its best.

TECHNOLOGY
PROCESS
Major determinants of product cost, schedule, and
quality
3
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.

4
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.
5
Early Process Improvement

• The theories of process management are a
  synthesis of the concepts of Deming, Crosby,
  Juran, and others.
• Over the past 30 years, these theories have been
  used to address problems common to many
  organizations.
• Solutions have been discovered, but a gap existed
  between the state of the practice and the state
  of the art.
• Many of these concepts have been used to build
  process-improvement models.

6
What Is a Process Model?

• A model is a structured collection of elements
  that describe characteristics of effective
  processes.
• Processes included are those proven by experience
  to be effective.

7
How Is a Model Used?

• A model is used
• to help set process improvement objectives and
  priorities, improve processes, and provide
  guidance for ensuring stable, capable, and mature
  processes
• as a guide for improvement of organizational
  processes

8
Why Is a Model Important?

• A model provides
• a place to start
• the benefit of a communitys prior experiences
• a common language and a shared vision
• a framework for prioritizing actions

9
What Model do I use?

• Historically Depends on the discipline that you
  want to model.
• Software Engineering
• Systems Engineering
• Software Acquisition
• Systems Security
• etc.

10
What is a CMM?

• Capability Maturity Model A reference model of
  mature practices in a specified discipline, used
  to assess a groups 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)
• Capability Maturity Model and CMM are used by
  the Software Engineering Institute (SEI) to
  denote a particular class of maturity models

Capability Maturity Model, CMM, CMM
Integration, and CMMI are service marks and
registered trademarks of Carnegie Mellon
University
11
Commonly Used CMMs

• Software CMM staged software development
• System Engineering CMM continuous system
  engineering
• Software Acquisition CMM staged software
  acquisition
• System Security Engineering CMM continuous securit
  y engineering
• FAA-iCMM continuous software engineering, systems
  engineering, and acquisition
• IPD-CMM hybrid integrated product development
• People CMM staged workforce
• SPICE Model continuous software development

12
So Many Models, So Little Time
ZZZ 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

EIA 731
Software CMM
SystemsEngr CMM
People CMM
IPD CMM
SoftwareAcq CMM
FAA iCMM
Systems SecurityEngr CMM
13
CMMI to the Rescue!

• Integrates systems and software disciplines into
  one process improvement framework.
• Provides a framework for introducing new
  disciplines as needs arise.

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

• 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 can be used ineither/both

14
Improvements in CMMI

• The CMMI
• Incorporates additional years of learning
• More explicitly links best practices to business
  objectives
• Expands the scope of and visibility into the
  product life cycle and engineering activities
• Adds more best practices (e.g., Measurement, Risk
  Management, Product Integration, 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

15
What is CMMI?

• CMMI is
• a model that provides a set of best practices
  that address productivity, performance, costs,
  and stakeholder satisfaction
• a model which provides a structured view of
  process improvement across an organization
• CMMI can help
• set process improvement goals and priorities
• provide guidance for quality processes
• provide a yardstick for appraising current
  practices
• CMMI is NOT
• a set of bolt-on processes that last only as
  long as the wheel is squeaking. CMMI provides a
  consistent, enduring framework that accommodates
  new initiatives.
• restricted to a single discipline (I.e. Software
  Engineering or Systems Engineering). CMMI focuses
  on the total software intensive system problem
  and integrates multiple disciplines into one
  process-improvement framework that eliminates
  inconsistencies and reduces duplication

16
Benefits of CMMI for Managers/Practitioners

• Differences in behaviors and outcomes you can
  expect to see with CMMI
• Commitment
• understanding who the stakeholders are and
  achieving common understanding with them of the
  project's scope/requirements
• moving from accepting changes without adequate
  impact analysis to
• negotiated changes based on impact
• Control
• management moves from after-the-fact corrective
  action to measurement-focused, more proactive
  controls throughout the program
• requirements are fundamental basis for planning
  and control
• risk management is explicitly used throughout the
  systems and software engineering disciplines
• Communication
• management focus moves from communication is an
  extra step in the process to communication is
  vital to keeping the process going
• notion of stakeholders as the base for
  communication expands the scope of communication
  activities

17
Benefits of CMMI for Senior Managers

• MORE....
• focus on requirements as the basis for planning
  and changes
• early information on risks and problems
• LESS....
• firefighting
• making commitments without adequate impact
  analysis
• rewarding of firefighting vs fire prevention
  behaviors
• Resulting in....
• fewer letters/phone calls from unsatisfied
  external customers on systems issues
• less shipping of engineers to the field until
  the problems are solved
• more visibility into ability to meet system
  schedules and budgets

18
Benefits of CMMI for Program Managers

• MORE...
• involvement in understanding system and software
  requirements and their impact on the system
• routine visibility into project progress
• visibility into subsystem subcontracts
• insight into subsystem subcontractor risks
• LESS/FEWER....
• large, unmanageable tasks
• reason or ability to make un-negotiated
  commitments
• accepting requirements changes without adequate
  impact analysis

19
History of the CMMI
1987
1991
1995
1997
2000
2002
1993
First CMM Published
SW-CMM v1.1 Published
CMMI-SE/SW Version 1.0 Published
Model Refined and Published as SW-CMM v1.0
CMMI Initiative Launched
CMMI-SE/SW/IPPD/A Version 1.1 Published
Software Acquisition (SA-CMM), Systems
Engineering (SE-CMM), Integrated Product
Development (IPD-CMM), Organizational Workforce
Capability Development (People CMM) Developed
20
The CMMI Project

• DoD sponsored collaboration between industry,
  Government, SEI
• Over 100 people involved

• KPMG
• Lockheed Martin
• Motorola
• Northrop Grumman
• Pacific Bell
• Q-Labs
• Raytheon
• Reuters
• Rockwell Collins
• SAIC
• Software Productivity Consortium
• Sverdrup Corporation
• TeraQuest
• Thomson CSF
• TRW

• U.S. Army, Navy, Air Force
• Federal Aviation Administration
• National Security Agency
• Software Engineering Institute
• ADP, Inc.
• ATT Labs
• BAE
• Boeing
• Computer Sciences Corporation
• EER Systems
• Ericsson Canada
• Ernst and Young
• General Dynamics
• Harris Corporation
• Honeywell

21
CMMI Maturity Profile Reporting Organizational
Types
22
CMMI Maturity Profile Types of Organizations
23
CMMI Maturity Profile Summary
24
CMMI Maturity Profile Summary
25
CMMI Model Representations
26
CMMI Model Structure
27
One Model, Two Representations
28
CMMI Process Area Contents

• Purpose
• Introductory Notes
• Goals Specific and Generic
• Practices Specific and Generic
• Typical Work Products
• Sub-practices
• Notes
• Discipline Amplifications
• Generic Practice Elaborations

• Required
• Expected
• Informative

29
CMMI Maturity Levels
30
CMMI Process Areas
31
Level 2, Managed

• Requirements Management
• Manage the requirements of the projects
  products and product components and to identify
  inconsistencies between those requirements and
  the projects plans and work products.
• Project Planning
• Establish and maintain plans that define
  project activities
• Project Monitoring and Control
• Provide an understanding of the projects
  progress so that appropriate corrective actions
  can be taken when the projects performance
  deviates significantly from the path.

32
Level 2, Managed (Continued)

• Supplier Agreement Management
• Manage the acquisition of products from
  suppliers for which there exists a formal
  agreement
• Measurement and Analysis
• Develop and sustain a measurement capability
  that is used to support management information
  needs
• Process and Product Quality Assurance
• Provide staff and management with objective
  insight into processes and associated work
  products
• Configuration Management
• Establish and maintain the integrity of work
  products using configuration identification,
  configuration status accounting, and
  configuration audits.

33
Level 3, Defined

• Requirements Development
• Produce and analyze customer, product, and
  product-component requirements
• Technical Solution
• Design, develop, and implement solutions t
  requirements.
• Product Integration
• Assemble the product from the product components,
  
• ensure that the product, as integrated, functions
  properly, and
• deliver the product

34
Level 3, Defined (Continued)

• Verification
• Ensure that the Selected work products meet
  their specified requirements
• Validation
• Demonstrate that a product or product
  component fulfils its intended use when placed in
  its intended environment
• Risk Management
• Identify potential problems before the occur,
  so that risk-handling activities may be planned
  and invoked as needed across the life of the
  product or project to mitigate adverse impacts on
  achieving objectives

35
Level 3, Defined (Continued)

• Organizational Process Focus
• Plan and implement organizational process
  improvement based on a thorough understanding of
  the current strengths and weaknesses of the
  organizations processes and process assets
• Organizational Process Definition
• Establish and maintain a usable set of
  organizational process assets
• Organizational Training
• Develop the skills and knowledge of people so
  they can perform their roles effectively and
  efficiently

36
Level 3, Defined (Continued)

• Integrated Project Management for IPPD
• Establish and manage the project and the
  involvement of the relevant stakeholders
  according to an integrated and defined process
  that is tailored from the organizations set of
  standard processes
• Integrated Teaming
• Form and sustain an integrated team for the
  development of work products
• Integrated Supplier Management
• Proactively identify sources of products that
  may be used to satisfy the projects requirements
  and to manage selected suppliers while
  maintaining a project-supplier relationship

37
Level 3, Defined (Continued)

• Decision Analysis and Resolution
• Analyze possible decisions using a formal
  evaluation process that evaluated identified
  alternatives against established criteria
• Organizational Environment for Integration
• Provide an IPPD infrastructure and manage
  people for integration

38
Level 4, Quantitatively Managed

• Organizational Process Performance
• Establish and maintain a quantitative
  understanding of the performance of the
  organizations 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 organizations projects
• Quantitative Project Management
• Quantitatively manage the projects defined
  process to achieve the projects established
  quality and process-performed objectives

39
Level 5, Optimizing

• Organizational Innovation and Deployment
• Select and deploy incremental and innovative
  improvements that measurably improve the
  organizations processes and technologies.
• Causal Analysis and Resolution
• Identify causes of defects and other problems
  and take action to prevent them from occurring in
  the future

40
CMMI Product Suite

• Models
• Disciplines
• Systems Engineering SE
• Software Engineering SW
• Integrated Product and Process Development (IPPD)
• Supplier Sourcing (SS)
• Representations
• Staged
• Continuous

• Training
• Model
• Introduction to CMMI
• Intermediate Concepts
• Instructor Training
• Lead Appraiser
• Appraisal methods
• Appraisal Requirements for CMMI (ARC)
• SCAMPI Method Description Document (MDD)

41
CMMI What is coming next?

• Emphasis through 2003 is on CMMI adoption and
  transition from legacy models
• Quarterly transition workshops will complement an
  annual User Workshop and SEPG Conference
• Communities of Practice will be encouraged
• Course Instructors
• CMMI Appraisers
• Transition Teams
• Technical Notes and Special Reports will
  complement V1.1
• Mapping CMMI with other standards and models
• Managing COTS integration
• Making attribute tradeoffs in design
• Allowing prototypical coverage for specific
  interests (e.g., safety, security, modeling and
  simulation)