TSU CMM CMMI

Capability Maturity Model /
Capability Maturity Model Integration
CS 3398 Software Engineering
November 12, 2003
Terry Startzel, Senior Consultant
Cooper Consulting Company
Texas State University |Texas State University |
San MarcosSan Marcos

Greetings and Welcome!
Greetings and Welcome
to this Presentation on the Capability Maturity Model
(CMM) / Capability Maturity Model Integration
(CMMI)
I would like to thank Dr. Beard for the invitation to
provide you with this introduction to model-based
software engineering process improvement!
Before we get going, lets introduce ourselves.

Introduction
Quality Products Are The Result Of
Quality Processes
Imagine for a moment that you work for a private
business or a department of government and you are
the business owner of a software development
project with an approved budget of $11,000,000.00.

Introduction
Quality Processes
Imagine further that to increase your opportunities
for success, you plan to outsource this project to a
software consulting company. Finally, imagine that
five companies have submitted bids in response to
your request for offer.

Introduction
Quality Processes
Now ask yourself, what criteria would you use to
select one of those five consulting companies?
Would your selection be based solely upon the lowest
cost? Or would other criteria be equally important
like the company’s track record for success?

Introduction
Quality Processes
The bottom line is that, while cost is important, you
would be searching for a mature consulting company
with a history of satisfied customers and a well
deserved reputation for excellence.

Introduction
Quality Processes
Now, if you were the owner of a software consulting
company and you wanted to enhance your
company’s competitiveness by achieving these types
of results, what is the most important thing you
could do to enhance your opportunities for success?

Introduction
Quality Processes
The answer is simple. To enhance your company’s
opportunities for success project after project, a
mature, efficient and effective software engineering
process is required. Quality software products are
produced by quality software engineering processes.

Introduction
Quality Processes
Assisting a company in their efforts to benchmark
and appraise their software engineering processes, as
well as to provide guidance to their process
improvement efforts, is the purpose of the Software
Engineering Institutes’ CMM/CMMI

Capability Maturity Model
Background and History
• In cooperation with major corporations and research
centers, Congress founded the Software Engineering
Institute (SEI) in 1984
www.sei.cmu.edu
• This non-profit, federally funded research and
development center was located and operated by the
Carnegie-Mellon University in Pittsburg, PA
• SEI was created as a research body to help improve
the practice of software engineering

• At its founding, its goal was to assist American
software professionals maintain a competitive edge
in the field of software development
• To accomplish this goal, SEI embarked on a strategy
to bring an engineering discipline to the software
development profession
• One of the early results this initiative was the
Capability Maturity Model for Software or simply
CMM

• The U.S. Department of Defense (DoD), which
sponsors the SEI, commissioned the original CMM
• With escalating costs and schedule overruns, DoD
projects were fairing no better than commercial
software projects at that time
• To appreciate the rather dismal state of software
development in the late 80s, let’s review the research
study conducted by The Standish Group (TSG)
www.standishgroup.com

• In the 1994 CHAOS Report, TSG reported that
Corporate America spent more than $275 billion
each year on approximately 200,000 application
software projects
www.standishgroup.com/sample_research/chaos_1994_1.php
• Of these projects, only 16.2% were completed on
time and on budget, 31.1% were cancelled, and
52.7% exceeded their original cost estimates by
189%

• The CHAOS Report also identified multiple factors
that contributed to these unfortunate statistics like
poor requirements management
• Taken together as a whole, these factors were
indicative of software process immaturity
• Given this process immaturity, it is understandable
that the DoD needed a way to assess the software
engineering capabilities of its consultants and
suppliers and to identify best practices

• To provide the DoD with the required assessment
capability, SEI with assistance from the Mitre
Corporation began developing a process maturity
framework in 1986
• The basic principles and concepts upon which the
CMM was based was described by Watts S.
Humphrey, who worked for IBM and then SEI, in
his book Managing the Software Process published in
1989

