Rectangle 27 0

What is CMMI?

CMM Integration project was formed to sort out the problem of using multiple CMMs. CMMI product team's mission was to combine three Source Models into a single improvement framework for the organizations pursuing enterprise-wide process improvement. These three Source Models are:

  • Capability Maturity Model for Software (SW-CMM) - v2.0 Draft C.
  • Electronic Industries Alliance Interim Standard (EIA/IS) - 731 Systems Engineering.
  • Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98.

CMM Integration:

  • Builds an initial set of integrated models.
  • Improves best practices from source models based on lessons learned.
  • Establishes a framework to enable integration of future models.
Rectangle 27 0

Supplier Sourcing

As work efforts become more complex, project managers 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. Under these circumstances, the supplier sourcing discipline covers the acquisition of products from suppliers.

Similar to IPPD best practices, supplier sourcing best practices must be selected in conjunction with best practices used to produce products.

Rectangle 27 0

SEI CMMI - Representations

The CMMI is structured as follows:

  • Maturity Levels (staged representation) or Capability Levels (continuous representation)
  • Process Areas
  • Goals: Generic and Specific
  • Common Features
  • Practices: Generic and Specific

This chapter will discuss about two CMMI representations and rest of the subjects will be covered in subsequent chapters.

A representation allows an organization to pursue different improvement objectives. An organization can go for one of the following two improvement paths.

Rectangle 27 0

CMMI Staged Structure

Following picture illustrates CMMI Staged Model Structure.

Rectangle 27 0

CMMI Staged Representation Maturity Levels

The following image shows the maturity levels in a CMMI staged representation.

Now we will learn the details about each maturity level. Next section will list down all the process areas related to these maturity levels.

Rectangle 27 0

Common Features

The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting. The five common features are listed below:

The practices in the common feature Activities Performed describe what must be implemented to establish a process capability. The other practices, taken as a whole, form the basis by which an organization can institutionalize the practices described in the Activities Performed common feature.

Rectangle 27 0

What is Maturity?

Definitions vary but mature processes are generally thought to be:

  • Well-defined,
  • Repeatable,
  • Measured,
  • Analyzed,
  • Improved, and
  • Effective.

Poor but mature processes are just as bad as no maturity at all!

CMM helps to solve the maturity problem by defining a set of practices and providing a general framework for improving them. The focus of CMM is on identifying key process areas and the exemplary practices that may comprise a disciplined software process.

Rectangle 27 0

Difference between CMM and CMMI

CMM is a reference model of matured practices in a specified discipline like Systems Engineering CMM, Software CMM, People CMM, Software Acquisition CMM etc., but they were difficult to integrate as and when needed.

CMMI is the successor of the CMM and evolved as a more matured set of guidelines and was built combining the best components of individual disciplines of CMM(Software CMM, People CMM, etc.). It can be applied to product manufacturing, people management, software development, etc.

CMM describes about the software engineering alone where as CMM Integrated describes both software and system engineering. CMMI also incorporates the Integrated Process and Product Development and the supplier sourcing.

Rectangle 27 0

Software Engineering

Software engineering covers the development of software systems. Software engineers focus on the application of systematic, disciplined, and quantifiable approaches to the development, operation, and maintenance of software.

Rectangle 27 0

CMMI Discipline Selection

Selecting a discipline may be a difficult step and depends on what an organization wants to improve.

We will discuss different areas related to CMMI implementation in subsequent chapters.

Rectangle 27 0

Continuous vs Staged Representations

Continuous RepresentationStaged Representation
Process areas are organized by process area categories.Process areas are organized by maturity levels.
Improvement is measured using capability levels. Capability levels measure the maturity of a particular process across an organization; it ranges from 0 through 5.Improvement is measured using maturity levels. Maturity levels measure the maturity of a set of processes across an organization: it ranges from 1 through 5.
There are two types of specific practices: base and advanced. All specific practices appear in the continuous representation.There is only one type of specific practice. The concepts of base and advanced practices are not used. All specific practices appear in the staged representation except when a related base-advanced pair of practices appears in the continuous representation, in which case only the advanced practice appears in the staged representation.
Capability levels are used to organize the generic practices.Common features are used to organize generic practices.
All generic practices are included in each process area.Only the level 2 and level 3 generic practices are included.
Equivalent staging allows determination of a maturity level from an organization's achievement profile.There is no need for an equivalence mechanism to back the continuous representation because each organization can choose what to improve and how much to improve using the staged representation.
Rectangle 27 0

