CMMI-Dev V1.3 Training

(1)

Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213

CMMI

®

_{Version 1.3 Model}

Upgrade Training

® CMMI and Carnegie Mellon are registered in the US Patent and Trademark Office by Carnegie Mellon University. For more information on CMU/SEI Trademark use, please visit

http://www.sei.cmu.edu/legal/marks/index.cfm

CMMI Version 1.3 Model Upgrade Training November 2010

This material is distributed by the SEI only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. Government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. Government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

(2)

Purpose

The purpose of this training is to help you to do the following:

• understand the changes and improvements made in CMMI V1.3

• successfully make the transition from CMMI V1.2 to CMMI V1.3 of the CMMI Product Suite

• satisfy a requirement for the following:

– to participate in a SCAMPISMHigh Maturity appraisal using CMMI model

V1.3

– to attend further CMMI V1.3 training courses

– to become a CMMI-DEV V1.3 or CMMI-ACQ V1.3 instructor

– to become a V1.3 SCAMPI Lead AppraiserSMor a V1.3 SCAMPI Lead

AppraiserSM

Materials

To successfully complete this on-line training, it would be useful to follow along and see the actual changes in the models.

Copies of all three models are available on the SEI website at http://www.sei.cmu.edu/cmmi/tools/cmmiv1-3/.

Comparison documents are also available at the website that show the redline changes between V1.2 and V1.3. We recommend that you familiarize yourself with the comparison documents and refer to them when you are completing this training.

Also many acronyms are used throughout these materials. If you are not familiar with an acronym, please refer to the acronym list in Appendix B in the model documents.

(3)

Course Objectives

The objectives of this training course are to enable you to

• understand the differences between CMMI V1.2 and V1.3 – General changes

– Process area changes – High maturity changes

Depicting Changes

In these materials, strikethroughs will be used to indicate deletions (strikethrough); red font without strikethroughs to indicate insertions (red font).

(4)

Modules in this Training

Module 1: Introduction

Module 2: General Model Changes

Module 3: A Quick Look at V1.3 PA Changes Module 4: Core and Shared PA Changes1

Module 5: CMMI-ACQ Specific PA Changes Module 6: CMMI-DEV Specific PA Changes Module 7: CMMI-SVC Specific PA Changes Module 8: High Maturity PA Changes

1 _{The core and shared PAs covered in this module do not include the}

high maturity core and shared PAs.

CMMI Revision Process

The CMMI Steering Group provided a long-term strategy and the upgrade criteria for V1.3.

The Product Development Team (PDT) reviewed change requests to identify possible changes to the product suite.

Configuration Control Boards (CCBs) determined which changes would be accepted.

The PDT developed draft versions of the model, training, and appraisal method materials.

Model piloting was conducted November 2009 through July 2010; training piloting was conducted August through September 2010; and

(5)

Tips for Using These Materials

Obtain a copy of the V1.3 models.

Review all material.

Follow along in the model as you work through the material to get a full understanding of the changes.

Work at your own pace. Take as much time as you need to review the material.

Completion Criteria

Successful completion of CMMI V1.3 Model Upgrade Training requires that you complete the following:

• Open and review all modules

• Complete the confirmation at the end of the course that shows that you have reviewed and understand the material

(6)

Summary

This training provides you with material to help you understand the differences between CMMI V1.2 and CMMI V1.3.

If you have any questions about upgrade training, please send email to [email protected]

CMMI

®

_{Version 1.3 Model}

(7)

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. Government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. Government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

Purpose

The purpose of this module is to describe the general changes to the CMMI models (ACQ, DEV, SVC) for Version 1.3. These changes usually affect more than one place in the model and are often times these changes are discussed further in later modules of this training.

(8)

Topics

CMMI Framework Terminology Updating Model Architecture Harmonizing V1.2 Models Glossary

Teaming Concepts The Term “Project”

Process Related Experiences Providing “Appropriate” Phrasing in Practice Statements

Generic Practices

Lifecycle Needs and Standards

Addressing Agile

Causal Analysis at Lower Levels of Maturity

Customer Satisfaction Modernizing Development Practices

Prioritized Customer Requirements Organization Level Contracts Easing Translation

Front Matter

(9)

CMMI Framework Related Terminology

₁

The Problem

CMMI terminology evolved and wasn’t always consistent with the release of new constellations.

Overview of Solution

• With the expansion of CMMI to address Acquisition and Services in V1.2, the terminology used to describe CMMI models was formalized and improved. Updates to the glossary include the following:

CMMI Framework

The basic structure that organizes CMMI components, including common

elements of thecurrent CMMI models as well as rules and methods for

generating models, appraisal methods (including associated artifacts), and training materials. (See also “CMMI model” and “CMMI Product Suite.”)

The framework enables new disciplines areas of interest to be added to CMMI so that the new disciplines they will integrate with the existing ones.[from Glossary]

CMMI Framework Related Terminology

₂

constellation

A collection of CMMI components that are used to construct models, training materials, and appraisal related documents for an area of interest (e.g., acquisition, development, services).[from Glossary]

• In the Front Matter, but not in the Glossary, you will find three terms that are new to DEV V1.2:

CMMI Model Foundation or CMF (first introduced in ACQ V1.2)

. . . model components common to all CMMI models and constellations. [from Preface]

To allow the use of multiple models within the CMMI Framework, model components are classified as either common to all CMMI models or applicable to a specific model. The common material is called the “CMMI Model Foundation” or “CMF.”

Those components are combined with material applicable to an area of interest (e.g., acquisition, development, services) to produce a model. [from section 1 Introduction]

(10)

CMMI Framework Related Terminology

₃

Core PAs

A core process area is a process area that is common to all CMMI models.

[from section 1 Introduction]

All CMMI models contain 16 core process areas. These process areas cover basic concepts that are fundamental to process improvement in any area of interest (i.e., acquisition, development, services). Some of the material in the core process areas is the same in all constellations. Other material may be adjusted to address a specific area of interest. Consequently, the material in the core process areas may not be exactly the same.. [from section 2 Process Area Components]

Shared PAs (There is only one shared PA [SAM].)

A shared PA is shared by at least two CMMI models, but not all of them.[from section 1 Introduction]

(11)

Updating Model Architecture

₁

The Overall Problem

Model components of the CMMI architecture are identified and described in Chapter 2, Process Area Components, and Chapter 3, Tying It All Together.

Some model components have not fulfilled the purpose for which they were intended.

Updating Model Architecture

₂

Problems with Model Component Descriptions

Some model component descriptions in V1.2 were inconsistent with the glossary and with their assignment as required, expected, or informative.

• Revised the model component descriptions (If defined in the glossary, the redundant text in the description was minimized, inconsistent text was eliminated, and a reference to the glossary was added.)

• Removed any text that made the component inconsistent with its assignment as a required, expected, or informative model component

Example

Generic Practice Elaborations

A gGeneric practice elaborationsappear after a generic practice in a process

area practicesto provide guidance on how the generic practices should can be