• The fully developed model, CMM for Software V1.1,
was published by SEI in 1993 as a technical report
authored by Mark Paulk and other SEI engineers
• In 1995, The Capability Maturity Model: Guidelines
for Improving the Software Process by Mark Paulk et.
al. was published by Addison-Wesley
• A major update to the CMM for Software, V2.0, was
in the process of being reviewed when work was
cancelled with to the launch of the CMMI Project

• CMM for Software is not a proprietary software
engineering process
• That is, the CMM identifies what processes should be
performed by a mature software development
organization not how an organization should
perform these processes
• To this end, it provides a broad process assessment
framework that enables an organization to
objectively determine its process maturity
Process Assessment Framework

• An organization is considered fully mature once it
has:
 Implemented measurable and controlled
processes that enable the organization to produce
quality software in a predictable, reliable, and
repeatable manner
 Implemented the capability to continuously
improve its processes in response to changes and
the availability of new technologies
Process Assessment Framework

• At its most fundamental, then, CMM is concerned
with continuous process improvement
• This approach can best be described as a spiral of
planning, implementing, and evaluating, with the
evaluation leading to new process improvements
• This approach is continuous in that this spiral
continues indefinitely and, in fact, must become
institutionalized within the supporting organization
Continuous Process Improvement

• In support of continuous process improvement,
CMM for Software is structured as a hierarchical
five-scale tier
• As such, it defines five levels of process maturity:
 Initial
 Repeatable
 Defined
 Managed
 Optimized

1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimized
• Project-Level Focus
• Basic Set of Software
Project Management
Controls
• Organization-Level Focus
• Institutionalized Software Management
and Engineering Processes
Quantitative Understanding of the
Software Processes and Products
and Defect Prevention

• Starting with maturity level 2, CMM defines goals
and Key Process Areas (KPA) specific to each level
• Implementing the KPAs and, thus, satisfying the
goals for a given level provides the foundation upon
which an organize can build and mature its processes
• According to CMM, all process improvement
initiatives should begin with a process appraisal to
determine the organization’s initial maturity level
Five Levels of Process Maturity

The Initial Level
• Level 1 organizations lack a set of sound project
management practices for developing software
• As such, Level 1 organizations tend to be ad hoc and
reaction-driven
• Success under these circumstances depends entirely
upon the skills and heroics of individuals team
members

The Initial Level
• In such an environment, very little learning occurs
because the factors that lead to a project success are
undocumented
• As a result, the success factors are not repeatable or
shareable across projects
• In 2001, SEI estimated that in the industry as a whole,
between 75 to 85 percent of all software development
organizations would assess at Level 1 [Persse, James (2001).
Implementing the Capability Maturity Model. John Wiley & Sons, Inc.]

The Repeatable Level
• In many ways, maturing from Level 1 to Level 2 is the
hardest step to take in CMM for Software
• At Level 2, a basic set of project planning and
management processes are implemented
• From the perspective of software process, Level 2
organizations become “self aware” and from this
awareness are able to learn and improve

The Repeatable Level
• Level 2, however, is very distinctly a project-focused
tier
• That is, Level 2 KPAs have not yet become
institutionalized and implementation of these
processes will initially vary from project to project
until they are refined and proven
• Even so, the way in which a project is planned and
managed is influenced by experienced gained from
similar projects and, thus, success becomes repeatable

As stated previously, the KPAs for Level 2 focus on
establishing a basic set of software project planning
and management processes:
 Requirements Management
 Software Project Planning
 Software Project Tracking and Oversight
 Software Quality Assurance
 Software Configuration Management
 Subcontractor Management
The Repeatable Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole, 5
to 10 percent of all software development
organizations would probably assess at Level 2 [Persse]
The Repeatable Level – SEI Estimate

• Once an organization has reached Level 2, and over
time, a refined and proven set of key software planning
and management processes will have emerged
• Moving from Level 2 to Level 3 then is not so much
focused on adopting new processes as it is with the
movement from a project-level focus to an
organization-level focus
• That is, these key planning and management processes
have become institutionalized within the organization
The Defined Level