SEI CMMI - Maturity Levels

A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.

CMMI models with staged representation, have five maturity levels designated by the numbers 1 through 5. They are:

  • Initial
  • Managed
  • Defined
  • Quantitatively Managed
  • Optimizing
Rectangle 27 0

Maturity Level 2 Managed

At maturity level 2, an organization has achieved all the specific and generic goals of the maturity level 2 process areas. In other words, the projects of the organization have ensured that requirements are managed and that processes are planned, performed, measured, and controlled.

The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

At maturity level 2, requirements, processes, work products, and services are managed. The status of the work products and the delivery of services are visible to management at defined points.

Commitments are established among relevant stakeholders and are revised as needed. Work products are reviewed with stakeholders and are controlled.

The work products and services satisfy their specified requirements, standards, and objectives.

Rectangle 27 0

Maturity Level 3 Defined

At maturity level 3, an organization has achieved all the specific and generic goals of the process areas assigned to maturity levels 2 and 3.

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods.

A critical distinction between maturity level 2 and maturity level 3 is the scope of standards, process descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project).

At maturity level 3, the standards, process descriptions, and procedures for a project are tailored from the organization's set of standard processes to suit a particular project or organizational unit. The organization's set of standard processes includes the processes addressed at maturity level 2 and maturity level 3. As a result, the processes that are performed across the organization are consistent except for the differences allowed by the tailoring guidelines.

Another critical distinction is that at maturity level 3, processes are typically described in more detail and more rigorously than at maturity level 2. At maturity level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process, its work products, and its services.

Rectangle 27 0

Capability Level 0: Incomplete

An "incomplete process" is a process that is either not performed or partially performed. One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.

This is tantamount to Maturity Level 1 in the staged representation.

Rectangle 27 0

Capability Level 2: Managed

A managed process is planned, performed, monitored, and controlled for individual projects, groups, or stand-alone processes to achieve a given purpose. Managing the process achieves both the model objectives for the process as well as other objectives, such as cost, schedule, and quality. As the title of this level indicates, you are actively managing the way things are done in your organization. You have some metrics that are consistently collected and applied to your management approach.

Note : metrics are collected and used at all levels of the CMMI, in both the staged and continuous representations. It is a bitter fallacy to think that an organization can wait until Capability Level 4 to use the metrics.

Rectangle 27 0

Generic Goals and Practices

Generic goals and practices are a part of every process area.

NOTATIONS : GG --> Generic Goals and GP --> Generic Practice

GG 1 Achieve Specific Goals

  • GP 1.1 Perform Specific Practices

GG 2 Institutionalize a Managed Process

  • GP 2.1 Establish an Organizational Policy
  • GP 2.2 Plan the Process
  • GP 2.3 Provide Resources
  • GP 2.4 Assign Responsibility
  • GP 2.5 Train People
  • GP 2.6 Manage Configurations
  • GP 2.7 Identify and Involve Relevant Stakeholders
  • GP 2.8 Monitor and Control the Process
  • GP 2.9 Objectively Evaluate Adherence
  • GP 2.10 Review Status with Higher Level Management

GG 3 Institutionalize a Defined Process

  • GP 3.1 Establish a Defined Process
  • GP 3.2 Collect Improvement Information

GG 4 Institutionalize a Quantitatively Managed Process

  • GP 4.1 Establish Quantitative Objectives for the Process
  • GP 4.2 Stabilize Sub process Performance

GG 5 Institutionalize an Optimizing Process

  • GP 5.1 Ensure Continuous Process Improvement
  • GP 5.2 Correct Root Causes of Problems
Rectangle 27 0

Process Areas in Detail

The CMMI contains 22 process areas indicating the aspects of product development that are to be covered by company processes.

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.

  • SP 1.1 Select Defect Data for Analysis
  • SP 1.2 Analyze Causes
  • SP 2.1 Implement the Action Proposals
  • SP 2.2 Evaluate the Effect of Changes
  • SP 2.3 Record Data

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.

  • SP 1.1 Identify Configuration Items
  • SP 1.2 Establish a Configuration Management System
  • SP 1.3 Create or Release Baselines
  • SP 2.1 Track Change Requests
  • SP 2.2 Control Configuration Items
  • SP 3.1 Establish Configuration Management Records
  • SP 3.2 Perform Configuration Audits

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.

  • 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