applied uniquely to theprocess area areas. A generic practice elaboration is an informative model component.(See the definition of “generic practice

(12)

Updating Model Architecture

₃

Problems with Typical Work Products

Though an informative model component, typical work products sometimes have been given too much importance (e.g., used as a checklist in appraisals).

• Renamed “typical work product” to “example work product”

• Reviewed typical work product lists to ensure that individually they are recognizable and collectively they are sufficiently broad in scope • In ACQ, renamed “typical supplier deliverable” to “example supplier

deliverable”

• Revised the glossary definition to eliminate the following sentence: These examples are called typical work products because there are often other work products that are just as effective but are not listed.

Updating Model Architecture

₄

Problems with Representations

In the front matter, the staged representation was described as “proven” while the continuous was not.

The CMMI front matter implies there are advantages or benefits inherent in using the staged representation and maturity levels that are not likewise attributed to the continuous representation and capability profiles, including predicting performance, comparing organizations, and improving processes.

• Introduced continuous and staged representation concepts agnostically with more balance in the front matter

• Reduced the amount of model material that discusses the representations and their differences, thereby deemphasizing the importance of representations in

(13)

Updating Model Architecture

₅

Problems with Amplifications

In DEV there were about 20 amplifications for SE, SW, and HW. (There were none in ACQ or SVC.) As a concept, “amplifications” was never well developed in CMMI and users found it confusing.

• Removed the “amplification” model component

• Converted amplifications having value into examples or notes

Updating Model Architecture

₆

Problems with References

References often were not helpful. It was confusing when a reference said, “Refer to the <destination PA> for more information about xyz,” when xyz was not found in the PA the reference pointed to.

• Revised references so that users can easily find the information that the reference points to by searching for a goal or practice title or purpose statement in the destination PA

• Introduced a standard sequence to references when there are multiple adjacent references

– Constellation-unique PAs appear first

– Within each PA reference grouping, the references are listed alphabetically by the destination PA

(14)

Updating Model Architecture

₇

Problems with PA Categories

PA categories were used inconsistently across the constellations.

Solutions for ACQ

• Renamed the “Acquisition” PA category to be “Acquisition Engineering” • Moved AM and SSAD from the Acquisition PA category to the Project

Management PA category

Solution for DEV

• Moved REQM from the Engineering PA category to the Project Management PA category

Solution for SVC

• Renamed the “Project Management” PA category to be “Project and Work Management”

(15)

Harmonizing V1.2 Models

The Problem

As V1.2 models were created and released, they became out of synch with one another. Improvements made in one model were not made in others simply because of differences in release schedules.

Analyzed differences among the three models (ACQ, DEV, SVC) to identify opportunities to improve commonality

Examples of improvements include the following:

• GGs, GPs, and GP elaborations consolidated into one location (DEV) • Improved measurement, supplier, and agreement terminology (DEV) • Improved definitions of terms related to products and services (DEV, ACQ) • Increased emphasis on customer satisfaction (all three)

• Improved examples, example work products, and notes (all three) Many of the changes made to the model are due to harmonization and are covered in the PA Changes modules of the upgrade training.

(16)

Glossary

₁

The Problem

Some definitions of terms in the glossary had the following problems:

• They were not consistent with how the same terms were described in other parts of the model (e.g., expected CMMI components, functional

configuration audit, higher level management, version control).

• They did not accurately reflect their relationships with other terms in the glossary (e.g., process, process element, subprocess).

• They were not consistent with ISO standard definitions (e.g. quality, process, subprocess).

• They were incorrect or misleading (e.g., base measure, development, end user, natural bounds, process performance baseline, process performance model, quantitative objective).

• It wasn’t clear that part of the glossary entry was the definition of the term and part was usage notes.

Glossary

₂

• For terms that were inconsistently described, changed the glossary definition, changed the description in another part of the model, or replaced a description with a reference to the glossary

• Ensured that related terms had consistent definitions where possible • Updated glossary definitions for some terms to be more consistent with ISO

standard definitions

• Corrected errors and improved the clarity of some definitions

• Established three distinct parts for glossary entries that have different formats, which allows their easy identification:

1. The term 2. The definition

(17)

Glossary

₃

Example – Definition Inconsistent with Other Model Material Chapter 2

Generic Practice Elaborations

A genericGenericpracticeelaboration appearselaborations appear aftera

genericpractice in a process areapracticesto provide guidance on how the generic practiceshouldcanbe applied uniquely to theprocessareaareas. A generic practice elaboration is an informative model component. (See the definition of “generic practice elaboration” in the glossary.)

Glossary

generic practice elaboration

An informative model component that appears after a generic practice to provide guidance on how the generic practice shouldcouldbe applied uniquelytotheaprocess area. (This model component is not present in all CMMI models.)

Glossary

₄

Two-part definition from DEV V1.2 Three-part definition from DEV V1.3

product baseline

In configuration management, the initial approved technical data package (including, for software, the source code listing) defining a configuration item during the production, operation, maintenance, and logistic support of its lifecycle. (See also “configuration item” and “configuration management.”)

product baseline

The initial approved technical data package defining a configuration item during the production, operation, maintenance, and logistic support of its lifecycle. (See also “configuration item,” “configuration

management,” and “technical data package.”) This term is related to configuration management. Example – Three-Part Glossary Entries

(18)

Glossary

₅

Example – Definition Inconsistent with ISO Glossary

quality

The degree to which ability of a set of inherent characteristics fufillsof a product, product component, or process to fulfill requirements. of customers.

Glossary

₆

Example – Definition Inconsistent with Intent Glossary

establish and maintain

Create,document, use, and revise. . . as necessary to ensure it remains they remain useful.

The phrase “establish and maintain” means more than a combination of its component

terms;. . . plays a special role in communicating a deeper principle in CMMI: work products

that have a central or key role in work group, project, and organizational performance should be given attention to ensure they are used and useful in that role.

This phrase has particular significance in CMMI because it often appears in goal and practice statements . . . and should be taken as shorthand for applying the principle to whatever work product is the object of the phrase.

(19)

Teaming Concepts

₁

The Problem

Teams are clearly relevant to product development. How teams are established in an organization has a lot to do with whether or not they are successful. However, there are no specific practices addressing rules for establishing and operating teams in DEV, instead there is the Integrated Product and Process Development (IPPD) addition, which is optional. Fewer than 5% of recent appraisals have included IPPD.

For the acquisition of complex systems, integrated teaming is not an option but a necessity. Thus, ACQ has, instead of an addition for IPPD, expected material that covers integrated teaming derived from generalizing and simplifying the IPPD material from DEV.

SVC adopted the ACQ approach, but in many service contexts “integrated teams” were not the key differentiator for success and the concept also proved to be problematic in some contexts.

(20)

Teaming Concepts

₂

• Replaced the concepts of integrated teaming and IPPD with a more general concept of teaming, thereby eliminating the IPPD addition and making the approach to teaming consistent in all three models (By making the three constellations common, teaming can be part of the CMF.)

• Replaced the glossary definition of “integrated team” with a definition of “team” • In the glossary definition, placed emphasis on what enables superior team

performance:

A team establishes and maintains a process that identifies roles,

responsibilities, and interfaces; is sufficiently precise to enable the team to measure, manage, and improve their work performance; and enables the team to make and defend their commitments.

Teaming Concepts

₃

ACQ SVC

IWM SP 1.6 Establish Teams

Establish and maintain integratedteams. IPM SP 1.6

Establish Teams

Establish and maintain integratedteams. Example

IPPD Addition

Integrated processes that emphasize parallel rather than serial development are a cornerstone of IPPD implementation. The processes for developing the product and for developing product-related lifecycle processes, such as the manufacturing process . . .

(21)

The Term “Project”

₁

The Problem

In V1.2 models, the word “project” was used in all three CMMI models, especially in the core process areas. “Project” was almost implicitly understood by product developers and acquirers.

However, service providers found it difficult to interpret goals and practices containing the word, often misinterpreted the models practices, and sometimes believed that model content containing the word “project” did not apply to them. Although some users (probably familiar with development environments) could adjust, others had great difficulty and asked many questions.

(22)

The Term “Project”

₂

• Kept the word “project” in the DEV and ACQ models, but replaced it with alternate terms in the SVC model (Depending on its implied meaning, the word “project” was generally either (1) simply removed, (2) replaced with the word “work,” or (3) replaced with the phrase “work group.”)

• Changed process area names in SVC (e.g., Project Planning becomes Work Planning) (The process area category Project Management also became Project and Work Management.)

• Considered material to be CMF since the only difference from the other models is the replacement of the word “project”

• Added terms and revised definitions in the glossary that use the word “project” to ensure that the glossary more broadly fit all CMMI models

The Term “Project”

₃

Example – Glossary Definitions Revised glossary definition

process asset library

A collection of process asset holdings that can be used by an organization or, project., or work group. (See also “organization’s process asset library.”)

Added glossary definition

work plan

A plan of activities and related resource allocations for a work group. Work planning includes estimating the attributes of work products and tasks, determining the resources needed, negotiating commitments, producing a schedule, and identifying and analyzing risks. Iterating through these activities can be necessary to establish the work plan.

(23)

The Term “Project”

₄

Project Planning (ACQ & DEV)

Purpose: The purpose of Project

Planning (PP) is to establish and maintain plans that define project activities.

SG 2 Develop a Project Plan

A project plan is established and maintained as the basis for managing the project.

Work Planning (SVC)

Purpose: The purpose of Work

Planning (WP) is to establish and maintain plans that define work activities.

SG 2 Develop a Work Plan

A work plan is established and maintained as the basis for managing the work.

Example – Process Area Content

(24)

Process Related Experiences

The Problem

In multiple places of the V1.2 models, including the definition of “defined

process,” GP 3.2, IPM SP 1.7, and OPF SP 3.4, a compound phrase is used that itemizes types of process related experiences. These phrases are often

inconsistent with each other, creating confusion and problems in appraisals.

Replaced these compound expressions, itemizing types of process related experiences with the simpler phrase “process related experiences”

(OPF) SP 3.4 Incorporate Experiences into Organizational Process Assets

Incorporate process related work products, measures, and

improvement information experiences derived from planning and

performing the process into organizational process assets. . . . Examples of process related experiences include work products, measures, measurement results, lessons learned, and process improvement suggestions. . . . [from GP 3.2 informative material]

Providing “Appropriate”

(25)

Providing “Appropriate” Phrasing in Practice

Statements

₁

The Problem

Certain words and phrases that appear in goal and practice statements unnecessarily complicate their interpretation. Words and phrases that were considered problematic include:

• Appropriate • Best • Designated • Effectively • Essential • Most important • Necessary • Realistic • Reasonable • Relevant

Providing “Appropriate” Phrasing in Practice

Statements

₂

Reworded some goals and practices to no longer use unnecessary words or phrases

Examples

(PPQA) SP 1.1 Objectively Evaluate Processes

Objectively evaluate designated selected performed processes against applicable process descriptions, standards, and procedures.

(PI) SP 3.4 Package and Deliver the Product or Product Component

Package the assembled product or product component and deliver it to the appropriatecustomer.

(IRP) SP 2.2 Analyze IndividualIncident Data

Analyze individualincident data to determine the best a course of action.

(26)

Generic Practices

₁

The Problem

There are inconsistencies among GP descriptions, glossary definitions, associated PAs, and GP elaborations.

There is wording in some GP descriptions (notably GP 2.8 and GP 3.2) that confuse users about the intent of the GP and lead to incorrect interpretation (e.g., a measure for every PA).

(27)

Generic Practices

₂

Solutions

• Revised GG 1 so that it is in the correct “voice” (i.e., passive voice)

GG 1 Achieve Specific Goals

The process supports and enables achievement of the specific goals

of the process area byare supported by the process by transforming identifiable input work products to produceintoidentifiable output work products. [Note: “process of” may be replaced by “process by”]

• Revised the GP 2.6 title to align with the statement and intent of the GP

GP 2.6 Manage ConfigurationsControl Work Products

Place designatedselectedwork products of the process under appropriate levels of control.

• Updated the GP 2.7 description to include examples of relevant stakeholders Examples of stakeholders that might serve as relevant stakeholders for specific tasks, depending on context, include individuals, teams, management,

customers, suppliers, end users, operations and support staff, other projects, and

government regulators. [already in ACQ; added to DEV and SVC]

Generic Practices

₃

• Clarified the GP 2.8 informative material (These clarifications are intended to 1) counter the impression that a measurement is required for every PA and 2) differentiate GP 2.8 and GP 2.10 relative to: a) the frequency of monitoring and controlling and b) the level of management involved.)