• As a result, and whenever a new project begins, these
institutionalized processes provide direction and set
expectations
• Tailoring of these processes, however, is allowed in
order to take into account the unique characteristics
of a given software project
• A new KPA introduced at Level 3 is a well-defined
software engineering process that integrates all of the
organization’s software engineering activities
The Defined Level

• Also two new groups appear within Level 3
organizations:
 Training
 Software Engineering Process Group (SEPG)
• The first provides an organization-wide training
program to ensure staff have the requisite skills
• The second facilitates the definition, maintenance, and
improvement of the organization's software
engineering processes
The Defined Level

• The two chief qualities of the software process at this
level are standardization and consistency
• Software planning, management and engineering have
become stable and repeatable
• This stability is based upon an organization-wide
understanding of the activities, roles, and
responsibilities in this defined software engineering
process
The Defined Level

The key process areas for Level 3 focus on establishing
effective software planning, management and
engineering processes across the organization:
 Organizational Process Focus
 Organizational Process Definition
 Process Training Program
 Integrated Software Management
 Software Product Engineering
 Intergroup Coordination
The Defined Level – Key Process Areas

The key process areas for Level 3 focus on establishing
effective software planning, management and
engineering processes across the organization:
 Peer Reviews
The Defined Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole,
only 3 to 7 percent of all software development
The Defined Level – SEI Estimate

• With Level 2 focused on process refinement and Level
3 focused process institutionalization, Level 4 is
focused on process measurement
• That is, moving from Level 3 to Level 4 is concerned
with measuring the effectiveness of the defined process
with the goal of continuous process improvement
• To accomplish this, the organization establishes
quantitative quality goals
The Managed Level

• These quantitative quality goals apply to the software
products, as well as the planning, managerial and
software engineering processes
• Level 4 is the ‘managed’ stage because nearly every
aspect of the software product and process is being
actively managed
• Metrics are collected, organized, and stored in a
organization-wide software process database for
analysis
The Managed Level

The key process areas for Level 4 focus on establishing a
quantitative understanding of the software
engineering process and products created by the
organization:
 Quantitative Process Management
 Software Quality Management
The Managed Level – Key Process Areas

In 2001, SEI estimated that in the industry as a whole,
The Managed Level – SEI Estimate

• The transition from Level 4 to Level 5 is a transition in
which the entire organization now becomes focused on
continuous process improvement
• This level is characterized by an ongoing, continuous
state of operation where the major goal becomes the
prevention of defects
• The organization as a whole consistently strives to
improve the range of its process ability
The Optimizing Level

The key process areas for Level 5 focus on implementing
continuous and measurable software process
improvement:
 Defect Prevention
 Technology Change Management
 Process Change Management
The Optimizing Level – Key Process Areas

• In 2001, SEI estimated that in the industry as a whole,
• The first CMM for Software Level 5 organization was
the United Space Alliance (USA) equally owed by the
Boeing Company and Lockheed Martin Corporation
• USA is currently performing work on the NASA Space
Shuttle and International Space Station Programs and
has a staff of more than 10,000 employees
The Optimizing Level – SEI Estimate

• Over the past two decades, the CMM for Software has
been the predominant tool for assessing and assisting
an organization’s processes improvement efforts
• In fact, its success led to the creation of additional
capability models to support other disciplines
including:
 The Systems Engineering Capability Model
 The Integrated Product Development Capability
Maturity Model
From CMM to CMMI

• While each of these models was well received,
inconsistencies in approach, structure, and
terminology were introduced
• For example, CMM for Software provided a “staged”
approach with its pre-defined maturity levels
• In contrast, the Systems Engineering Capability
Model provided a “continuous” approach that enables
an organization to improve maturity within a single
process area, independent of other process areas
From CMM to CMMI

• As a result, SEI launched the Capability Maturity
Model Integration Project
• Its goal was to reduce the redundancy and complexity
that resulted from the creation of separate, multiple
capability models, particularly within the same
organization
• To reach this goal, SEI set out to integrate the CMMs
and create a product suite designed to improve
efficiency and return on investment
From CMM to CMMI

