Objectifs de nos articles

Nos articles visent à partager avec nos lecteurs les méthodes et les pratiques que Lato Sensu Management applique tous les jours à la conduite des projets dans les secteurs bancaire, des télécoms et de la pharmacie. Ils ambitionnent également de susciter le dialogue et l'échange d'idées.

Lorsqu'un article est affublé de l'avertissement « à paraître » cela indique qu'il n'est pas disponible ou qu'il n'est pas encore finalisé.

2008-12-13 à 13:23:33

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 1Performed process
GG 2Managed process
GG 3Defined process
GG 4Quantitatively managed process
GG 5Optimizing process

CMMI Maturity Levels

  1. Initial
  2. Managed: software development is managed and controlled. Best practices are documented.
    1. Requirements Management (REQM)
      1. 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

        Separation between Requirements Development and Requirements Management

        Several types of requirements

        1. 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.
        2. 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.
        3. 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.
        4. 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.

        5. 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.
    2. Project Planning (PP)
      1. Establish Estimates
        1. Establish the Scope of the Project
        2. Establish Estimates of Work Products and Tasks Attributes
        3. Define project Lifecycle
        4. Determine Estimates of Effort and Cost
      2. Develop a Project Plan
        1. Establish the Budget and the Schedule
        2. Identify Project Risks
        3. Plan for Data Management
        4. Plan for Project Resources
        5. Plan for Needed Knowledge and Skills
        6. Plan Stakeholder Involvement
        7. Establish the project Plan
      3. Obtain Commitment to the Plan
        1. Review Plans That Affect the Project
        2. Reconcile Work and resource Levels
        3. Obtain Plan Commitment
    3. Project Monitoring and Control (PMC)
      1. Monitor Project Against Plan
        1. Monitor Project Planning Parameters
        2. Monitor Commitments
        3. Monitor Project Risks
        4. Monitor Data Management
        5. Monitor Stakeholder Involvement
        6. Conduct Progress Reviews
        7. Conduct Milestone Reviews
      2. Manage Corrective Action to Closure
        1. Analyze Issues
        2. Take Corrective Action
        3. Manage Corrective Action
    4. Process and Product Quality Assurance (PPQA)
      1. Objectively Evaluate Processes and Work Products
        1. Objectively Evaluate Processes
        2. Objectively Evaluate Work Products and Services
      2. Provide Objective Insight
        1. Communicate and Ensure Resolution of Noncompliance Issues
        2. Establish Records
    5. Configuration Management (CM)
      1. 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.
        1. Identify Configuration Items Identify the configuration items, components, and related work products that will be placed under configuration management
        2. Establish a Configuration Management System Baselines of identified work products are established
        3. Create or Release Baselines Create or release baselines for internal use and for delivery to the customer
      2. 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.
        1. Track Change Requests Track change requests for the configuration items.
        2. 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.
      3. 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.
        1. Establish Configuration Management Records Establish and maintain records describing configuration items.
        2. 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.
    6. Supplier Agreement Management (SAM)
      1. Establish Supplier Agreements
        1. Determine Acquisition Type
        2. Select Suppliers
        3. Establish Supplier Agreements
      2. Satisfy Supplier Agreements
        1. Execute the Supplier Agreement
        2. Monitor Selected Supplier Processes
        3. Evaluate Selected Supplier Work Products
        4. Accept the Acquired Product
        5. Transition Products
    7. Measurement and Analysis (MA)
      1. Align Measurement and Analysis Activities
        1. Establish Measurement Objectives
        2. Specify Measures
        3. Specify Data Collection and Storage Procedures
        4. Specify Analysis Procedures
      2. Provide Measurement Results
        1. Collect Measurement Data
        2. Analyze Measurement Data
        3. Store Data and Results
        4. Communicate Results
  3. Defined: best practices are generalized to the whole organization and applied to all projects.
    1. Risk Management (RSKM)
      1. 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.
        1. Determine Risk Source and Categories
        2. Define Risk Parameters
        3. Establish a Risk Management Strategy
      2. 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.

        1. Identify Risks
        2. Evaluate, Categorize and Prioritize Risks
      3. 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.»

        1. Develop Risk Mitigation Plans
        2. Implement Risk Mitigation Plans
    2. Technical Solution (TS)
    3. Product Integration (PI)
    4. Verification (VER)
    5. Validation (VAL)
    6. Requirements Development (RD)
      1. 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.

        1. Elicit Needs
        2. Develop the Customer Requirements
      2. 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.

        1. Establish Product and Product Component Requirements
        2. Allocate Product Component Requirements
        3. Identify Interface Requirements
      3. 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.

        1. Establish Operational Concepts and Scenarios
        2. Establish a Definition of Required Functionality
        3. Analyze Requirements
        4. Analyze Requirements to Achieve Balance
        5. Validate Requirements
    7. Integrated Project Management + IPPD (IPM)
    8. Decisional Analysis and Resolution (DAR)
    9. Organizational Training (OT)
    10. Organizational Process Definition + IPPD (OPD)
    11. Organizational Focus (OPF)
  4. Quantatively Managed
    1. Organizational Process Performance(OPP)
      1. 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.
        1. Select Processes
        2. Establish Process-Performance Measures
        3. Establish Quality and Process-Performance Objectives
        4. Establish Process-Performance Baselines
        5. Establish Process-Performance Models
    2. Quantitative Project Management (QPM)
      1. Quantitatively Manage the Project
        1. Establish the Project’s Objectives
        2. Compose the Defined Process
        3. Select the Subprocesses that Will Be Statistically Managed
        4. Manage Project Performance
      1. Statistically Manage Subprocess Performance
        1. Select Measures and Analytic Techniques
        2. Apply Statistical Methods to Understand Variation
        3. Monitor Performance of the Selected Subprocesses
        4. Record Statistical Management Data
  5. Optimizing
    1. Causal Analysis and Resolution (CAR)
      1. Select Improvements
        1. Collect and Analyze Improvement Proposals
        2. Identify and Analyze Innovations
        3. Pilot Improvements
        4. Select Improvements for Deployment
      2. Deploy Improvements
        1. Plan the Deployment
        2. Manage the Deployment
        3. Measure Improvement Effects