Subpractices

1. Measure Evaluate actual progress and performance against the plan for

performing the process.

The measures evaluations are of the process, its work products, and its services.

3. Review activities, status, and results of the process with the immediate level of management responsible for the process and identify issues.

TheThesereviews are intended to provide the immediate level of

management with appropriate visibility into the process. The reviews can be both periodic and event driven based on the day-to-day monitoring and controlling of the process, and are supplemented by periodic and

(28)

Generic Practices

₄

• Expanded the scope of GP 2.9 to align with the expectations set in PPQA GP 2.9 Objectively Evaluate Adherence

Objectively evaluate adherence of the process and selected work products against itstheprocess description, standards, and procedures, and address noncompliance.

The purpose of this generic practice is to provide credible assurance that the process isand selected work products are implemented as planned and adheres adhere to its the process description,

standards, and procedures. This generic practice is implemented, in part, by evaluating selected work products of the process.

Generic Practices

₅

• Revised the GP 2.10, Review Status with Higher Level Management,

informative material to clarify that higher level management can include, but is not required to include senior management

“. . . In particular, higher level management includes can include senior management.”

• Streamlined GP 3.2 and its elaborations with “process related experiences”

GP 3.2 Collect Improvement Information Process Related Experiences

Collect work products, measures, measurement results, and