• The three source models for CMMI include:
 The CMM for Software V2.0 draft C
 The Systems Engineering CM
 The Integrated Product Development CMM v0.98
• Four bodies of knowledge are supported by CMMI:
 Systems Engineering
 Software Engineering
 Integrated Product and Process Development
 Supplier Sourcing
From CMM to CMMI

• Systems engineering covers the development of total
systems, which may or may not include software
• Software engineering covers the development of
software systems
• Integrated product and process development is a
systematic approach intended to achieve a timely
collaboration of relevant stakeholders throughout the
life of the product to satisfy customer’s needs,
expectations, and requirements
From CMM to CMMI
CMMI Bodies of Knowledge or Disciplines

• Supplier sourcing focuses on identifying sourcing best
practices (i.e., enhanced source analysis and the
monitoring of supplier activities) for those projects
that use suppliers to perform functions or add
modifications to products needed by the project
From CMM to CMMI
CMMI Bodies of Knowledge or Disciplines

• In March 2002, CMMI Version 1.1 was released
• For Version 1.1, four combination of disciplines are
available:
 CMMI-SW – covers software engineering
 CMMI-SE/SW – covers both systems engineering
and software engineering
 CMMI-SE/SW/IPPD – adds Integrated Product
and Process Development
 CMMI-SE/SW/IPPD/SS – adds Supplier Sourcing
Capability Maturity Model Integration Version 1.1
From CMM to CMMI

• Both a continuous and a staged representation of the
CMMI V1.1 are available
• The continuous representation offers a flexible
approach to process improvement by enabling an
organization to focus on specific process areas for
improvement and/or to improve process areas to
different capability levels (i.e., CL1 – CL5)
• Capability levels are used to measure the improvement
path from unperformed to an optimizing process area
Continuous Representation
Representations
Continuous and Staged

To this end, six capability levels have been defined for the
continuous representation:
• Capability Level 0: Incomplete
• Capability Level 1: Performed
• Capability Level 2: Managed
• Capability Level 3: Defined
• Capability Level 4: Quantitatively Managed
• Capability Level 5: Optimizing
Continuous Representation – Capability Levels
Representations

Capability Level 0: Incomplete
An incomplete process is a process that is either not performed or
partially performed
Capability Level 1: Performed
A performed process is a process that satisfies the specific goals
of the process area
Capability Level 2: Managed
A managed process is a Capability Level 1 process that has the
basic infrastructure in place to support the process
Representations

Capability Level 3: Defined
A defined process is a Capability Level 2 process that is tailored
according to guidelines and contributes to the organization’s
process assets (e.g., work products, measures, etc.)
Capability Level 4: Quantitatively Managed
A quantitatively managed process is a Capability Level 3 process
that is controlled using statistical and other quantitative
techniques
Representations

Capability Level 5: Optimizing
An optimizing process is a Capability Level 4 process that is
improved based on an understanding of the common causes of
variation inherent in the process itself
Representations

Process Area 1Process Area 2 Process Area 3
Specific Goals Generic Goals
Specific
Practices
Structure of the Continuous
Representation
Generic
Practices
Capability Levels
Chrissis, M., Konrad, M., and Shrum, S. (2003) CMMI Guidelines for Process Integration and Product Improvement. Addison-Wesley.

• In contrast to the continuous representation, the
staged representation offers a systematic, structured
approach to process improvement
• Like CMM for Software, it defines five distinct levels
of process maturity each of which lays the foundation
for the next stage
• Associated with each maturity level are a set of
predefined process areas that improve the
organization’s overall process performance
Staged Representation
Representations

The five maturity levels, named similarly to the five
CMM for Software maturity levels, include:
• Maturity Level 1: Initial
• Maturity Level 2: Managed
• Maturity Level 3: Defined
• Maturity Level 4: Quantitatively Managed
• Maturity Level 5: Optimizing
(Note that maturity levels 2 – 5 are named exactly the same as
capability levels 2 – 5)
Staged Representation – Maturity Levels
Representations