The purpose of Integrated Project Management + IPPD (IPM) is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization's set of standard processes.

  • SP 1.2 Use Organizational Process Assets for Planning Project Activities
  • SP 1.3 Establish the Project's Work Environment
  • SP 1.4 Integrate Plans
  • SP 1.5 Manage the Project Using the Integrated Plans
  • SP 1.6 Contribute to the Organizational Process Assets
  • SP 2.1 Manage Stakeholder Involvement
  • SP 2.2 Manage Dependencies
  • SP 2.3 Resolve Coordination Issues
  • SP 3.1 Establish the Project's Shared Vision
  • SP 3.2 Establish the Integrated Team Structure
  • SP 3.3 Allocate Requirements to Integrated Teams
  • SP 3.4 Establish Integrated Teams
  • SP 3.5 Ensure Collaboration among Interfacing Teams

The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.

  • 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
  • SP 2.1 Collect Measurement Data
  • SP 2.2 Analyze Measurement Data
  • SP 2.3 Store Data and Results
  • SP 2.4 Communicate Results
  • SP 1.1 Collect and Analyze Improvement Proposals
  • SP 1.2 Identify and Analyze Innovations
  • SP 1.3 Pilot Improvements
  • SP 1.4 Select Improvements for Deployment
  • SP 2.1 Plan the Deployment areas
  • SP 2.2 Manage the Deployment
  • SP 2.3 Measure Improvement Effects
  • SP 1.1 Establish Standard Processes
  • SP 1.2 Establish Life-Cycle Model Descriptions
  • SP 1.3 Establish Tailoring Criteria and Guidelines
  • SP 1.4 Establish the Organization's Measurement Repository
  • SP 1.5 Establish the Organization's Process Asset Library

IPPD Addition:

  • SP 2.1 Establish Empowerment Mechanisms
  • SP 2.2 Establish Rules and Guidelines for Integrated Teams
  • SP 2.3 Balance Team and Home Organization Responsibilities
  • SP 1.1 Establish Organizational Process Needs
  • SP 1.2 Appraise the Organization's Processes
  • SP 1.3 Identify the Organization's Process Improvements
  • SP 2.1 Establish Process Action Plans
  • SP 2.2 Implement Process Action Plans
  • SP 3.1 Deploy Organizational Process Assets
  • SP 3.2 Deploy Standard Processes
  • SP 3.3 Monitor Implementation
  • SP 3.4 Incorporate Process-Related Experiences into the Organizational Process Assets
  • 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
  • It is a Process Management process area at Maturity Level 3.

The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently.

  • SP 1.1 Establish the Strategic Training Needs
  • SP 1.2 Determine Which Training Needs Are the Responsibility of the Organization
  • SP 1.3 Establish an Organizational Training Tactical Plan
  • SP 1.4 Establish Training Capability
  • SP 2.1 Deliver Training
  • SP 2.2 Establish Training Records
  • SP 2.3 Assess Training Effectiveness

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.

  • SP 1.1 Determine Integration Sequence
  • SP 1.2 Establish the Product Integration Environment
  • SP 1.3 Establish Product Integration Procedures and Criteria
  • SP 2.1 Review Interface Descriptions for Completeness
  • SP 2.2 Manage Interfaces
  • 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

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.

  • SP 1.1 Monitor Project Planning Parameters
  • SP 1.2 Monitor Commitments
  • SP 1.3 Monitor Project Risks
  • SP 1.4 Monitor Data Management
  • SP 1.5 Monitor Stakeholder Involvement
  • SP 1.6 Conduct Progress Reviews
  • SP 1.7 Conduct Milestone Reviews
  • SP 2.1 Analyze Issues
  • SP 2.2 Take Corrective Action
  • SP 2.3 Manage Corrective Action

The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

  • 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 Life Cycle
  • SP 1.4 Determine Estimates of Effort and Cost
  • 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
  • SP 3.1 Review Plans that Affect the Project
  • SP 3.2 Reconcile Work and Resource Levels
  • SP 3.3 Obtain Plan Commitment
  • It is a support process area at Maturity Level 2.

The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

  • SP 1.1 Objectively Evaluate Processes
  • SP 1.2 Objectively Evaluate Work Products and Services
  • SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues
  • SP 2.2 Establish Records

