2008-12-16 à 19:56:54
CMMI Introduction
This article offers a high level
view of the maturity levels of CMMI, broken down into
specific goals and specific practices. The 5 levels of CMMI
are described: from 1 (initial) to 5 (optimizing). This article
is primary a set of preliminary notes on the subject. However,
we felt it useful to publish it in its current state given the
numerous questions we receive on the CMMI subject.
For each and every level, there are a number of areas to
work on: these are called KPA.
Generic Goals and Generic Practices apply to all
levels and to each KPA.
On top of Generic Goal and Generic
Practices some Specific Goals (SG) and Specific
Practices (SP) do
apply to each KPA.
The Generic Goal and Generic Practices are not
repeated for each level, each KPA. Instead, they're listed only once.
Generic Goals and Generic Practices
Generic Goals and Process Names
| Generic Goal |
Progression of Processes |
| GG 1 | Performed process |
| GG 2 | Managed process |
| GG 3 | Defined process |
| GG 4 | Quantitatively managed process |
| GG 5 | Optimizing process |
CMMI Maturity Levels
- Initial
- Managed: software development is managed and controlled. Best practices are documented.
- Requirements Management (REQM)
- Manage Requirements
Requirements are managed and inconsistencies with
project plans are identified.
The project maintains a current
and approved set of requirements over the life of the project by
doing the following:
- Managing all changes to the requirements
- Maintaining the relationships among the requirements,
the project plans, and the work products
- Identifying inconsistencies among the requirements,
the project plans, and the work products
- Taking corrective action