Glossary

Glossary
Acronym Domain Description
Ac CMM Activities Performed (common feature)
Ca CMM Abilities to perform (common feature)
CAR CMMICausal Analysis and Resolution
CCB CMMIConfiguration Control Board
CI CMMIConfiguration Item
CM CMMIConfiguration Management
CMP AMS Configuration Management Plan
DAR CMMIDecision Analysis and Resolution
En CMM Engagement to perform (common feature)
IPM CMMIIntegration project Management
IPPDCMMIIntegrated Product and Process Development
LMS AMS Library Management System
MA CMMIMeasurement and Analysis
Me CMM Measurement and analysis (common feature)
OID CMMIOrganizational Innovation and Deployment
OPD CMMIOrganizational Process Definition
OPF CMMIOrganizational Process Focus
OPP CMMIOrganizational Process Performance
OT CMMIOrganizational Training
PCB AMS Project Control Book
PCR AMS Project Change Request
PI CMMIProduct Integration
PMC CMMIProject Monitoring and Control
PMP AMS Project Management Plan
PP CMMIProject Planning
PPQACMMIProcess and Product Quality Assurance
QPM CMM Quantitative Process Management
QPM CMMIQuantitative Project Management
RD CMMIRequirements Development
REQMCMMIRequirements Management
RM CMM Requirements Management
RSQMCMMIRisk Management
SAM CMMISupplier Agreement Management
SCE CMM Suppliers Capability Evaluation
SCM CMM Software Configuration Management
SEPGCMM 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 CMMITechnology Change Management
TP CMM Training Program
TS CMMItechnical Solution
VAL CMMIValidation
Ve CMM Verifying implementation (common feature)
VER CMMIVerification