The purpose of the Quantitative Project Management (QPM) process area is to quantitatively manage the project's defined process to achieve the project's established quality and process-performance objectives.

  • SP 1.1 Establish the Project's Objectives
  • SP 1.2 Compose the Defined Processes
  • SP 1.3 Select the Sub-processes that Will Be Statistically Managed
  • SP 1.4 Manage Project Performance
  • SP 2.1 Select Measures and Analytic Techniques
  • SP 2.2 Apply Statistical Methods to Understand Variation
  • SP 2.3 Monitor Performance of the Selected Sub-processes
  • SP 2.4 Record Statistical Management Data

The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product-component requirements.

  • SP 1.1 Elicit Needs
  • SP 1.2 Develop the Customer Requirements
  • SP 2.1 Establish Product and Product-Component Requirements
  • SP 2.2 Allocate Product-Component Requirements
  • SP 2.3 Identify Interface 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

The purpose of Requirements Management (REQM) is 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.

  • SP 1.1 Obtain an Understanding of Requirements
  • SP 1.2 Obtain Commitment to Requirements
  • SP 1.3 Manage Requirements Changes
  • SP 1.4 Maintain Bidirectional Traceability of Requirements
  • SP 1.5 Identify Inconsistencies between Project Work and Requirements

The purpose of Risk Management (RSKM) is 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 adverse impacts on achieving objectives.

  • SP 1.1 Determine Risk Sources and Categories
  • SP 1.2 Define Risk Parameters
  • SP 1.3 Establish a Risk Management Strategy
  • SP 2.1 Identify Risks
  • SP 2.2 Evaluate, Categorize, and Prioritize Risks
  • SP 3.1 Develop Risk Mitigation Plans
  • SP 3.2 Implement Risk Mitigation Plans
  • It is a Project Management process area at Maturity Level 2.

The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers for which there exists a formal agreement.

  • SP 1.1 Determine Acquisition Type
  • SP 1.2 Select Suppliers
  • SP 1.3 Establish Supplier Agreements
  • SP 2.1 Execute the Supplier Agreement
  • SP 2.2 Monitor Selected Supplier Processes
  • SP 2.3 Evaluate Selected Supplier Work Products
  • SP 2.4 Accept the Acquired Product
  • SP 2.5 Transition Products

The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related life-cycle processes either single or in combination as appropriate.

  • SP 1.1 Develop Alternative Solutions and Selection Criteria
  • SP 1.2 Select Product Component Solutions
  • SP 2.1 Design the Product or Product Component
  • SP 2.2 Establish a Technical Data Package
  • SP 2.3 Design Interfaces Using Criteria
  • SP 2.4 Perform Make, Buy, or Reuse Analysis
  • SP 3.1 Implement the Design
  • SP 3.2 Develop Product Support Documentation

The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.

  • SP 1.1 Select Products for Validation
  • SP 1.2 Establish the Validation Environment
  • SP 1.3 Establish Validation Procedures and Criteria
  • SP 2.1 Perform Validation
  • SP 2.2 Analyze Validation Results.
  • It is an Engineering process area at Maturity Level 3.


The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Specific Practices by Goal

  • SP 1.1 Select Work Products for Verification
  • SP 1.2 Establish the Verification Environment
  • SP 1.3 Establish Verification Procedures and Criteria
  • SP 2.1 Prepare for Peer Reviews
  • SP 2.2 Conduct Peer Reviews
  • SP 2.3 Analyze Peer Review Data
  • SP 3.1 Perform Verification
  • SP 3.2 Analyze Verification Results
Rectangle 27 0

Changes Made into Version 1.2

Only those changes that are made to the set of Process Areas are considered here. For a comprehensive detail, visit the SEI homepage.

  • Organizational Environment for Integration (OEI)
  • Integrated Teaming (IT)
  • Integrated Supplier Management (ISM)
  • IPM . SG3 and SG4 were eliminated, new SG3 was added (all IPPD PAs)
  • OPD . SG was added, turning it in an IPPD PA
  • OPF . two SPs were extracted from SG and created SG3 together with two new SPs
  • REQD . SP3.5 was renamed Validate Requirements
  • SAM . SP2.1 was eliminated, two new SPs added in SG2
  • TS . SP1.2 was eliminated
  • VER . SP3.2 was renamed Analyze Verification Results
Rectangle 27 0

4 - Understanding SEI CMMI

SEI CMMI is a process improvement approach that provides organizations with the essential elements of effective processes.