improvement information process related experiences derived from

planning and performing the process to support the future use and improvement of the organization’s processes and process assets.

(29)

Generic Practices

₆

Examples

Examples of updates to GP elaborations that reflect PA changes (DEV GP 2.3) QPM Elaboration

Special expertise in statistics . . . may be needed to define the analytic

techniques for statistical used in quantitative management . . . however, teams need sufficient expertise to support a basic understanding of their process performance as they perform their daily work.

Examples of other resources provided include the following: . . .

Scripts and tools that assist teams in analyzing their own process performance with minimal need for additional expert assistance

(DEV GP 2.4) TS Elaboration

Appointing a lead or chief architect that oversees the technical solution and has authority over design decisions helps to maintain consistency in product design and evolution.

• Deleted capability levels 4 and 5, generic goals 4 and 5, and all level 4 and 5 generic practices as part of high maturity changes

(30)

Lifecycle Needs and Standards

The Problem

V1.2 models focus on the development lifecycle, but do not mention other lifecycles relevant to CMMI, including manufacturing, deployment, operations, maintenance, support, and disposal.

• Added examples from DEV Part 1 to the SVC model for lifecycles such as manufacturing and maintenance

• In OPF SP 1.1, added an example box that provides examples of standards that could be used to reflect the organization’s process needs and objectives, including lifecycle related standards

• Added standards as entries to the References in the Appendix (e.g., ISO/IEC 15288:2008, ISO/IEC 27001:2005, NDIA Engineering for System Assurance Guidebook)

(31)

Addressing Agile

₁

The Problem

Developers that use Agile methods sometimes resist using CMMI because they can’t see how CMMI practices are applicable to and can improve the

effectiveness of organizations using Agile methods.

Added guidance to appropriate PAs to do the following:

• Help users interpret the practices in a context where Agile methods are used • Reinforce the applicability of the practices in an Agile environment

• Send the message that CMMI is a robust best practice framework meant to be used in Agile environments as well as other development environments

Addressing Agile

₂

• Added a new section to DEV Chapter 5 entitled “Interpreting CMMI When Using Agile Approaches”

– This section describes how CMMI practices can apply in a variety of development environments. It also provides interpretive guidance in selected PAs that explains how the PA can be used in Agile environments. – A reference to this new section appears in the SSD intro notes of SVC. • Added interpretive guidance to the following PAs:

– In DEV: CM, REQM, PP, RD, TS, PI, VER, PPQA, and RSKM – In ACQ: AM, ATM, PMC, and PP

– In SVC: SSD

(32)

Addressing Agile

₃

Example

An example of a note added to DEV is the following one for PP:

In Agile environments . . . Teams plan, monitor, and adjust plans during each iteration as often as it takes (e.g., daily). Commitments to plans are

demonstrated when tasks are assigned and accepted during iteration planning, user stories are elaborated or estimated, and iterations are populated with tasks from a maintained backlog of work. (See “Interpreting CMMI When Using Agile Approaches” in Part I.)

Causal Analysis at Lower Levels

of Maturity

(33)

Causal Analysis at Lower Levels of Maturity

₁

The Problem

The CAR PA was placed at maturity level 5 to support high maturity practices with more sophisticated approaches to understanding selected outcomes, their causes, and possible resolutions by using statistical and other quantitative techniques. However, organizations have found a need to perform causal analysis at lower levels of maturity.

Causal Analysis at Lower Levels of Maturity

₂

• Revised the introductory notes of higher level PAs to acknowledge the value of their SPs in contexts that do not meet the assumptions for high maturity use and provided cautions and limitations for use in other contexts

• Added model content that encourages appropriate use of causal analysis at lower maturity levels

– Added a subpractice in IPM SP 1.5, Manage the Project Using Integrated Plans

5. Address causes of selected issues that can affect project objectives. – Added an SP in QPM

SP 2.3 Perform Root Cause Analysis

(34)

Customer Satisfaction

The Problem

Especially in DEV, customer satisfaction was rarely mentioned in V1.2. All three models have this issue to some degree.

Added informative material, such as customer satisfaction related measures and examples, to the following PAs:

• In ACQ: ARD and OPF

• In DEV: MA, OPF, PMC, and RD • In SVC: MA

(35)

Modernizing Development

Practices

Modernizing Development Practices

₁

The Problem

Much of the engineering content of DEV V1.2 is ten years old.

DEV was a starting point for the other two constellations. Therefore, no V1.2 model adequately addresses “modern” engineering approaches, which are now in more widespread use.

For example, RD SG 3 and RD SP 3.2 both emphasize functionality and not non-functional requirements (SSD SP 1.3 also does too).