Maturity Level 1: Initial
At maturity level 1, processes are usually ad hoc and chaotic and
the required supporting infrastructure is not in place
Maturity Level 2: Managed
At maturity level 2, the organization’s projects have ensured that
requirements are managed and that processes are planned,
performed, measured, and controlled
Representations

Maturity Level 3: Defined
At maturity level 3, processes are well characterized and
understood by the organization, and are supported by an
infrastructure that includes standards, procedures, tools, and
methods; a project may tailor a process according to guidelines
Maturity Level 4: Quantitatively Managed
At maturity level 4, the organization and projects establish
quantitative objectives for quality and process performance and
use them as criteria in managing processes; quality and process
performance are understood in statistical terms
Representations

Maturity Level 5: Optimizing
At maturity level 5, an organization continually improves its
processes based on a quantitative understanding of the common
causes of variation inherent in the process itself
Representations

Maturity Levels
Process Area 1 Process Area 2 Process Area 3
Ability
To Perform
Directing
Implementation
Commitment
To Perform
Verifying
ImplementationSpecific
Practices
Generic
Practices
Structure of the Staged
Representation

Comparing the Representations
Level
Continuous Representation
Capability Levels
Staged Representation
Maturity Levels
Level 0 Incomplete N/A
Level 1 Performed Initial
Level 2 Managed Managed
Level 3 Defined Defined
Level 4 Quantitatively Managed Quantitatively Managed
Level 5 Optimizing Optimizing
Representations

• CMMI V1.1 has defined 25 process areas
 22 process areas are common to all the disciplines
(i.e., CMMI-SE/SW/IPPD/SS)
 Two process areas are specific to Integrated
Product and Process Development
 One process area is specific to Supplier Sourcing
• These process areas are the fundamental
organizational feature of all the CMMI models
CMMI Process Areas
Understanding CMMI

• A process area is a set of related practices, which
when performed collectively, satisfy a set of goals
considered important in making significant process
improvements in a given area
• Relationships exist between process areas and some
have been classified as Fundamental and others
Progressive
• Note that the 25 defined process areas are common to
both the staged and continuous representations
CMMI Process Areas
Understanding CMMI

CMMI’s 25 process areas can be grouped into one of the
following four categories:
• Process Management
• Project Management
• Engineering
• Support
CMMI Process Areas
Understanding CMMI

Process Management process areas contain cross-
project activities related to defining, planning,
deploying, implementing, monitoring, controlling,
appraising, measuring and improving processes
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Organizational Process Performance
• Organizational Innovation and Deployment
Process Management Process Areas
Understanding CMMI

Process Management Process Areas
Understanding CMMI
Process Area Purpose
Organizational
Process Focus
To plan and implement organizational process improvement based on a thorough
understanding of the current strengths and weaknesses of the organization’s processes
and process assets
Organizational
Process Definition
To establish and maintain a usable set of organizational process assets (e.g., policies,
process descriptions, support tools, etc.)
Organizational
Training
To develop the skills and knowledge of people so they can perform their roles effectively
and efficiently
Organizational
Process
Performance
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
Organizational
Innovation and
Deployment
To select and deploy incremental and innovative improvements that measurably improve
the organization’s processes and technologies. The improvements support the
organization’s quality and process-performance objectives as derived from the
organization’s business objectives.

Project Management process areas cover the project
management activities related to planning,
monitoring, and controlling a project
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Integrated Project Management
• Risk Management
Project Management Process Areas
Understanding CMMI

Understanding CMMI
Project Planning To establish and maintain plans that define project activities
Project Monitoring
and Control
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
Supplier
Agreement
Management
To manage the acquisition of products from suppliers for which there exists a formal
agreement
Integrated Project
Management
To establish and manage the project and the involvement of relevant stakeholders
according to an integrated and defined process that is tailored from the organization’s
set of standard processes; [IPPD – also to establish a shared vision for the project and a
team structure for integrated teams that will carry out the objectives of the project]
Risk Management
To identify potential problems before they occur so that risk-handling activities can be
planned and invoked as needed across the life of the product or project to mitigate advers
impacts on achieving objectives