- Obtain an Understanding of Requirements
As the project
matures and requirements are
derived, all activities or
disciplines will receive
requirements. To avoid requirements
creep, criteria are established to
designate appropriate channels, or
official sources, from which to
receive requirements. The receiving
activities conduct analyses of the
requirements with the requirements
provider to ensure that a
compatible, shared understanding is
reached on the meaning of the
requirements. The result of this
analysis and dialog is an agreed-to
set of requirements.
- Obtain Commitment to Requirements
This specific
practice deals with agreements and
commitments among those who have to
carry out the activities necessary
to implement the requirements.
Requirements evolve throughout the
project, especially as described by
the specific practices of the
Requirements Development process
area and the Technical Solution
process area. As the requirements
evolve, this specific practice
ensures that project participants
commit to the current, approved
requirements and the resulting
changes in project plans,
activities, and work
products.
- Manage Requirements Changes
During the
project, requirements change for a
variety of reasons. As needs change
and as work proceeds, additional
requirements are derived and changes
may have to be made to the existing
requirements. It is essential to
manage these additions and changes
efficiently and effectively. To
effectively analyze the impact of
the changes, it is necessary that
the source of each requirement is
known and the rationale for any
change is documented. The project
manager may, however, want to track
appropriate measures of requirements
volatility to judge whether new or
revised controls are
necessary.
- Maintain Bidirectional Traceability
The intent
of this specific practice is to
maintain the bidirectional
traceability of requirements for
each level of product decomposition.
(See the definition of
«bidirectional traceability» in the
glossary.) When the requirements are
managed well, traceability can be
established from the source
requirement to its lower level
requirements and from the lower
level requirements back to their
source. Such bidirectional
traceability helps determine that
all source requirements have been
completely addressed and that all
lower level requirements can be
traced to a valid source.
Requirements traceability can
also cover the relationships to
other entities such as intermediate
and final work products, changes in
design documentation, and test
plans. The traceability can cover
horizontal relationships, such as
across interfaces, as well as
vertical relationships. Traceability
is particularly needed in conducting
the impact assessment of
requirements changes on the
project's activities and work
products.
- Identify Inconsistencies Between Project Work and Requirements
This specific
practice finds the inconsistencies
between the requirements and the
project plans and work products and
initiates the corrective action to
fix them.
- Project Planning (PP)
- Establish Estimates
- Establish the Scope of the Project
- Establish Estimates of Work Products and Tasks Attributes
- Define project Lifecycle
- Determine Estimates of Effort and Cost
- Develop a Project Plan
- Establish the Budget and the Schedule
- Identify Project Risks
- Plan for Data Management
- Plan for Project Resources
- Plan for Needed Knowledge and Skills
- Plan Stakeholder Involvement
- Establish the project Plan
- Obtain Commitment to the Plan
- Review Plans That Affect the Project
- Reconcile Work and resource Levels
- Obtain Plan Commitment
- Project Monitoring and Control (PMC)
- Monitor Project Against Plan
- Monitor Project Planning Parameters
- Monitor Commitments
- Monitor Project Risks
- Monitor Data Management
- Monitor Stakeholder Involvement
- Conduct Progress Reviews
- Conduct Milestone Reviews
- Manage Corrective Action to Closure
- Analyze Issues
- Take Corrective Action
- Manage Corrective Action
- Process and Product Quality Assurance (PPQA)
- Objectively Evaluate Processes and Work Products
- Objectively Evaluate Processes
- Objectively Evaluate Work Products and Services
- Provide Objective Insight
- Communicate and Ensure Resolution of Noncompliance Issues
- Establish Records
- Configuration Management (CM)
- Establish Baselines
Baselines of identified work products are established.
Specific practices to establish
baselines are covered by this specific goal.
The specific practices under the Track and
Control Changes specific goal serve to
maintain the baselines. The specific
practices of the Establish Integrity
specific goal document and audit the
integrity of the baselines.
- Identify Configuration Items
Identify the configuration items, components,
and related work products that will be placed under configuration
management
- Establish a Configuration Management System
Baselines of identified work
products are established
- Create or Release Baselines
Create or release baselines
for internal use and for delivery to the customer
- Track and Control Changes
Changes to the work
products under configuration management are
tracked and controlled.
The specific practices under this
specific goal serve to maintain the
baselines after they are established by
the specific practices under the
Establish Baselines specific
goal.
- Track Change Requests
Track change requests for the
configuration items.
- Control Configuration Items
Control changes to the configuration items.
Control is maintained over the configuration
of the work product baseline. This control
includes tracking the configuration of each of the
configuration items, approving a new configuration
if necessary, and updating the baseline.
- Establish Integrity
Integrity of baselines
is established and maintained.
The integrity of the baselines,
established by processes associated with
the Establish Baselines specific goal,
and maintained by processes associated
with the Track and Control Changes
specific goal, is provided by the
specific practices under this specific
goal.
- Establish Configuration Management Records
Establish and maintain records
describing configuration items.
- Perform Configuration Audits
Perform configuration audits to
maintain integrity of the configuration baselines.
Configuration audits confirm that the resulting
baselines and documentation conform to a specified
standard or requirement. Audit results should be
recorded as appropriate.
- Supplier Agreement Management (SAM)
- Establish Supplier Agreements
- Determine Acquisition Type
- Select Suppliers
- Establish Supplier Agreements
- Satisfy Supplier Agreements
- Execute the Supplier Agreement
- Monitor Selected Supplier Processes
- Evaluate Selected Supplier Work Products
- Accept the Acquired Product
- Transition Products
- Measurement and Analysis (MA)
- Align Measurement and Analysis Activities
- Establish Measurement Objectives
- Specify Measures
- Specify Data Collection and Storage Procedures
- Specify Analysis Procedures
- Provide Measurement Results
- Collect Measurement Data
- Analyze Measurement Data
- Store Data and Results
- Communicate Results
- Defined: best practices are generalized to the whole organization and applied to all projects.
- Risk Management (RSKM)
- Prepare for Risk Management
Preparation for risk management is conducted:
Preparation is conducted by establishing and maintaining a strategy for
identifying, analyzing, and mitigating risks. This is typically documented
in a risk management plan. The risk management strategy addresses
the specific actions and management approach used to apply and
control the risk management program. This includes identifying the
sources of risk; the scheme used to categorize risks; and the
parameters used to evaluate, bound, and control risks for effective
handling.
- Determine Risk Source and Categories
- Define Risk Parameters
- Establish a Risk Management Strategy
- Identify and Analyze Risks
Risks are identified and analyzed to determine their relative importance:
The degree of risk impacts the resources assigned to handle an
identified risk and the determination of when appropriate
management attention is required.
Analyzing risks entails identifying risks from the internal
and external sources identified and then evaluating each
identified risk to determine its likelihood and consequences.
Categorization of the risk, based on an evaluation against
the established risk categories and criteria developed for
the risk management strategy, provides the information
needed for risk handling. Related risks may be grouped for efficient
handling and effective use of risk management resources.
- Identify Risks
- Evaluate, Categorize and Prioritize Risks
- Mitigate Risks
Evaluate and categorize each identified risk using the defined
risk categories and parameters, and determine its relative priority:
The evaluation of risks is needed to assign relative importance to each
identified risk, and is used in determining when appropriate
management attention is required. Often it is useful to aggregate risks
based on their interrelationships, and develop options at an aggregate
level. When an aggregate risk is formed by a roll up of lower level risks,
care must be taken to ensure that important lower level risks are not
ignored.
Collectively, the activities of risk evaluation, categorization, and
prioritization are sometimes called «risk assessment» or
«risk analysis.»
- Develop Risk Mitigation Plans
- Implement Risk Mitigation Plans
- Technical Solution (TS)
- Product Integration (PI)
- Verification (VER)
- Validation (VAL)
- Requirements Development (RD)
- Develop Customer Requirements
Stakeholders needs, expectations, constraints,
and interfaces are collected and translated into customer
requirements.
The needs of stakeholders (e.g.,
customers, end users, suppliers, builders,
testers, manufacturers, and logistics
support personnel) are the basis for
determining customer requirements. The
stakeholder needs, expectations,
constraints, interfaces, operational
concepts, and product concepts are analyzed,
harmonized, refined, and elaborated for
translation into a set of customer
requirements.
Frequently, stakeholder needs,
expectations, constraints, and interfaces
are poorly identified or conflicting. Since
stakeholder needs, expectations,
constraints, and limitations should be
clearly identified and understood, an
iterative process is used throughout the
life of the project to accomplish this
objective. To facilitate the required
interaction, a surrogate for the end user or
customer is frequently involved to represent
their needs and help resolve conflicts. The
customer relations or marketing part of the
organization as well as members of the
development team from disciplines such as
human engineering or support can be used as
surrogates. Environmental, legal, and other
constraints should be considered when
creating and resolving the set of customer
requirements.
- Elicit Needs
- Develop the Customer Requirements
- Develop Product Requirements
Customer requirements are refined and elaborated
to develop product and product component requirements.
Customer requirements are analyzed
in conjunction with the development of the
operational concept to derive more detailed
and precise sets of requirements called
«product and product component
requirements.» Product and product component
requirements address the needs associated
with each product lifecycle phase. Derived
requirements arise from constraints,
consideration of issues implied but not
explicitly stated in the customer
requirements baseline, and factors
introduced by the selected architecture, the
design, and the developer’s unique business
considerations. The requirements are
reexamined with each successive, lower level
set of requirements and functional
architecture, and the preferred product
concept is refined.
The requirements are allocated to product
functions and product components including
objects, people, and processes. The
traceability of requirements to functions,
objects, tests, issues, or other entities is
documented. The allocated requirements and
functions are the basis for the synthesis of
the technical solution. As internal
components are developed, additional
interfaces are defined and interface
requirements are established.
- Establish Product and Product Component Requirements
- Allocate Product Component Requirements
- Identify Interface Requirements
- Analyze and Validate Requirements
The requirements are analized and validated,
and a definition of required functionality is developed.
The specific practices of the
Analyze and Validate Requirements specific
goal support the development of the
requirements in both the Develop Customer
Requirements specific goal and the Develop
Product Requirements specific goal. The
specific practices associated with this
specific goal cover analyzing and validating
the requirements with respect to the user’s
intended environment.
Analyses are performed to determine what
impact the intended operational environment
will have on the ability to satisfy the
stakeholders’ needs, expectations,
constraints, and interfaces. Considerations,
such as feasibility, mission needs, cost
constraints, potential market size, and
acquisition strategy, must all be taken into
account, depending on the product context. A
definition of required functionality is also
established. All specified usage modes for
the product are considered, and a timeline
analysis is generated for timecritical
sequencing of functions.
The objectives of the analyses are to
determine candidate requirements for product
concepts that will satisfy stakeholder
needs, expectations, and constraints; and
then to translate these concepts into
requirements. In parallel with this
activity, the parameters that will be used
to evaluate the effectiveness of the product
are determined based on customer input and
the preliminary product concept.
Requirements are validated to increase
the probability that the resulting product
will perform as intended in the use
environment.
- Establish Operational Concepts and Scenarios
- Establish a Definition of Required Functionality
- Analyze Requirements
- Analyze Requirements to Achieve Balance
- Validate Requirements
- Integrated Project Management + IPPD (IPM)
- Decisional Analysis and Resolution (DAR)
- Organizational Training (OT)
- Organizational Process Definition + IPPD (OPD)
- Organizational Focus (OPF)
- Quantatively Managed
- Organizational Process Performance(OPP)
- Establish Performance Baselines and Models
Baselines and
models, which characterize the expected
process performance of the
organization's set of standard
processes, are established and
maintained.
Prior to establishing process-
performance baselines and models, it
is necessary to determine which
processes are suitable to be
measured (the Select Processes
specific practice), which measures
are useful for determining process
performance (the Establish Process-
Performance Measures specific
practice), and the quality and
process-performance objectives for
those processes (the Establish
Quality and Process- Performance
Objectives specific practice). These
specific practices are often
interrelated and may need to be
performed concurrently to select the
appropriate processes, measures, and
quality and processperformance
objectives. Often, the selection of
one process, measure, or objective
will constrain the selection of the
others. For example, if a certain
process is selected, the measures
and objectives for that process may
be constrained by the process
itself.
- Select Processes
- Establish Process-Performance Measures
- Establish Quality and Process-Performance Objectives
- Establish Process-Performance Baselines
- Establish Process-Performance Models
- Quantitative Project Management (QPM)
- Quantitatively Manage the Project
- Establish the Project’s Objectives
- Compose the Defined Process
- Select the Subprocesses that Will Be Statistically Managed
- Manage Project Performance
- Statistically Manage Subprocess Performance
- Select Measures and Analytic Techniques
- Apply Statistical Methods to Understand Variation
- Monitor Performance of the Selected Subprocesses
- Record Statistical Management Data
- Optimizing
- Causal Analysis and Resolution (CAR)
- Select Improvements
- Collect and Analyze Improvement Proposals
- Identify and Analyze Innovations
- Pilot Improvements
- Select Improvements for Deployment
- Deploy Improvements
- Plan the Deployment
- Manage the Deployment
- Measure Improvement Effects
Glossary
Glossary
| Acronym |
Domain |
Description |
| Ac | CMM | Activities Performed (common feature) |
| Ca | CMM | Abilities to perform (common feature) |
| CAR | CMMI | Causal Analysis and Resolution |
| CCB | CMMI | Configuration Control Board |
| CI | CMMI | Configuration Item |
| CM | CMMI | Configuration Management |
| CMP | AMS | Configuration Management Plan |
| DAR | CMMI | Decision Analysis and Resolution |
| En | CMM | Engagement to perform (common feature) |
| IPM | CMMI | Integration project Management |
| IPPD | CMMI | Integrated Product and Process Development |
| LMS | AMS | Library Management System |
| MA | CMMI | Measurement and Analysis |
| Me | CMM | Measurement and analysis (common feature) |
| OID | CMMI | Organizational Innovation and Deployment |
| OPD | CMMI | Organizational Process Definition |
| OPF | CMMI | Organizational Process Focus |
| OPP | CMMI | Organizational Process Performance |
| OT | CMMI | Organizational Training |
| PCB | AMS | Project Control Book |
| PCR | AMS | Project Change Request |
| PI | CMMI | Product Integration |
| PMC | CMMI | Project Monitoring and Control |
| PMP | AMS | Project Management Plan |
| PP | CMMI | Project Planning |
| PPQA | CMMI | Process and Product Quality Assurance |
| QPM | CMM | Quantitative Process Management |
| QPM | CMMI | Quantitative Project Management |
| RD | CMMI | Requirements Development |
| REQM | CMMI | Requirements Management |
| RM | CMM | Requirements Management |
| RSQM | CMMI | Risk Management |
| SAM | CMMI | Supplier Agreement Management |
| SCE | CMM | Suppliers Capability Evaluation |
| SCM | CMM | Software Configuration Management |
| SEPG | CMM | Software Engineering Process Group |
| SPA | CMM | Software Process Assessment |
| SPE | CMM | Software Process Engineering |
| SPI | CMM | Software Process Improvement |
| SPP | CMM | Software Project Planning |
| SQA | CMM | Software Quality Assurance |
| SQM | CMM | Software Quality Management |
| SSM | CMM | Software Subcontract Management |
| TCM | CMMI | Technology Change Management |
| TP | CMM | Training Program |
| TS | CMMI | technical Solution |
| VAL | CMMI | Validation |
| Ve | CMM | Verifying implementation (common feature) |
| VER | CMMI | Verification |