Also, Engineering and other PAs rarely mention the following concepts: • Quality attributes (i.e., non functional requirements or “ilities”) • Allocation of product capabilities to release increments • Product lines

• System of systems

• Architecture-centric development practices • Technology maturation

(36)

Modernizing Development Practices

₂

Overview of Solution

• Updated the glossary to include new terms (and modified some old terms), including quality attribute, architecture, and definition of required functionality and quality attributes

• Updated the informative material in all three models (especially RD, REQM, VAL, VER) to bring more balance to functional and quality attribute

requirements (non-functional requirements)

• Made minimal updates to required and expected content (RD SG 3, RD SP 3.2, and SSD)

• Updated the informative material in all three models to address other modern engineering approaches (e.g., product lines)

• Replaced selected uses of the overloaded term “performance” in all three models with another appropriate qualifying phrase

Modernizing Development Practices

₃

Example

Example of a new term that reflects modern engineering, which was added to the glossary in V1.3 models

quality attribute

A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterizable by some appropriate measure.

Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture.

architecture

The set of structures needed to reason about a product. These structures are comprised of elements, relations among them, and properties of both.

(37)

Modernizing Development Practices

₄

Examples of minimal updates to required and expected material and updates to informative material

(RD) SG 3 Analyze and Validate Requirements

The requirements are analyzed and validated, and a definition of required functionality is developed.

. . . A scenario is typically a sequence of events that mightmay occur in the development, use, or sustainment of the product, which is used to make explicit some of the functional or quality attribute needs of the stakeholders. [From first note under SP 3.1 statement]

SP 3.2 Establish a Definition of Required Functionalityand Quality

Attributes Subpractices

1. Determine key mission and business drivers.

Prioritized Customer

Requirements

(38)

Prioritized Customer Requirements

The Problem

Especially in DEV, customer priorities were rarely mentioned in V1.2.

• Made the prioritization of requirements more explicit in RD SP 1.2 and SSD SP 1.1. This change will also result in RD, SSD, and ARD being more in synch (harmonized)

SP 1.2 Develop the Transform Stakeholder Needs into Customer

Requirements

Transform stakeholder needs, expectations, constraints, and interfaces into prioritizedcustomer requirements.

• Added informative material to the following PAs: • In ACQ: PP

• In DEV: OPD, PP, RD • In SVC: PP, SSD

(39)

Organization Level Contracts

The Problem

CMMI V1.2 did not cover organization-level contracts (e.g., using preferred suppliers, task orders).

Added minimal informative material to the following:

• SSAD SP 1.1 Identify Potential Suppliers (ACQ only)

• OPD SP 1.1 Establish Standard Processes (all 3 models)

• SAM SP 1.1 Determine Acquisition Type (DEV and SVC only)

(40)

Easing Translation

₁

The Problem

The models are translated into multiple languages because CMMI has a worldwide user base. However, most of the developers who create and update the models are not familiar with issues encountered in translation and may use idioms (e.g., “one size doesn’t fit all”). Further, because of the large number of developers, the work of multiple authors often means inconsistent use of phrasing (e.g., organizational process assets vs. organization’s process assets) and even some terminology.

Reviewed the V1.3 model drafts to identify terminology and phrasing issues that can create translation problems (The CMMI Translation Team, consisting of members from different countries and representing different languages conducted the review. Many of the problems were consistency problems [e.g., percent vs. percentage] or overloaded terms [e.g., performance].)

Language Status (for DEV V1.2)

Japanese Completed August 2007. Intro course translated October 2007

Chinese (trad.) Completed December 2007

French Completed August 2008

German Completed April 2009. Intro course translated October 2009

Spanish Completed in June 2009

Portuguese Completed in May 2010

Language Status (for ACQ V1.2)

Easing Translation

₂

(41)

Front Matter

The Problem

Many improvements were made to the models and the front matter needed to describe and reflect those changes.

• Added the history of CMMI to accompany Figure 1.2 • With a few exceptions, removed mention of “source models” • Removed any biases favoring maturity levels or capability levels • Clarified that CMMI models are not processes or process descriptions • Added information on selecting the right CMMI model for use

• Clarified that section 2 Process Area Components contains descriptions and not definitions

• Mentioned (DEV only) that recursion among PAs can also apply to Project Management PAs (In V1.2, some inferred the idea of recursion might apply to Engineering PAs only.)

(42)

Summary

There were many changes to the model in many areas. The following V1.3 change criteria was used to guide these changes:

• Improve clarity of high maturity material and its alignment across required, expected, informative

• Provide more effective GPs • Improve appraisal efficiency

• Increase the commonality across the constellations: harmonize the constellations, including incorporation of improvements introduced in later V1.2 releases

• Reduce model complexity and size

• Correct identified model defects or provide enhancements

CMMI

®

_{Version 1.3 Model}

(43)

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. Government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. Government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

Purpose

Improvements were made to all PAs; some PAs changed more than others.

This module provides a summary of changes for each PA. The summaries of changes are presented in alphabetical order by PA abbreviation.

(44)

Summary of Changes in AM

Made no substantive changes to specific goals, specific practices, or terminology