Project Management process areas cover the project
management activities related to planning,
monitoring, and controlling a project
Understanding CMMI
• Integrated Teaming (IPPD)
• Integrated Supplier Management (SS)
• Quantitative Project Management

Understanding CMMI
Integrated
Teaming (IPPD) To form and sustain an integrated team for the development of work products
Integrated Supplier
Management (SS)
To proactively identify sources of products that may be used to satisfy the project’s
requirements and to manage selected suppliers while maintaining a cooperative project-
supplier relationship
Quantitative
Project
Management
To quantitatively manage the project’s defined processes to achieve the project’s
established quality and process-performance objectives

Engineering process areas cover the development and
maintenance activities that are shared across
engineering disciplines
• Requirements Definition
• Requirements Management
• Technical Solution
• Product Integration
• Verification
• Validation
Engineering Process Areas
Understanding CMMI

Engineering Process Areas
Understanding CMMI
Requirements
Definition To produce and analyze customer, product, and product-component requirements
Requirements
Management
To manage the requirements of the project’s products and product components and to
identify inconsistencies between those requirements and the project’s plans and work
products
Technical Solution
To design, develop, and implement solutions to requirements; solutions, designs, and
implementation encompass products, product components, and product-related life-cycle
singly or in combination as appropriate
Product
Integration
To assemble the product from the product components, ensure that the product, as
integrated, functions properly, and deliver the product
Verification To ensure that selected work products meet their specified requirements
Validation
To demonstrate that a product or product component fulfills its intended use when
placed in its intended environment

Support process areas cover the activities that support
product development and maintenance
• Configuration Management
• Process and Product Quality Assurance
• Measurement and Analysis
• Organizational Environment for Integration (IPPD)
• Decision Analysis and Resolution
• Causal Analysis and Resolution
Support Process Areas
Understanding CMMI

Support Process Areas
Understanding CMMI
Configuration
Management
To establish and maintain the integrity of work products using configuration
identification, configuration control, configuration status accounting, and configuration
audits
Process and
Product Quality
Assurance
To provide staff and management with objective insights into processes and associated
work products
Measurement and
Analysis
To develop and sustain a measurement capability that is used to support management
information needs
Organization
Environment for
Integration (IPPD)
To provide an Integrated Product and Process Development infrastructure and manage
people for integration
Decision Analysis
and Resolution
To analyze possible decisions using a formal evaluation process that evaluates identified
alternatives against established criteria
Causal Analysis
and Resolution
To identify causes of defects and other problems and take action to prevent them from
occurring in the future

• Process areas are comprised of components
• These components have been grouped into one of the
following three categories:
 Required Model Components
 Expected Model Components
 Informative Model Components
CMMI Process Area Components
Understanding CMMI

• Required components describe what an organization
must achieve to satisfy a process area
• The required components in CMMI are the specific
and generic goals
• Goal satisfaction is used in appraisals as the basis for
deciding if a process area has been achieved
• For example: Configuration Management SG1 –
Baselines of identified work products are established
CMMI Process Area – Required Model Components
Understanding CMMI

• Expected components describe what an organization
will typically implement to achieve a specific or
generic goal
• Expected components include the specific and generic
practices
• Before a goal can be considered satisfied, practices as
described in CMMI or alternatives must be in place
• For example: SP 1.1-1 Identify Configuration Items
CMMI Process Area – Expected Model Components
Understanding CMMI

Informative components provide details that help
organizations get started in thinking about how to
approach the required and expected components
• Subpractices
• Typical Work Products
• Discipline Amplifications
• Generic Practice Elaborations
• Goal and Practice Titles
• Goal and Practice Notes
CMMI Process Area – Informative Model Components
Understanding CMMI

Informative components provide details that help
organizations get started in thinking about how to
approach the required and expected components
• References
CMMI Process Area – Informative Model Components
Understanding CMMI

CMMI Model
Components
Process Area
Purpose
Statement
Introductory
Notes
Related
Process Areas
Specific
Practices
Generic
Practices
Typical Work
Products
Subpractices
Generic Practice
Elaborations
Required
Expected
Informative