Adjusted the focus of an example work product to help ensure that the specific practice (SP 1.1 Execute the Supplier Agreement) is interpreted to cover responsibilities of the acquirer as well as the supplier

Added guidance for determining the levels to which the selected supplier processes should be monitored

Moved this process area from the Acquisition process area category to the Project Management category

Summary of Changes in ARD

Made no substantive changes to specific goals or specific practices Added material throughout the process area to incorporate modern engineering practices, such as quality attributes, product lines, system of systems, architecture-centric practices, allocation of product capabilities to release increments, and technology maturation (This addition of material resulted in changes to informative material and terminology.) Added informative material to acknowledge the importance of customer satisfaction

Added informative material to highlight transition, sustainment,

operations, and installation as lifecycle stages to be considered during requirements development

(45)

Summary of Changes in ATM

Added material throughout the process area to incorporate modern engineering practices, such as quality attributes, product lines, system of systems, architecture-centric practices, allocation of product capabilities to release increments, and technology maturation (This addition of material resulted in changes to informative material.)

Added informative material to provide guidance for managing suppliers that are using an Agile method

Added examples and guidance to informative material

Summary of Changes in AVAL

Clarified when validation occurs in the product lifecycle

(46)

Summary of Changes in AVER

Added architecture evaluations as an additional method of verification

Summary of Changes in CAM

(47)

Summary of Changes in CAR

Used “outcomes” to include positive outcomes instead of only “defects and problems”

Added examples for service organizations and for selecting outcomes for analysis

Added subpractices in SP 1.1 for defining the problem, and in SP 2.2 for following up when expected results were not realized

Added more information about how PPMs can be used

Added informative material addressing more proactive defect prevention

Summary of Changes in CM

Made no substantive changes to specific goals or specific practices Removed “functional configuration audits (FCA)” and “physical

configuration audits (PCA)” from the glossary (which are used only in SP 3.2 Perform Configuration Audits)

Added guidance at multiple locations on how CM applies to hardware, equipment, and other tangible assets in addition to software and documentation

Addressed how CM applies in Agile environments in the introductory notes

Added subpractices about specifying relationships among configuration items, providing access control to the CM system, and categorizing and prioritizing change requests

Added the need to check for consistency among configuration items as part of assuring baseline integrity

(48)

Summary of Changes in DAR

Made no substantive changes to the specific goals, specific practices, or terminology

Made minor changes to the informative material to provide clarification of practices and subpractices

Added guidance on defining the issue to be addressed (the decision to be made) and on communicating the results and rationale for the solution

Summary of Changes in IPM

Deleted SG 3 and its associated specific practices to remove the IPPD addition

Added SP 1.5 subpractice 5 to remind the user that causal analysis to prevent recurrence of issues can be one of the actions taken to improve project or work performance

Added SP 1.6 to address teams from a broader perspective than IPPD Revised the following terms in the glossary: project, project startup, and team

(49)

Summary of Changes in IRP

Restructured IRP SG 2 and SG 3 to more clearly distinguish between the scope of each goal (SG 2 will now Identify, Control, and

Address Individual Incidents, and SG3 will Analyze and Address Causes and Impacts of Selected Incidents.)

Added the concept of identifying a previously established workaround or known reusable solution to handle an incident similar to past incidents in SG 2 and SG 3

Clarified the SP 3.1 title and practice statement to reflect that for selected incidents, underlying causes are analyzed

Added examples and guidance to informative material

Summary of Changes in MA

Distinguished more clearly between information needs and objectives, measurement objectives, and business/project objectives in the informative material

Added informative material to acknowledge the importance of customer satisfaction

Added a table similar to the one for CMMI-ACQ, which provides some common examples of measures, measurement information categories, base measures, derived measures, and measurement relationships

(50)

Summary of Changes in OPD

Removed all IPPD addition material including SG 2, Enable IPPD Management

Added SP 1.7 (formerly SP 2.2), Establish Rules and Guidelines for Teams and modified the purpose statement

Replaced the glossary definition of “integrated team” with one for “team” Provided additional guidance and examples to the informative material

Summary of Changes in OPF

Made no substantive changes to specific goals or terminology Simplified the SP 3.4 compound practice statement from collecting “process-related work products, measures, and improvement information” to collecting “process related experiences”

Added guidance on evaluating customer satisfaction as a source for process improvements

(51)

Summary of Changes in OPM (old OID)

Expanded the former OID PA to include performance management and called it Organizational Performance Management (OPM) to emphasize a focus on performance of the organizational processes as they relate to business objectives

Defined a new goal about managing business performance using statistical and other quantitative techniques

Clarified that improvements selected for possible implementation can be validated in different ways (Piloting is not the only option.)

More explicitly described the use of process performance models

Provided more information about how improvements can be selected for deployment

Changed references from “process and technology improvements” to “improvements” with an explanation that improvements include both

Summary of Changes in OPP

Restructured OPP, moving “Establish Quality and Process Performance Objectives” to SP 1.1 for emphasis

Revised SP 1.4 to include process performance analysis and assessment of subprocess stability

Revised SP 1.5 to clarify that process performance models are used throughout the development lifecycle toward achieving quality and process performance objectives

Clarified that not all process performance baselines and models must be created at the organization level (Projects can follow OPP practices to create process performance baselines and models, when appropriate.) Clarified the relationship of OPP to other high maturity process areas Emphasized traceability to business objectives through modifications to SP1.1 and SP1.2

(52)

Summary of Changes in OT

Revised the PA to eliminate “technical” training where it may not apply to all model constellations

Removed the subjective term “necessary” (as in “Provide Necessary Training”) from the SG 2 title and statement

Made no substantive changes to specific practices or terminology Added examples and guidance to the informative material

Summary of Changes in PI

Made no substantive changes to specific goals

Changed SP 1.1 to focus on an “integration strategy” rather than an “integration sequence” to reflect the complexity of the activity (This change caused additional revisions to SP 3.2 and informative material throughout the process area.)

Added material to incorporate modern engineering practices, such as quality attributes, product lines, system of systems, architecture-centric practices, allocation of product capabilities to release increments, and technology maturation (This change resulted in further changes to SP 3.1 and informative material throughout the process area.)

(53)

Summary of Changes in PMC

Made no substantive changes to specific goals or specific practices Revised the definitions of the following terms in the glossary: project and project startup

Deleted the term “program” from the glossary

Provided additional examples and made some minor changes to the informative material

Summary of Changes in PP

Made no substantive changes to specific goals or specific practices Revised the definitions of the following terms in the glossary: project and project startup

Deleted the term “program” from the glossary

Added information on how PP applies to product lines and Agile environments in the introductory notes

Removed the material that addressed IPPD

Added subpractices to specific practices 2.3 and 2.4

Modified the informative material so that the development of WBS can be based on other considerations in addition to the product or product architecture

(54)

Summary of Changes in PPQA

Made no substantive changes to specific goals or terminology

Changed “designated” to “selected” in the specific practices to convey that there should be a selection not just a designation of what to objectively evaluate

Clarified that PPQA applies to both project and organization level activities and work products

Added information about how PPQA applies in Agile environments in the introductory notes

Emphasized more consistently in the informative material that objective evaluations are applied to selected performed processes and work products

Generalized the subpractices so that they do not limit the value that objective evaluations can provide

Summary of Changes in QPM

Restructured QPM so that SG1 focuses on preparation and SG2 focuses on managing the project

Broadened the focus on using statistical techniques from individual selected subprocesses to cover multiple levels from the individual subprocesses to the entire project

Added guidance about using process performance baselines and process performance models

Defined quantitative management in the glossary to include statistical techniques and used that definition throughout QPM

(55)

Summary of Changes in RD

Revised a specific goal (i.e., SG 3 Analyze and Validate Requirements), a specific practice (i.e., SP 3.2 Establish a Definition of Required Functionality and Quality Attributes), informative material, and terminology by adding material throughout the process area to incorporate modern engineering practices involving quality attributes, product lines, system of systems, architecture-centric practices, allocation of product capabilities to release increments, and technology maturation

Modified SP 1.2 Transform Stakeholder Needs into Customer Requirements to emphasize that the result is prioritized customer requirements

Added information on how Requirements Development works with Agile methodologies

Added and revised the following glossary terminology: quality attributes, architecture, definition of required functionality and quality attributes, allocated requirement, functional analysis, product line

Summary of Changes in REQM

Revised SP 1.5 on ensuring alignment to better describe the intent and making it more proactive by focusing on the alignment of plans and work products with requirements rather than finding inconsistencies

Added information to the introductory notes on how REQM applies in Agile environments

Made revisions in SP 1.4 to more clearly communicate what is intended by traceability

Changed “agreed-on requirements” to “approved requirements”

throughout the PA to more clearly communicate what will be the basis for planning, acquisition, design, service delivery, etc.

Moved this process area from the Engineering process area category to the Project Management category

(56)

Summary of Changes in RSKM

Modified the specific practice 3.1 statement to explicitly tie risk mitigation planning back to the risk management strategy

Addressed how RSKM applies in Agile environments in the introductory notes

Provided additional examples and made some minor changes to the informative material

Added the following themes to the informative material:

• the use of industry standards to help identify and prevent risks • risks associated with quality attributes and product architecture • the use of risk monetization to enhance standard treatment of risks

• the use of techniques such as FMEA to improve the discipline in treatment of risk parameters

Summary of Changes in SAM

Revised the wording in SP1.3, Establish Supplier Agreements, from “formal” agreements to “supplier” agreements

Demoted SP 2.2, Monitor Selected Supplier Processes, and SP 2.3, Evaluate Selected Supplier Work Products, to subpractices of SP 2.1, Execute the Supplier Agreement

Revised the practice SP2.3 (previously numbered as SP 2.5), Ensure Transition of Products, to allow it to apply when the product or service is delivered directly from the supplier to the customer or end user

(57)

Summary of Changes in SCON

Revised SP 3.3, Analyze Results of Verification and Validation, to focus on verification and validation of the service continuity plan

Explicitly defined the term “essential functions”

Summary of Changes in SD

Provided guidance to maintain traceability to requirements when the resolution to a service request results in changes to the service system Added material that reminds service providers to give customer and end user training and orientation as needed

Added guidance on managing and controlling operationally oriented quality attributes associated with service delivery