• Each process area consists of one or more specific
goals and one or more generic goals, depending upon
the representation (i.e., Staged or Continuous)
• Specific goals describe the unique characteristics that
must be present to satisfy a process area (e.g., Manage
Requirements)
• Specific goals are supported by specific practices that
describe activities that should result in the
achievement of a process area’s specific goals
Understanding CMMI
CMMI Process Areas – Specific and Generic Goals

Understanding CMMI
Requirements Management – Specific Goal and Practices
SG 1 Manage Requirements
SP 1.1-1 Obtain an Understanding of Requirements
SP 1.2-2 Obtain Commitment to Requirements
SP 1.3-1 Management Requirements Changes
SP 1.4-2 Maintain Bidirectional Traceability of Requirements
SP 1.5-1
Identify Inconsistencies between Project Work and
Requirements

• Generic goals are called “generic” because the same
goal statement appears in multiple process areas
• A generic goal describes the characteristic that must
be present to institutionalize the processes that
implement a process area
• Within CMMI, “institutionalization” is an important
concept that speaks to whether the process have been
ingrained within the way the organization performs
work; ingrained implies consistency across projects
Understanding CMMI

GG 1 Achieve Specific Goals
The process supports and enables the achievement of the specific
goals of the process area by transforming identifiable input work
products to produce identifiable output work products
GG2 Institutionalize a Managed Process
The process is institutionalized as a managed process
GG3 Institutionalize a Defined Process
The process is institutionalized as a defined process
Understanding CMMI
CMMI’s Generic Goals

GG 4 Institutionalize a Quantitatively Managed Process
The process is institutionalized as a quantitatively managed
process
GG5 Institutionalize an Optimizing Process
The process is institutionalized as an optimizing process
Understanding CMMI
CMMI’s Generic Goals

• Generic goals are supported by generic practices that
describe activities that are considered important in
achieving the associated generic goal
• Generic practices are organized by the following four
common features:
 Ability to Perform (AB)
 Commitment to Perform (CP)
 Directing Implementation (DI)
 Verifying Implementation (VI)
Understanding CMMI

Ability to Perform
Groups the generic practices related to ensuring that the process
is ready for execution
Commitment to Perform
Groups the generic practices related to creating policies and
securing sponsorship
Direction Implementation
Groups the generic practices related to managing the
performance of the practice
Understanding CMMI
CMMI’s Generic Practices’ Common Features

Verifying Implementation
Groups the generic practices related to review by higher level
management and objective evaluation of conformance to process
descriptions, procedures, and standards
Understanding CMMI
CMMI’s Generic Practices’ Common Features

• All five generic goals and practices are used in the
continuous representation
• The target capability level will determine the specific
goals and practices that apply to a specific process
area
• In the staged representation, only generic goals 2 and
3 are used because not all process areas will be raised
above a defined process
Understanding CMMI

Understanding CMMI
Generic Goals 1 and 2 and Associated Generic Practices
GG 1 Achieve Specific Goals
GP 1.1 Perform Base Practices
GG 2 Institutionalize a Managed Process
GP 2.1 Establish an Organizational Policy (CP)
GP 2.2 Plan the Process (AP)
GP 2.3 Provide Resources (AP)
GP 2.4 Assign Responsibility (AP)
GP 2.5 Train People (AP)
GP 2.6 Manage Configurations (DI)
GP 2.7 Identify and Involve Relevant Stakeholders (DI)
GP 2.8 Monitor and Control the Process (DI)
GP 2.9 Objectively Evaluate Adherence (VI)
GP 2.10 Review Status with Higher Level Management (VI)

• In the staged representation, the process areas are
organized by the five maturity levels identified earlier
• Advancing through the maturity levels means
achieving control at the project level first followed by
the organizational level until the goal of continual
process improvement has been realized
• In general, as an organization matures, predictability
of project success increases and risk decreases
Understanding CMMI
CMMI’s Staged Representation

1. Initial
2. Managed
3. Defined
4. Quantitatively
Managed
5. Optimizing
• Project-Level Focus
• Processes Characterized as
Reactive
• Organization-Level Focus
• Processes Characterized as Proactive
Processes Measured and Controlled
Focus on Continuous Process
Improvement
• Processes Unpredictable
• Poorly Controlled
• Ad Hoc and Chaotic
Understanding CMMI

Understanding CMMI
Maturity Level 2: Managed
Process Area Category
Project Monitoring and Control Project Management
Project Planning Project Management
Supplier Agreement Management Project Management
Requirements Management Engineering
Configuration Management Support
Measurement and Analysis Support
Process and Product Quality Assurance Support

Understanding CMMI
Organizational Process Definition Process Management
Organizational Process Focus Process Management
Organizational Training Process Management
Integrated Project Management Project Management
Integrated Supplier Management (SS) Project Management
Integrated Teaming (IPPD) Project Management
Risk Management Project Management

Understanding CMMI
Product Integration Engineering
Requirements Development Engineering
Technical Solution Engineering
Validation Engineering
Verification Engineering
Decision Analysis and Resolution Support
Organizational Environment for Integration Support

Understanding CMMI
Maturity Level 4: Quantitatively Managed
Organizational Process Performance Process Management
Quantitative Project Management Project Management

Understanding CMMI
Maturity Level 5: Optimizing
Organizational Innovation and Deployment Process Management
Causal Analysis and Resolution Support

• For additional information on CMMI V1.1, please
visit the SEI’s Web Site at:
http://www.sei.cmu.edu/cmmi/cmmi.html
• Portable Document Format (PDF) editions of both the
staged and continuous representations are available
for downloading
Wrap Up
For Additional Information

• To hasten the transition from SW-CMM to CMMI
V1.1, SEI has stopped updating the SW-CMM
• It also plans to discontinue training for SW-CMM by
the end of 2003
• Because CMMI is consistent with modern software
engineering best practices, the IBM Rational Software
Corporation has endorsed CMMI V1.1
Wrap Up
For Additional Information

• Watts S. Humphrey (1989). Managing the Software
Process. Addison-Wesley Publishing Company, Inc.
• Mark Paulk, et al. (1993). Capability Maturity Model for
Software, Version 1.1. A Software Engineering Institute
Technical Report.
• Mark Paulk, et al. (1995). The Capability Maturity
Model: Guidelines for Improving the Software Process.
Addison Wesley Longman, Inc.
• James R. Persse (2001). Implementing the Capability
Maturity Model. John Wiley & Sons, Inc.
Resources

• CMMI Project Team (2002). Capability Maturity Model
Integration (CMMI) Version 1.1. Software Engineering
Institute.
• Ahren, Dennis, Clouse, Aaron, and Turner, Richard
(2003). CMMI Distilled 2nd
Edition: A Practical
Introduction to Integrated Process Improvement.
Addison-Wesley Publishing Company, Inc.
• Chrissis, Mary Beth, Konrad, Mike, and Shrum,
Sandy. (2003). CMMI Guidelines for Process
Integration and Product Improvement. Addison-Wesley
Publishing Company, Inc.
Resources

• Reaching CMM Levels 2 and 3 with the Rational Unified
Process. An IBM Rational Software Corporation
White Paper.
• Rolf W. Reitzig, Carlo Rodriguez, and Gary Holt
(2002). Achieving Capability Maturity Model Level 2
with the Rational Unified Process. An IBM Rational
Software Corporation White Paper.
• Walker Royce (2002). CMM vs CMMI: From
Conventional to Modern Software Management. An
IBM Rational Software Corporation Article printed in
the Rational Edge. www.therationaledge.com/
Resources

• Rolf W. Reitzig (2003). Using Rational Software
Solutions to Achieve CMMI Level 2. An IBM Rational
Software Corporation Article printed in the Rational
Edge.
Resources

TSU CMM CMMI

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to TSU CMM CMMI

Similar to TSU CMM CMMI (20)

More from Terry Startzel, MS, PMP, SCPM, CSM

More from Terry Startzel, MS, PMP, SCPM, CSM (8)

TSU CMM CMMI