a software process framework for the sei capability ... · pdf filehandbook cmu/sei-94-hb-01...

Handbook

CMU/SEI-94-HB-01September 1994

A Software Process Framework for the SEI Capability Maturity Modelsm

Timothy G. Olson

Neal R. Reizer

James W. Over

Software Engineering InstituteCarnegie Mellon University

Pittsburgh, Pennsylvania 15213

Unlimited distribution subject to the copyright.

HandbookCMU/SEI-94-HB-01

September 1994

A Software Process Framework

for the SEI Capability Maturity Modelsm

Timothy G. Olson

Neal R. Reizer

James W. Over

This report was prepared for the

SEI Joint Program OfficeHQ ESC/AXS5 Eglin StreetHanscom AFB, MA 01731-2116

The ideas and findings in this report should not be construed as an official DoD position. It is published in theinterest of scientific and technical information exchange.

FOR THE COMMANDER

(signature on file)

Thomas R. Miller, Lt Col, USAFSEI Joint Program Office

This work is sponsored by the U.S. Department of Defense.

Copyright © 1994 by Carnegie Mellon University.

Permission to reproduce this document and to prepare derivative works from this document for internal use isgranted, provided the copyright and “No Warranty” statements are included with all reproductions and derivativeworks.

Requests for permission to reproduce this document or to prepare derivative works of this document for externaland commercial use should be addressed to the SEI Licensing Agent.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIALIS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRAN-TIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOTLIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTIBILITY, EXCLUSIVITY, ORRESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOESNOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT,TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 withCarnegie Mellon University for the operation of the Software Engineering Institute, a federally funded researchand development center. The Government of the United States has a royalty-free government-purpose license touse, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so,for government purposes pursuant to the copyright license under the clause at 52.227-7013.

This document is available through Research Access, Inc., 800 Vinial Street, Pittsburgh, PA 15212. Phone: 1-800-685-6510. FAX: (412) 321-2994. RAI also maintains a World Wide Web home page. The URL ishttp://www.rai.com

Copies of this document are available through the National Technical Information Service (NTIS). For informa-tion on ordering, please contact NTIS directly: National Technical Information Service, U.S. Department ofCommerce, Springfield, VA 22161. Phone: (703) 487-4600.

This document is also available through the Defense Technical Information Center (DTIC). DTIC provides accessto and transfer of scientific and technical information for DoD personnel, DoD contractors and potential contrac-tors, and other U.S. Government agency personnel and their contractors. To obtain a copy, please contact DTICdirectly: Defense Technical Information Center / 8725 John J. Kingman Road / Suite 0944 / Ft. Belvoir, VA22060-6218. Phone: (703) 767-8222 or 1-800 225-3842.]

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder.

Table of Contents

Acknowledgments ..................................................................................................................................... iv

To The Reader............................................................................................................................................. v

Chapter 1 Introduction ..........................................................................................................Introduction-1

About this document ....................................................................................................Introduction-2

Organization of this document ..................................................................................... Introduction-4

Questions Addressed by the Software Process Framework .......................................Introduction-5

Process Definition Criteria ...........................................................................................Introduction-6

Relation to the CMM ....................................................................................................Introduction-8

The Operational Framework ........................................................................................Introduction-9

Chapter 2 Features of the Software Process Framework...................................................... Features-1

Checklists ........................................................................................................................ Features-2

CMM Context................................................................................................................... Features-4

CMM Reference Text ...................................................................................................... Features-5

CMM Role Identification .................................................................................................. Features-8

Entry and Exit Criteria...................................................................................................... Features-9

Translation Tables ......................................................................................................... Features-11

User References............................................................................................................ Features-15

Chapter 3 How to Use the Software Process Framework.......................................................... Usage-1

Using the Software Process Framework to Analyze and Review Software Processes....... Usage-2

Chapter 4 Repeatable Level (Level 2) ................................................................................................ L2-1

Level 2 Policy Checklists .................................................................................................L2-Policy-1

Level 2 Standards Checklists ................................................................................... L2-Standards-1

Level 2 Process Checklists.......................................................................................... L2-Process-1Requirements Management ........................................................................... L2-Process-3

Software Project Planning ............................................................................ L2-Process-23

Software Project Tracking and Oversight ..................................................... L2-Process-59

Software Subcontract Management ............................................................. L2-Process-97

Software Quality Assurance ....................................................................... L2-Process-129

Software Configuration Management ......................................................... L2-Process-155

Level 2 Procedure Checklists ................................................................................. L2-Procedures-1

Level 2 Summary .......................................................................................................L2-Summary-1

CMU/SEI-94-HB-1 i

Table of Contents, Continued

Chapter 5 Defined Level (Level 3) ...................................................................................................... L3-1



Level 3 Process Checklists.......................................................................................... L3-Process-1Organization Process Focus .......................................................................... L3-Process-3

Organization Process Definition ................................................................... L3-Process-25

Training Program .......................................................................................... L3-Process-49

Integrated Software Management ................................................................ L3-Process-67

Software Product Engineering .................................................................... L3-Process-103

Intergroup Coordination .............................................................................. L3-Process-149

Peer Reviews ............................................................................................. L3-Process-179



Chapter 6 Managed Level (Level 4) ................................................................................................... L4-1



Level 4 Process Checklists.......................................................................................... L4-Process-1Quantitative Process Management................................................................. L4-Process-3

Software Quality Management ..................................................................... L4-Process-31



Chapter 7 Optimizing Level (Level 5) ................................................................................................. L5-1



Level 5 Process Checklists.......................................................................................... L5-Process-1Defect Prevention ........................................................................................... L5-Process-3

Technology Change Management ............................................................... L5-Process-35

Process Change Management ..................................................................... L5-Process-77



ii CMU/SEI-94-HB-1

Table of Contents, Continued

Appendices ................................................................................................................................ Appendix-1

Appendix A List of Acronyms.......................................................................................... Appendix-3

Appendix B Glossary of Terms ....................................................................................... Appendix-5

Appendix C Role Translation Table.............................................................................. Appendix-21

Appendix D General Term Translation Table ............................................................... Appendix-39

Appendix E References................................................................................................ Appendix-41

CMU/SEI-94-HB-1 iii

Acknowledgments

The authors would like to thank the customers who sponsored this work and provided manyideas for developing this product. The authors want to thank the software engineering processgroup (SEPG) at Standard Systems Center (SSC), Maxwell Air Force Base, Gunter Annex. TheSSC SEPG consisted of Ron Obranovich, Captain Ken Anthonis, Captain Al Braaten, CaptainMark Minkler, and Captain Gloria Trabue. We would also like to thank the primary SSCsponsor, Colonel John Barnhart.

The authors would also like to thank Army Materiel Command (AMC) for their support and input.We would like to extend a special thanks to Jim Reeb at Missile Command (MICOM) for pilottesting previous versions of the Software Process Framework (SPF) while MICOM moved frommaturity level 1 to maturity level 2. We would also like to thank Bob Goetze and Chuck Gordonat Armament Munitions and Chemical Command (AMCCOM) for providing the opportunity topilot test an early version of the SPF.

The members of the Software Process Definition (SPD) Project at the SEI contributed manyideas that improved the quality of this document tremendously. The SPD Project members areJim Hart, Mark Kasunic, Marc Kellner, and Dick Phillips. We would also like to give specialrecognition to Julia Mullaney for her contribution to the operational framework and processdefinition concepts that provide the basis for this document.

The authors would like to thank the members of the SEI technical staff who contributed theirtime as technical reviewers of this document. A special thanks to Suzanne Garcia, MichaelKonrad, and Mark Paulk for their review comments. Additional technical reviews were providedby Jim Armitage of GTE Government Systems Corporation, Mark Ginsberg of Hughes AircraftCompany, and Charlie Weber of Loral Federal Systems.

The authors greatly appreciate Dawna Baird for her outstanding administrative support andinexhaustible patience and Suzanne Couturiaux for her editorial assistance.

iv CMU/SEI-94-HB-1

To the Reader

The Software Process Framework (SPF) is a document that provides informationcontained in the SEI Capability Maturity Model (CMM) for Software v1.1 [Paulk93a]in a format suitable for process definition and improvement. The SPF allows users todetermine if their organization’s software process documentation is consistent with therecommendations made by the CMM. When organizational software processdocumentation is found to be inconsistent with the CMM, the SPF provides the abilityto make informed decisions regarding the applicability of specific CMMrecommendations.

Introduction

Many organizations have started down the path of software process improvement byconducting a software process assessment and then responding with action plans toaddress the assessment findings. At this point, many organizations find themselvesstruggling to develop software processes that are consistent with the CMM. The SPFhelps to address part of this implementation barrier by answering the question:

Background

How does an organization know if its software policies, standards, processes,procedures, training, and tools are consistent with the CMM?

The primary audiences of this document are:Primaryaudiences

• Software engineering process groups (SEPGs) or process engineers:Organizational units or personnel responsible for facilitating software processimprovement.

• Software process improvement groups: Organizational teams responsible forimproving software processes such as process action teams (PATs), qualityimprovement teams, or technical working groups (e.g., a PAT addressing a softwareprocess assessment finding).

• Software quality assurance groups or process assurance: Organizational groups orpersonnel responsible for auditing, reviewing, verifying, or validating softwareprocesses.

Assumption: The primary audiences of this document are assumed to beexperienced in software process improvement, experienced using theSEI CMM, and familiar with CMM-based appraisals (softwareprocess assessments and software capability evaluations).

Continued on next page

CMU/SEI-94-HB-1 v

To The Reader, Continued

Secondary audiences of this document include:Secondaryaudiences

• Managers: Individuals or groups who are responsible for planning, controlling, andimproving software acquisition, development, or maintenance processes and areinterested in using the CMM for software process improvement.

• Software process participants: Individuals or groups responsible for implementingsome portion of a software acquisition, development, or maintenance process.

• Sponsors: Personnel responsible for funding, authorizing, and providing the neededresources for software process improvement efforts that are based on the CMM.

The primary uses of the SPF are to:Primary uses

• Analyze and review software processes to check consistency with the CMM (in thecontext of process assurance or process verification).

• Design software processes so that they are consistent with the CMM.

• Serve as a technical reference for the SEI workshop “Defining Software Processes:Getting Started.”

Additional uses of the SPF include:Additional uses

Improvement efforts:• Help identify who should be involved in a software process improvement effort.• Guide charter and plan development for process action teams (PATs).• Guide PATs in establishing selection criteria for process improvement pilot projects.• Help measure success criteria for pilot projects and for installing and

institutionalizing a software process.

Defining organizational roles:• Provide a checklist for software quality assurance (SQA) reviews and audits.• Help define organizational roles, responsibilities, and scope (e.g., software

configuration management).

Others:• Provide criteria for a “good process definition.”• Help communicate the CMM recommendations to achieve a particular maturity

level to senior management (or others).• Help develop process guides and process models (e.g., SEPG uses the SPF as a

template to build a process guide).• Help tailor software processes (e.g., structure and content).


vi CMU/SEI-94-HB-1

To The Reader, Continued

This document contains a set of checklists to help an organization determine if itssoftware policies, standards, processes, procedures, training, and tools are consistentwith the CMM.

The checklists are not intended to be scored or used as the basis for an appraisal (i.e.,software capability evaluation or software process assessment).

Do not use forappraisals

CMU/SEI-94-HB-1 vii

viii CMU/SEI-94-HB-1

Chapter 1 . Introduct ion

O v e r v i e w

This chapter will provide the rationale for the development of the SoftwareProcess Framework (SPF). This chapter also describes the major conceptsunderlying the development of the SPF.

Introduction

This chapter contains the following topics:In this chapter

Topic See page

About this document Introduction-2

Organization of this document Introduction-4

Questions addressed by the SPF Introduction-5

Process definition criteria Introduction-6

Relation to the CMM Introduction-8

The operational framework Introduction-9

CMU/SEI-94-HB-1 Introduction-1

About this Document

This section provides an overview of this document.Introduction

Purpose The purpose of the SPF is to provide guidance for designing, analyzing, andreviewing software processes for consistency with the CMM.

To fulfill its purpose, the SPF:

• Is based on the CMM and the principles of quality and process management.

• Presents information recommended by the CMM in a format suitable forsoftware process definition and improvement.

• Identifies policies, standards, processes, procedures, training, and toolsrecommended by the CMM.

• Provides checklists for designing, analyzing, and reviewing software policies,standards, processes, procedures, training, and tools so that they can beconsistent with the CMM.

The SPF addresses levels 2 through 5 of the CMM, version 1.1.Scope

The Software Process Framework is not:The SPF isnot...

• A procedure for reaching a particular maturity level.The SPF doesn’t tell you how to get to a particular maturity level, but ratherwhat the “goal state” looks like from a process definition and improvementperspective.

• Process definition training.The SPF does not provide all the needed knowledge and skills for defining asoftware process.

• A method or process.The SPF does not provide a method or process for defining a software process.

• A replacement for the CMM.The CMM contains information about organizational software process maturity;the SPF contains similar information but it is organized for the purpose ofdesigning, analyzing, and reviewing software processes for consistency with theCMM.

• A process model or process guide.

We recommend that organizations tailor the checklists for their own use byrestating and adding terminology that is organization specific.

Tailoring theSPF

Introduction-2 CMU/SEI-94-HB-1

About this Document , Continued

In thisdocument

This document contains the following chapters and appendices.

Chapter Title Description

1 Introduction Rationale for development of theSPF

2 Features of the SPF Descriptions and examples of SPFfeatures

3 How to use the SPF Guidance and examples of using theSPF

4 Repeatable Level (Level2)

Checklists of CMM recommendedinformation for maturity level 2

5 Defined Level (Level 3) Checklists of CMM recommendedinformation for maturity level 3

6 Managed Level (Level 4) Checklists of CMM recommendedinformation for maturity level 4

7 Optimizing Level (Level5)

Checklists of CMM recommendedinformation for maturity level 5

Appendix A List of Acronyms Acronyms used in the SPF

Appendix B Glossary of Terms CMM glossary, with additional termsthat have been introduced in the SPF

Appendix C Role Translation Table A tool to translate generic CMMroles into organization specific roles

Appendix D General Term TranslationTable

A tool to translate generic termsused in the CMM into equivalentorganization terms

Appendix E References References upon which the SPF isbased


Organization of this Document

This section provides an overview of the organization of this document.Introduction

CMM maturitylevels

Each level of the CMM is presented as a separate chapter in the SPF. Gray tabsare used to delimit individual maturity levels.

Example: Maturity level 2 is presented in chapter 4 of the SPF.

Each maturity level of the CMM is presented with separate sections for softwarepolicies, standards, processes, and procedures.

Example: Chapter 4 contains sections for the policies, standards, processes, andprocedures recommended by the CMM for maturity level 2.

Organizationof eachmaturity level

Each section within a maturity level (i.e., policies) is further divided by keyprocess area (KPA).

Example: The policy section of chapter 4 contains a separate entry for eachlevel 2 KPA (e.g., requirements management policy information).

Division ofKPAs


Quest ions Addressed by the SPF

This section presents the questions facing process definers that the SPF has beendeveloped to address.

Introduction

Relationshipbetween theSPF and CMM

The CMM contains many of the best practices for developing and maintainingsoftware. People defining software processes consistent with the CMM require theinformation in the CMM to be presented in a format that helps them to analyzeand structure their process information.

The SEI Software Process Definition Project has developed the SPF to support thedefinition of software processes. It accomplishes this by examining the CMMfrom the perspective of process definition and presenting the results as a series ofchecklists.

When developing software process documentation, process definers are faced withthree challenging questions:

Questionsfacing processdefiners

• What software process information do I need to document?• What recommendations does the CMM make about this process information?• How do I effectively organize the process information once I have found it?

The SPF was developed to address these questions. In other words, it serves as abridge from current practice to defined software processes that are consistent withwhat the CMM recommends.

Each question facing a process definer is addressed by a different aspect of theSPF. The aspects of the SPF that address the questions presented above areshown in the table below.

The SPFaddressesthese questions

This question... Is answered by this aspect of theSPF...

What software process information doI need to document?

Process definition criteria

What does the CMM say about thisprocess information?

Relation to the CMM

How do I organize the processinformation once I have found it?

Operational framework


Process Def ini t ion Cr i ter ia

This section describes process definition criteria and their relationship to the SPF.Introduction

Definition:Processdefinitioncriteria

Process definition criteria are the set of information that must be included in asoftware process description for it to be usable by the people performing theprocess.

Determining the appropriate process definition criteria answers the question,“What software process information do I need to document?”

Rationale forthe criteria

Satisfying the process definition criteria requires developing and maintainingprocess descriptions that contain the information necessary for the softwareprocess description to be usable by the people performing the process. Theprocess definition criteria can be satisfied by answering the basic set of questionsgiven below.

Satisfying thecriteria

Each basic question is answered by an associated process element. The set ofbasic process questions and their associated process elements are shown in thetable below.

Processelements

This processelement...

Answers this basic question...

Purpose Why is a process performed?

Input What work products are used?

Output What work products are produced?

Role Who (or what) performs the activities?

Activity What is done?

Entry criteria When (under what circumstances) can processes begin?

Exit criteria When (under what circumstances) can processes be consideredcomplete?

Procedure How are activities implemented?


Process Def ini t ion Cr i ter ia , Continued

Additionalprocesselements

In addition to the process elements shown above, there are several other pieces ofinformation that are useful to include in process descriptions. They are:

• Reviews and audits performed.• Work products that are to be managed and controlled (or placed under

configuration management).• Measurements to be made.• Training.• Tools.

Every CMM key process area is presented as a series of checklists (see Chapter2, Features of the SPF). There is one checklist for each process element (exceptpurpose). For example, the software project planning KPA has checklists forinputs, outputs, roles, activities, and so on.

The content of these checklists is derived from the recommendations made by theCMM (see the next section, Relation to the CMM).

Processelements andthe SPF


Rela t ion to the CMM

Introduction This section describes the relationship between the CMM and the SPF.

Relationbetween theCMM and theSPF

In the previous section, we discussed the types of information that must beincluded in a software process description. This lead to a set of basic questions toask regarding a software process description.

Once the basic set of questions has been asked, the next challenge is to find theanswers. The CMM is a normative model of best practice from the softwareengineering community and is a source of one set of answers.

The recommendations made by the CMM are presented as checklists. A processelement checklist contains the information recommended by the CMM for aparticular process element.

Example: A roles checklist describes the roles recommended by the CMM for aparticular key process area.

Definition

Using the CMM as a source of answers to the basic set of process questions, wedeveloped a series of process element checklists for each key process area. Thesechecklists are described in the table below.

Processelementchecklists

Checklist Description

Roles List of roles participating in process activities

Entry Criteria Description of when the process can start

Inputs Description of the work products used by the process

Activities Description of the activities of the process

Outputs Description of the work products produced by the process

Exit Criteria Description of when the process is complete

Reviews andAudits

List of reviews and audits performed during the process

Work ProductsManaged andControlled

List of work products to be managed and controlled

Measurements Description of process measurements

DocumentedProcedures

List of the activities to be completed according to adocumented procedure

Training List of training for the process

Tools List of tools to support the process


The Operat ional Framework

Introduction This section describes the operational framework and its relation to the SPF.

Operationalframeworkand the SPF

The SPF separates information within a CMM maturity level into anorganizational structure for software process documentation called the operationalframework. The operational framework contains the following process informationtypes:

Standards

ProcessDescribe "what happens" within the

organization to build products that

conform to the standards in accordance with the policies of the organization

Procedures

Describes "how-to" or step-by-step instructions that implement the process

Constrain the process

is implemented by

TrainingKnowledge/skills required to

use a procedure

ToolsAutomated support needed to implement the procedures

are supported by

Policy

The "laws" or "regulations" that govern or constrain operations

The "operational definitions" or "acceptance criteria” for

final and interim products

Software process documentation must be usable for people. Processdocumentation that is organized poorly will inhibit people from using it andreduce its effectiveness. The operational framework helps to eliminate thisproblem because it helps to:

Rationale forthe operationframework

• Separate information into usable parts: The operational framework separatesinformation into usable parts used for different purposes. For example, if youwant to see an organizational policy, detailed training information included withthe policy is irrelevant information (meaning either wasted time or ignoring thepolicy).



The Operat ional Framework , Continued

Rationale forthe operationframework,continued

• Identify and use only the relevant information for each part: Only relevantinformation needs to be in each part of the operational framework. For example,training information should only be in training documents, and policies shouldcontain information that does not change frequently. By placing only relevantinformation in each part of the operational framework, people will learn whereto look for information.

• Manage changes and improvements: Changes and improvements to theoperational parts will be easier to manage because the information is welldefined. For example, once defined, policies should not frequently change.Processes probably do not need to change if a step by step procedure changes.Training changes can be isolated to training documents. Only the necessary andimportant relationships between the operational parts need to be managed.

• Manage and improve communication: Communication improves because peopleknow where to look for certain types of information, and they know therelationships between the information. Since the changes are isolated to theoperational parts, less communication is needed and only the relevant changesneed to be managed and communicated.

Within each maturity level of the CMM, the SPF is organized according to theoperational framework. Therefore, each maturity level is presented with separatesections for:

Impact on SPForganization

• policies• standards,• processes, and• procedures.

Note: Training and tools are closely related to processes and are presented aschecklists with the process they support.


Chapter 2 . Features of the Software ProcessFramework

O v e r v i e w

Chapterpurpose

The purpose of this chapter is to describe the features of the Software ProcessFramework (SPF).

This chapter discusses the following features:In this chapter

Feature See Page

Checklists Features-2

CMM context Features-4

CMM reference text Features-5

CMM role identification Features-8

Entry and exit criteria Features-9

Translation tables Features-11

User references Features-15

CMU/SEI-94-HB-1 Features-1

Checklists

The SPF presents information in checklists, which provide various perspectives ofthe recommendations made by the CMM. Organizations can use these checkliststo compare their process documentation to the CMM.

The purpose of this section is to describe how the checklists in the SPF can beused.

Introduction

There are five types of checklists in the SPF. Their names and descriptions areprovided below.

Types ofchecklists

Checklist Type Description

Policy Describes the policy contents and KPA goals recommendedby the CMM.

Standard Describes the recommended content of select work productsdescribed in the CMM.

Process Describes the process information content recommended bythe CMM. The process checklists are further refined intochecklists for:• roles,• entry criteria,• inputs,• activities,• outputs,• exit criteria,• reviews and audits,• work products managed and controlled,• measurements,• documented procedures,• training, and• tools.

Procedure Describes the recommended content of documentedprocedures described in the CMM.

Level Overview Provides an overview of an entire maturity level. The leveloverview checklists are further refined into checklists for:• KPA purposes,• KPA goals,• policies,• standards,• process descriptions,• procedures,• training,• tools,• reviews and audits,• work products managed and controlled, and• measurements.

Features-2 CMU/SEI-94-HB-1

Checklists , Continued

A checklist is used to:Use

• allow process designers, analyzers, or reviewers to check whether their softwareprocesses are consistent with the CMM.

• indicate that a particular item is being addressed by the organization.

The following example illustrates how the SPF checklists are used to showconsistency with the CMM, and illustrate compliance and noncompliance withspecific CMM recommendations. As shown in the example below, a check ( ) inthe left column is used to indicate that a role has been completely satisfied.

The checkboxes “ q ” are used when there are checklists within checklists (nestedchecklists). When there are nested checklists, the left column becomes theparent checklist. Only check the parent checklist if all the checkboxes in thatparent are satisfied.

In the example below, the SCCB role is not satisfied (the parent checklist is notchecked) because all of the checkboxes within that parent have not been checked.Only the project manager role has been completely satisfied (indicated by thecheck in the left column).

q

q

q

RolesThe table below describes the activities that are performed by the CMM roles in thesoftware configuration management process.

Role Activity ReferenceProjectManager

The SCM activities are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-83, V2) V1 S5.2

SCCB The SCCB: (L2-73, Ab1)

q Authorizes the establishment ofsoftware baselines and theidentification of configurationitems/units.

Represents the interests of theproject manager and all groups whomay be affected by changes to thesoftware baselines.

Reviews and authorizes changes tothe software baselines.

Authorizes the creation of productsfrom the software baseline library.

V1 S4.6.2

V1 S4.6

V1 S4.6.2a

V1 S4.6.2.b

Example of use


C M M C o n t e x t

There are many places where extracting a passage from the CMM results in lostcontext. This section describes how CMM-specific context within the SPF isprovided.

Introduction

Parentheses are used to provide CMM-specific context within the SPF.Indicatingadded context

The following example from the intergroup coordination key process area showsthe use of parentheses to maintain context:

IC Process - Inputs

Inputs The table below lists the recommended inputs to the intergroup coordinationprocess.

Input Org. Input References

Actual completion (of criticaldependencies). (L3-89, A4, 5.1)

Changes to intergroup commitments. (L3 -88, A3, 4)

Changes to the plan (used to communicateintergroup commitments and to coordinateand track the work performed). (L3-88,A3, 5)

Changes to the project-level objectives. (L3-87, A2, 1.2)

Changes to the system requirements. (L3-87, A2, 1.2)

Commitments. (L3-90, A7, 4)

Customer’s requirements. (L3-87, A1, 1)

End users requirements. (L3-87, A1, 1)

Intergroup commitments. (L3-88, A3)

Plan (used to communicate intergroupcommitments and to coordinate and trackthe work performed). (L3-88, A3)

Project schedule. (L3-89, A4, 3)

Projected completion (of criticaldependencies). (L3-89, A4, 5.1)

Software schedule. (L3-89, A4, 3)

Status (of critical dependencies). (L3-89,A4, 5.1)

System requirements. (L3-90, A7, 3)

Technical issues. (L3-90, A7, 5)

Technical requirements. (L3-90, A7, 3)

Technical risks. (L3-88, A2, 1.4)

Contextadded

Example


C M M R e f e r e n c e T e x t

The ability to trace from process documentation to the CMM is essential forsoftware organizations. This section describes the convention used to cross-reference information items of the SPF to the CMM source documentation.

Introduction

CMM reference text identifies the location of the CMM source material fromwhich the SPF derives its information.

Definition

CMM reference text is used to:Expected use

• Identify a passage in the CMM quickly.

• Maintain traceability from organizational process documentation to the CMM.

The syntax of CMM reference text is:

([CMM page], [Key practice], [Subpractice].[Subpractice subbullet])

Syntax

This is an example of CMM reference text.

(L2-7, A3, 1.1)

CMM page number

Key practice Subpractice subbullet

Subpractice

Note: Text which spans page boundaries of the CMM is referenced by the firstpage only.

Example:CMMreference text



C M M R e f e r e n c e T e x t , Continued

The abbreviations used for the key practice component of the CMM reference textare listed in the table below.

Abbreviations:Key practices

CMM Common Features (key practice type) Abbreviation

Goal (not a common feature, but added as an SPF abbreviation) G

Commitment to perform C

Ability to perform Ab

Activity performed A

Measurement and analysis M

Verifying implementation V

Note: These abbreviations are always followed by a number denoting the numberassociated with the key practice.

Example: Activity 3 of Requirements Management is found on page L2-7, so the CMM Reference text would be (L2-7, A3).



C M M R e f e r e n c e T e x t , Continued

The following diagram shows a page from the CMM. Examples of CMMreference text are shown as boxed examples.

Example:CMM pagewith SPFreferences

Level 2: Repeatable Requirements Management

(Activity 2) The allocated requirements:

1. Are managed and controlled.

"Managed and controlled" implies that the version of the workproduct in use at a given time (past or present) is known (i.e.,version control), and changes are incorporated in a controlledmanner (i.e., change control).

If a greater degree of formality than is implied by "managed andcontrolled" is desired, the work product can be placed under thefull discipline of configuration management, as is described in theSoftware Configuration Management key process area.

2. Are the basis for the software development plan.

3. Are the basis for developing the software requirements.

Activity 3 Changes to the allocated requirements are reviewed andincorporated into the software project.

1. The impact to existing commitments is assessed, and changes arenegotiated as appropriate.

q Changes to commitments made to individuals and groupsexternal to the organization are reviewed with seniormanagement .

Refer to Activity 4 of the Software Project Planning key processarea and Activity 3 of the Software Project Tracking andOversight key process area for practices covering commitmentsmade external to the organization.

q Changes to commitments within the organization are negotiatedwith the affected groups.

(L2-7, A3)

(L2-7, A3, 1)

(L2-7, A3, 1.1)

CMU/SEI-93-TR-25 CMM Practices n L2-7


CMM Role Ident i f ica t ion

The CMM identifies many roles. This section describes how the SPF highlightsthe roles found in the CMM. This feature should help you use the SPF todetermine the responsibilities of each role defined in the CMM.

Introduction

The SPF defines roles as active or passive depending on the context given in theCMM. The following table provides the basis for defining a particular appearanceof a role as active or passive.

Definition:Types of roles

IF the occurrence... THEN therole is...

Example

refers to an activity the roleparticipate in

Active The software qualityassurance group reviewsand/or audits the...

indicates the existence of a role Passive A group that is responsiblefor coordinating andimplementing ... exists.

is modifying a work product Passive Subcontractor’s plans.

Identification:Active roles

The SPF uses bold typeface to indicate the occurrence of an active role.

Note: In the roles checklist, only the role being described is presented in boldtypeface.

The SPF uses normal typeface for occurrences of passive roles.Identification:Passive roles

The following example illustrates the use of bold typeface in the SPF.

Example: The organization's activities for defect prevention are reviewed withsenior management on a periodic basis. (L5-14, V1)

Example


Entry and Exit Cri ter ia

Entry criteria are the conditions under which an activity can be started. Entrycriteria often take the form of a simple or compound predicate about the state of awork product, role, or activity.

Example:

Definitions

Input State

Allocatedrequirements

are documented. (L2-3, C1, 1)

Exit criteria are the conditions under which an activity can be declared complete.Exit criteria often take the form of a simple or compound predicate about the stateof an artifact, role, or activity.

Example:Output State

Project's softwaredevelopment plan

includes defect prevention activities.(L5-3, C2, 1)

Many of the key process areas, once started, end when the project (ororganization!) ends. For these processes, one way to evaluate whether exitcriteria are being met by the process description is to answer the followingquestion:

Note

If the process was executed as described, would it result in the exit criteria beingsatisfied?

Entry and exit criteria have each been partitioned into two types — input andoutput based and general. The major determinant for the type of criteria is stateinformation. State refers to the status of a work product when entering (entrystate) or exiting (exit state) a process.

Types ofcriteria



Entry and Exit Cri ter ia , Continued

We used the following rule to determine whether entry criteria were input based orgeneral.

Note: The examples are taken from the requirements management key processarea.

Description:Entry criteria

IF the criteria contain stateinformation about an...

THEN theyare...

Example

input input-based entrycriteria

Input: Allocatedrequirements

State: are documented.

activity or role general entrycriteria

The project follows a writtenorganizational policy formanaging the systemrequirements allocated tosoftware.

We used the following rule to determine whether exit criteria were output-based orgeneral.

Note: The examples are taken from the requirements management key processarea.

Description:Exit criteria

IF the criteria contain stateinformation about an...

THEN theyare...

Example

input general exitcriteria

The allocated requirementsare reviewed, and problemsare resolved before thesoftware engineering groupcommits to them.

output output-based exitcriteria

Output: Commitmentsresulting from theallocatedrequirements

State: are negotiated withthe affected groups.

activity or role general exitcriteria

The activities for managingthe allocated requirementsare reviewed with seniormanagement on a periodicbasis.


Translat ion Tables

The purpose of the translation tables is to provide an organization with a tool totranslate CMM terminology into their own terminology.

Purpose

Making the translation assumptions explicit has proven to be beneficial inpractice. Experience has shown that there is rarely a one-to-one mapping ofterminology, and there are usually “gray” areas that should be documented. Therecan also be different terminology within the same organization (e.g., projects ordivisions within the same organization may use different terminology).

Rationale

This section describes three types of translation tables.In this section

Translation table Page

Role translation table Features-12

General term translation table Features-13

Work product translation table Features-14


Role translat ion table

In order to be widely applicable, the CMM uses roles that are not specific to oneorganizational structure. The role translation table provides the ability to mapgeneric CMM roles to the roles found in your organization.

Introduction

Location The role translation tables are located in Appendix C of the SPF.

The role translation table is typically used first in any activity involving the SPF.When to use

To use the role translation table, simply read the CMM role from the left columnof the table and list the equivalent role(s) from your organization in the rightcolumn.

Use

Completing the role translation table may be an iterative activity. For example, ifyou are addressing only one KPA, then you should only complete the table for theroles identified in that KPA.

Note: The roles checklist included in each KPA section of the SPF indicates theroles involved in a particular KPA.

Guidance

The following table provides an excerpted example of a role translation table.Example

CMM Role Your Organization’s Role(s)

Affected groups or other affectedgroups

SQA

SCM

Marketing

Sales

Technical staff

Testing department

And so on...

Project manager Project leader

Project software manager Project leader

Senior management Senior management steering committee

Software engineering process group SEPG

Senior manager CEO

Software engineering staff Technical staff


Genera l Term Transla t ion Table

Since the CMM is broadly applicable, it is unavoidable that some terms will needto be further defined for each organization. The general term translation tables area tool for translating general terms used by the CMM into organization–specificterminology.

Introduction

The general term translation tables are located in Appendix D of the SPF.Location

The general term translation table is used early in any activity involving the SPF,typically after performing role translations.

When to use

To use the general term translation table, simply read the CMM general term fromthe left column of the table and list the equivalent term from your organization inthe right column.

Use

The following table provides an excerpted example of a general term translationtable.

Example

CMM General Terms Your Organization’s Terms

Product Deliverable

Project Project

Software product CSCI/CSCU

Software project Software task

System Product


Work Product Translat ion Table

The work product translation tables provide the ability to translate CMM namesfor work products into your organization’s terminology.

Purpose

There are two types of work product translation tables. They are:Note

• input translation tables, and• output translation tables.

The work product translation tables are embedded as part of the input and outputchecklists for each key process area.

Location

Work product translation tables should be completed when the process inputs andoutputs are being addressed.

When to use

Use the following procedure for completing the work product translation tables.Use

Step Action

1 Read the CMM work product from the input or output column of thechecklist, and list the equivalent organization work product(s) in the“Org. Input” (for inputs) or “Org. Output” (for outputs) column in thechecklist.

2 Place a reference to the organization’s process documentation for thatwork product in the references column of the SPF.

3 Repeat steps 1 and 2 for the rest of the table.

The following table provides an excerpted example of an input translation tablefrom the requirements management process translating CMM inputs into afictitious organization’s inputs. Output translations would result in similar results.

Example


4

Statement of Work. (L2-14, Ab1)

[Refer to Level 2 Standards for additionalinformation regarding a statement of work.]

SOW DID 1000.5

4

Allocated requirements. (L2-18, A6, 1.4)

[Refer to Level 2 Standards for additionalinformation regarding allocatedrequirements.]

SRS

IRS

DID 1000.6


User References

In addition to tracing process documentation back to the CMM, it is alsoimportant for organizations to trace from the SPF to their process documentation.This section describes the feature that provides this capability.

Introduction

User references are used to:Expected use

• Identify the location of the organizational process documentation that addressesa process element in the SPF.

• Indicate the suggested location of the organizational process documentation thatshould address a process element in the SPF that is not currently beingaddressed by the organization.

• Provide traceability from organizational process documentation to the SPF, andtherefore, to the CMM.



User References , Continued

Consider the following scenario:

A user is reviewing an organizational document against the SPF and wantstraceability (from the SPF to the organizational document). The user places areference to the organizational document in the “References” column (e.g.,chapter, section, page, paragraph) of the SPF. Abbreviations are used since blankspace is limited, and there are numerous reference boxes to fill in.

In the example below, “V1” is an abbreviation for “Volume 1”; “V2” is anabbreviation for “Volume 2”; and “S” is an abbreviation for “Section.” In thisexample, the numbers allow traceability to the exact page and subsection of thehypothetical organizational document.

SCM Process - Ex i t Cr i ter ia, Continued

Output-basedExit Criteria,continued

The table below describes the states that outputs must satisfy to exit the softwareconfiguration management process, continued from the previous page.

Output State ReferencesSCM plan q development is coordinated or

implemented by the SCM group. (L2-75, Ab2, 2)

q distribution is coordinated orimplemented by the SCM group. (L2-75, Ab2, 2)

q maintenance is coordinated orimplemented by the SCM group. (L2-75, Ab2, 2)

q is prepared for each softwareproject according to adocumented procedure. (L2-76,A1)

q is developed in the early stagesof, and in parallel with, overallproject planning. (L2-76, A1, 1)

q is reviewed by the affectedgroups. (L2-77, A1, 2)

q is managed and controlled. (L2 -77, A1, 3)

q is documented. (L2-77, A2)

q is approved. (L2-77, A2)

q is used as the basis forperforming the SCM activities. (L2-77, A2)

V1 S2.3.6

V2 S1.2

V2 S1.1

V1 S2.3.6

V1 S2.3.6

V2 S1.3

V2 S1.4

V2 S1.5V2 S1.6

V2 S1.7

4

4

4

4

4

4

Example



User References , Continued

Notice that there can be references to items in the checklist that are not checked.These references can be used as pointers to areas of the organizational documentthat can be improved.

Example: The previous checklistcontains several items that are not satisfied. The references serve aspointers to the location in the organizational process documentationwhere improvements might be made in the future.

References touncheckeditems


Chapter 3 . How to Use the Software ProcessFramework

O v e r v i e w

Chapterpurpose

The purpose of this chapter is to provide guidance on how to use the SoftwareProcess Framework (SPF).

Before reading this section, you will want to become familiar with the features ofthe SPF. Please refer to Chapter 2, Features of the SPF, for further information.

Before youbegin

The audience using the SPF is expected to be experienced in software processdefinition and improvement and familiar with the concepts and terminology of theCMM (e.g., software engineering process groups, process engineers, processaction teams, software quality assurance groups, etc).

Assumptions

Evolution ofthis chapter

This chapter contains guidance for using the SPF to analyze and review softwareprocesses. Additional data are currently being collected and future versions of thisdocument will provide additional guidance.

CMU/SEI-94-HB-1 Usage-1

Using the SPF to Analyze and Rev iew Sof twareProcesses

Many organizations develop baselines of their current software processes. Afterthe baseline is developed, it is useful to be able to analyze it for consistency withthe CMM.

This section provides guidance for analyzing and reviewing existing processdocumentation for consistency with the CMM.

Introduction

Before you begin this procedure, you should identify the scope of the processdocument you are analyzing or reviewing. For example, the scope of yourdocument could be:

Before youbegin

• an entire process document,• organizational policies,• organization standards,• the software project planning KPA, or• the recommended training for level 4.

It is helpful to make photocopies of the appropriate material from the SPF prior tobeginning this procedure (i.e., keep a good master!). For example, if you werereviewing organizational policies against those recommended at level 2, then youwould make copies of the SPF level 2 policy checklists.

Suggestion

To complete this procedure, you will need:What you need

• Role translation tables.• General term translation tables.• The appropriate checklists from the SPF, depending on the scope selected.• Work product translation tables (optional).• The process documentation to be analyzed or reviewed.


Usage-2 CMU/SEI-94-HB-1

Using the SPF to Analyze and Rev iew Sof twareProcesses , Continued

Use this procedure to analyze and review process documentation.Procedure

Step Action

1 Use the role translation table to translate CMM roles into yourorganization’s roles. (See “Role Translation Table” in chapter 2 andAppendix C for blank tables.)

2 Use the general term translation table to translate CMM generalterms into organizational terminology. (See “General TermTranslation Tables” in chapter 2 and Appendix D for templates.)

3 Use the work product translation tables to translate the CMM workproducts into organizational work products. (See “Work ProductTranslation Tables” in chapter 2 and the input and output checklistsin the appropriate KPA section of the SPF)

4 Select an item from the SPF checklist that has not been analyzed orreviewed.

IF: the item is satisfied (i.e., your organization’s processdescription addresses the item being considered)

THEN: check the checkbox next to the item. (See chapter 2 forguidance on completing the checklists)

record the reference to the organizational process document

IF: the item is not satisfied (i.e., your organization’s processdescription does not address the item being considered)

THEN: do not check the checkbox next to the item.

record the reference of where in the process document theitem probably should be addressed, if possible. (This ishelpful for improving the document or process beingevaluated.)

IF: the item does not apply to your organization (e.g., if yourorganization doesn’t subcontract out software, then itemsrelated to software subcontractors probably do not apply toyour organization)

THEN: mark N/A in the checkbox next to item.

if possible, record the rationale (or pointer to the rationale)in the user reference column.

5 IF: there are more items in the SPF checklist to analyze orreview

THEN: go to step 4.

ELSE: the analysis or review is complete.



Usage-4 CMU/SEI-94-HB-1

Using the SPF to Analyze and Rev iew Sof twareProcesses , Continued

When the analysis or review is completed, you will have:Results

• Completed checklists of the CMM recommendations that are satisfied andunsatisfied.

• A list of CMM recommendations that do not apply to your organization, with (ifrecorded) rationale of why they do not.

If all CMM criteria are satisfied, then the process document is consistent with theCMM.

Caution: Do not interpret this as implying a particular maturity rating. The SPFis a measure of consistency of process documentation. Other factorssuch as actual practice are not measured by the SPF.

CMM recommendations that are not satisfied, and have no rationale for why theyare not, become a starting point for process improvement efforts.

Next steps


Chapte r 4 . Repea tab le Leve l (Leve l 2 )

O v e r v i e w

Introduction This chapter contains the checklists for level 2 of the CMM.

This chapter contains the following sections:In this chapter

Section Title Page

Level 2 Policy Checklists L2-Policy-1

Level 2 Standards Checklists L2-Standards-1

Level 2 Process Checklists L2-Process-1

Level 2 Procedure Checklists L2-Procedures-1

Level 2 Summary L2-Summary-1

CMU/SEI-94-HB-1 L2-1

L2-2 CMU/SEI-94-HB-1

Level 2 Pol icy Checkl is ts

O v e r v i e w

Introduction This section describes the explicit policies found in the Capability MaturityModel at maturity level 2.

The purpose of the policy checklists is to provide:Purpose

• Guidance in identifying which policies are recommended by the CMM at level2.

• Criteria that an organization can use to evaluate its software policies todetermine if they are consistent with the CMM at level 2.

• Information that can be used to develop software policies so that they areconsistent with the CMM at level 2.

Each checklist contains two subsections: the KPA policies and the KPA goals.The table below describes these two subsections of a policy checklist.

Checklistdescription

Subsection Description

Policy checklist This subsection contains criteria that the organizationalpolicy can be evaluated against. These criteria must beaddressed by organizational policy to be consistent withthe CMM.

Policy goals This subsection is a reminder to policy designers andevaluators to keep in mind the KPA goals when developingthe policies for each KPA. The goals can be thought of asthe results of implementing an effective policy.

This section covers the following policies:In this section

Policies See Page

Requirements management policy L2-Policy-2

Software project planning policy L2-Policy-3

Software project tracking and oversight policy L2-Policy-4

Software subcontract management policy L2-Policy-5

Software quality assurance policy L2-Policy-6

Software configuration management policy L2-Policy-7

CMU/SEI-94-HB-1 L2-Policy-1

Requi rements Management (RM) Po l icy

RM policychecklist

The project follows a written organizational policy for managing the systemrequirements allocated to software (L2-2, C1). This policy typically specifiesthat:

Description References

The allocated requirements are documented. (L2-3, C1, 1)

The allocated requirements are reviewed by: (L2-3, C1, 2)

q the software managers, and

q other affected groups.

The software plans, work products, and activities arechanged to be consistent with changes to the allocatedrequirements. (L2-3, C1, 3)

RM policygoals

Implementation of an effective requirements management policy has the followingresults:

Results of Effectively Implementing RM Policy References

System requirements allocated to software are controlled toestablish a baseline for software engineering andmanagement use. (L2-2, G1)

Software plans, products, and activities are kept consistentwith the system requirements allocated to software. (L2-2,G2)

L2-Policy-2 CMU/SEI-94-HB-1

Sof tware Pro jec t P lann ing (SPP) Po l icy

SPP policychecklist

The project follows a written organizational policy for planning a software project( L2-12, C2). This policy typically specifies that:


The system requirements allocated to software are used asthe basis for planning the software project. (L2-12, C2, 1)

The software project's commitments are negotiatedbetween: (L2-12, C2, 2)

q the project manager,

q the project software manager, and

q the other software managers.

Involvement of other engineering groups in the softwareactivities is negotiated with these groups and isdocumented. (L2-13, C2, 3)

Affected groups review the project's: (L2-13, C2, 4)

q software size estimates,

q effort and cost estimates,

q schedules, and

q other commitments.

Senior management reviews all software projectcommitments made to individuals and groups external to theorganization. (L2-13, C2, 5)

The project's software development plan is managed andcontrolled. (L2-13, C2, 6)

SPP policygoals

Implementation of an effective software project planning policy has the followingresults:

Results of Effectively Implementing SPP Policy References

Software estimates are documented for use in planning andtracking the software project. (L2-12, G1)

Software project activities and commitments are plannedand documented. (L2-12, G2)

Affected groups and individuals agree to their commitmentsrelated to the software project. (L2-12, G3)


Sof tware Pro ject Track ing and Overs ight (SPTO)Po l icy

The project follows a written organizational policy for managing the softwareproject (L2-30, C2). This policy typically specifies that:

SPTO policychecklist


A documented software development plan is used andmaintained as the basis for tracking the software project.(L2-30, C2, 1)

The project manager is kept informed of the softwareproject's status and issues. (L2-30, C2, 2)

Corrective actions are taken when the software plan is notbeing achieved, either by adjusting performance or byadjusting the plans. (L2-30, C2, 3)

Changes to the software commitments are made with theinvolvement and agreement of the affected groups. (L2-30,C2, 4)

Senior management reviews all commitment changes andnew software project commitments made to individuals andgroups external to the organization. (L2-31, C2, 5)

Implementation of an effective software project tracking and oversight policy hasthe following results:

SPTO policygoals

Results of Effectively Implementing SPTO Policy References

Actual results and performances are tracked against thesoftware plans. (L2-30, G1)

Corrective actions are taken and managed to closure whenactual results and performance deviate significantly fromthe software plans. (L2-30, G2)

Changes to software commitments are agreed to by theaffected groups and individuals. (L2-30, G3)


Sof tware Subcontract Management (SSM) Pol icy

SSM policychecklist

The project follows a written organizational policy for managing the softwaresubcontract (L2-44, C1). This policy typically specifies that:


Documented standards and procedures are used in selectingsoftware subcontractors and managing the softwaresubcontracts. (L2-45, C1, 1)

The contractual agreements form the basis for managing thesubcontract. (L2-45, C1, 2)

Changes to the subcontract are made with the involvementand agreement of both the prime contractor and thesubcontractor. (L2-45, C1, 3)

SSM policygoals

Implementation of an effective software subcontract management policy has thefollowing results:

Results of Effectively Implementing SSM Policy References

The prime contractor selects qualified softwaresubcontractors. (L2-44, G1)

The prime contractor and the software subcontractor agreeto their commitments to each other. (L2-44, G2)

The prime contractor and the software subcontractormaintain ongoing communications. (L2-44, G3)

The prime contractor tracks the software subcontractor'sactual results and performance against its commitments.(L2-44, G4)


Software Qual i ty Assurance (SQA) Pol icy

SQA policychecklist

The project follows a written organizational policy for implementing softwarequality assurance (L2-60, C1). This policy typically specifies that:


The SQA function is in place on all software projects. (L2-60, C1, 1)

The SQA group has a reporting channel to seniormanagement that is independent of: (L2-61, C1, 2)


q the project's software engineering group, and

q other software-related groups.

Senior management periodically reviews the SQAactivities and results. (L2-61, C1, 3)

SQA policygoals

Implementation of an effective software quality assurance policy has the followingresults:

Results of Effectively Implementing SQA Policy References

Software quality assurance activities are planned. (L2-60,G1)

Adherence of software products and activities to applicablestandards, procedures, and requirements is verifiedobjectively. (L2-60, G2)

Affected groups and individuals are informed of softwarequality assurance activities and results. (L2-60, G3)

Noncompliance issues that cannot be resolved within thesoftware project are addressed by senior management.(L2-60, G4)


Sof tware Conf igurat ion Management (SCM)Po l icy

The project follows a written organizational policy for implementing softwareconfiguration management (L2-72, C1). This policy typically specifies that:

SCM policychecklist


Responsibility for SCM for each project is explicitlyassigned. (L2-72, C1, 1)

SCM is implemented throughout the project's life cycle.(L2-72, C1, 2)

SCM is implemented for externally deliverable softwareproducts, designated internal software work products, anddesignated support tools used inside the project (e.g.,compilers). (L2-72, C1, 3)

The projects establish or have access to a repository forstoring configuration items/units and the associated SCMrecords. (L2-72, C1, 4)

The software baselines and SCM activities are audited on aperiodic basis. (L2-73, C1, 5)

Implementation of an effective software configuration management policy has thefollowing results:

SCM policygoals

Results of Effectively Implementing SCM Policy References

Software configuration management activities are planned.(L2-72, G1)

Selected software work products are identified, controlled,and available. (L2-72, G2)

Changes to identified software work products are controlled.(L2-72, G3)

Affected groups and individuals are informed of the statusand content of software baselines. (L2-72, G4)


Level 2 Standards Checkl ists

O v e r v i e w

Introduction This section describes the recommended content of selected work products in theCMM at maturity level 2.

A standard checklist describes the content of a work product as recommended bythe CMM.

Definition

The purpose of the standards checklists is to provide:Purpose

• Guidance in identifying the contents of standard work products that arerecommended by the CMM at level 2.

• Criteria that an organization can use to evaluate its software standards todetermine if they are consistent with the CMM at level 2.

• Information that can be used to develop software standards that are consistentwith the CMM at level 2.

The standards checklists contain only what is recommended by the CMM, and arenot complete standards in themselves. For example, the standard for the softwaredevelopment plan (SDP) contains only content recommended by the CMM. Othersources for the content of a SDP should also be considered, such as ANSI/IEEEStd 1058.1-1987, DOD-STD-2167, DI-MCCR-80030, etc.

What thestandardschecklists arenot

This section covers the following standards:In this section

Standard KPA See Page

Allocated requirements RM L2-Standards-2

Statement of work SPP L2-Standards-3

Software development plan SPP L2-Standards-4

Contractual agreement SSM L2-Standards-5

Software quality assurance plan SQA L2-Standards-6

Software configuration management plan SCM L2-Standards-7

Note: There are no recommended standards for the software project tracking andoversight kpa.

CMU/SEI-94-HB-1 L2-Standards-1

Allocated Requirements

The following table contains what the CMM describes as the recommendedcontent of allocated requirements:

Standardchecklist

Recommended Content

Nontechnical requirements (i.e., the agreements, conditions, and/orcontractual terms) that affect and determine the activities of the softwareproject. (L2-4, Ab2, 1)

Technical requirements for the software. (L2-4, Ab2, 2)

Acceptance criteria that will be used to validate that the software productssatisfy the allocated requirements. (L2-4, Ab2, 3)

L2-Standards-2 CMU/SEI-94-HB-1

Statement of Work

The following table contains what the CMM describes as the recommendedcontent of the statement of work:

Standardchecklist

Recommended Content

Scope of the work. (L2-14, Ab1, 1.1)

Technical goals and objectives. (L2-14, Ab1, 1.2)

Identification of customers and end users. (L2-14, Ab1, 1.3)

Imposed standards. (L2-14, Ab1, 1.4)

Assigned responsibilities. (L2-14, Ab1, 1.5)

Cost and schedule constraints and goals. (L2-15, Ab1, 1.6)

Dependencies between the software project and other organizations. (L2-15, Ab1, 1.7)

Resource constraints and goals. (L2-15, Ab1, 1.8)

Other constraints and goals for development and/or maintenance. (L2-15,Ab1, 1.9)


Sof tware Development P lan

The following table contains what the CMM describes as the recommendedcontent of the software development plan:

Standardchecklist

Recommended Content

Software project's purpose, scope, goals, and objectives. (L2-19, A7, 1)

Selection of a software life cycle. (L2-19, A7, 2)

Identification of the selected procedures, methods, and standards fordeveloping and/or maintaining the software. (L2-20, A7, 3)

Identification of software work products to be developed. (L2-20, A7, 4)

Size estimates of the software work products and any changes to thesoftware work products. (L2-20, A7, 5)

Estimates of the software project's effort and costs. (L2-20, A7, 6)

Estimated use of critical computer resources. (L2-20, A7, 7)

Software project schedules, including identification of milestones andreviews. (L2-20, A7, 8)

Identification and assessment of the project's software risks. (L2-20, A7, 9)

Plans for the project's software engineering facilities and support tools.(L2-20, A7, 10)


Contractual Agreement

The following table contains what the CMM describes as the recommendedcontent of the contractual agreement between the prime contractor and thesoftware subcontractor:

Standardchecklist

Recommended Content

Terms and conditions. (L2-50, A3, 1)

Statement of work. (L2-50, A3, 2)

Requirements for the products to be developed. (L2-50, A3, 3)

List of dependencies between the subcontractor and the prime contractor.(L2-50, A3, 4)

Subcontracted products to be delivered to the prime contractor. (L2-50, A3,5)

Conditions under which revisions to products are to be submitted. (L2-50,A3, 6)

Acceptance procedures and acceptance criteria to be used in evaluating thesubcontracted products before they are accepted by the prime contractor.(L2-50, A3, 7)

Procedures and evaluation criteria to be used by the prime contractor tomonitor and evaluate the subcontractor's performance. (L2-51, A3, 8)


Software Qual i ty Assurance Plan

The following table contains what the CMM describes as the recommendedcontent of the software quality assurance plan:

Standardchecklist

Recommended Content

Responsibilities and authority of the SQA group. (L2-64, A2, 1)

Resource requirements for the SQA group (including staff, tools, andfacilities). (L2-64, A2, 2)

Schedule and funding of the project's SQA group activities. (L2-64, A2, 3)

The SQA group's participation in establishing the software developmentplan, standards, and procedures for the project. (L2-65, A2, 4)

Evaluations to be performed by the SQA group. (L2-65, A2, 5)

Audits and reviews to be conducted by the SQA group. (L2-65, A2, 6)

Project standards and procedures used as the basis for the SQA group'sreviews and audits. (L2-65, A2, 7)

Procedures for documenting and tracking noncompliance issues to closure.(L2-65, A2, 8)

Documentation that the SQA group is required to produce. (L2-65, A2, 9)

Method and frequency of providing feedback to the software engineeringgroup and other software-related groups on SQA activities. (L2-65, A2, 10)


Software Conf igurat ion Management Plan

The following table contains what the CMM describes as the recommendedcontent of the software configuration management plan:

Standardchecklist

Recommended Content

SCM activities to be performed, the schedule of activities, the assignedresponsibilities, and the resources required (including staff, tools, andcomputer facilities). (L2-77, A2, 1)

SCM requirements and activities to be performed by the softwareengineering group and other software-related groups. (L2-77, A2, 2)


Level 2 Process Checkl is ts

O v e r v i e w

The purpose of the process checklists is to provide:Sectionpurpose

• Guidance in identifying which processes are required by the CMM at level 2.

• Criteria that an organization can use to evaluate its software processes todetermine if they are consistent with the CMM at level 2.

• Information that can be used to develop software processes that are consistentwith the CMM at level 2.

This section contains checklists for the following key process areas:In this section

Key Process Area See Page

Requirements Management L2-Process-3

Software Project Planning L2-Process-23

Software Project Tracking & Oversight L2-Process-59

Software Subcontract Management L2-Process-97

Software Quality Assurance L2-Process-129

Software Configuration Management L2-Process-155

CMU/SEI-94-HB-1 L2-Process-1

L2-Process-2 CMU/SEI-94-HB-1

Requi rements Management (RM) Process

R M P r o c e s s - O v e r v i e w

The purpose of Requirements Management is to establish a commonunderstanding between the customer and the software project of the customer'srequirements that will be addressed by the software project. (L2-1)

RM processpurpose

Requirements Management involves establishing and maintaining an agreementwith the customer on the requirements for the software project. This agreement isreferred to as the "system requirements allocated to the software." The "customer"may be interpreted as the system engineering group, the marketing group, anotherinternal organization, or an external customer. The agreement covers both thetechnical and nontechnical (e.g., delivery dates) requirements. The agreementforms the basis for estimating, planning, performing, and tracking the softwareproject's activities throughout the software life cycle.

The allocation of the system requirements to software, hardware, and other systemcomponents (e.g., humans) may be performed by a group external to the softwareengineering group (e.g., the system engineering group), and the softwareengineering group may have no direct control of this allocation. Within theconstraints of the project, the software engineering group takes appropriate stepsto ensure that the system requirements allocated to software, which they areresponsible for addressing, are documented and controlled.

To achieve this control, the software engineering group reviews the initial andrevised system requirements allocated to software to resolve issues before they areincorporated into the software project. Whenever the system requirementsallocated to software are changed, the affected software plans, work products, andactivities are adjusted to remain consistent with the updated requirements. (L2-1)

RM processdescription



R M P r o c e s s - O v e r v i e w , Continued

Sectionoverview

The table below contains a description and the location of each checklist for thiskey process area.

Checklist Description Page

Roles List of roles participating in processactivities.

L2-Process-5

Entry Criteria Description of when the process can start. L2-Process-8

Inputs Description of the work products used bythe process.

L2-Process-9

Activities Description of the activities of theprocess.

L2-Process-10

Outputs Description of the work products producedby the process.

L2-Process-12

Exit Criteria Description of when the process iscomplete.

L2-Process-13

Reviews andAudits

List of reviews and audits. L2-Process-16


List of work products to be managed andcontrolled.

L2-Process-18

Measurements Description of process measurements. L2-Process-19


List of the activities to be completedaccording to a documented procedure.

L2-Process-20

Training List of training. L2-Process-21

Tools List of tools. L2-Process-22


RM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in therequirements management process.

Role Activities Participated in... Reference

Affectedgroups

q The allocated requirements arereviewed by: (L2-3, C1, 2)



q Commitments resulting from theallocated requirements are negotiatedwith the affected groups. (L2-6, A1,4)

q Changes to commitments within theorganization are negotiated with theaffected groups. (L2-7, A3, 1.2)

q Changes that need to be made to thesoftware plans, work products, andactivities resulting from changes to theallocated requirements are: (L2-8, A3,2)

q identified,

q evaluated,

q assessed for risk,

q documented,

q planned,

q communicated to the affectedgroups and individuals, and

q tracked to completion.

q Changes to commitments resultingfrom changes to the allocatedrequirements are negotiated with theaffected groups. (L2-10, V3, 3)



RM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in therequirements management process, continued from the previous page.


(Affected)individuals

q Individuals who have experience andexpertise in the application domain andin software engineering are assigned tomanage the allocated requirements.(L2-5, Ab3, 1)

q Changes that need to be made to thesoftware plans, work products, andactivities resulting from changes to theallocated requirements are: (L2-8, A3,2)

q identified,

q evaluated,


q documented,

q planned,



Groupresponsiblefor analyzingand allocatingsystemrequirements

Any allocated requirements identified ashaving potential problems are reviewedwith the group responsible for analyzingand allocating system requirements, andnecessary changes are made. (L2-6, A1,3)

Individualsand groupsexternal to theorganization

Changes to commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement. (L2-7, A3, 1.1)

Projectmanager

The activities for managing the allocatedrequirements are reviewed with the projectmanager on both a periodic and event-driven basis. (L2-9, V2)



RM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in therequirements management process, continued from the previous page.


Seniormanagement

q Changes to commitments made toindividuals and groups external tothe organization are reviewed withsenior management. (L2-7, A3, 1.1)

q The activities for managing theallocated requirements are reviewedwith senior management on aperiodic basis. (L2-9, V1)

Softwareengineeringgroup

q Members of the software engineeringgroup and other software-relatedgroups are trained to perform theirrequirements management activities.(L2-5, Ab4)

q The software engineering groupreviews the allocated requirementsbefore they are incorporated into thesoftware project. (L2-5, A1)

q The software engineering group usesthe allocated requirements as the basisfor software plans, work products, andactivities. (L2-6, A2)

q The allocated requirements arereviewed, and problems are resolvedbefore the software engineeringgroup commits to them. (L2-10, V3,1)

Softwaremanager

The allocated requirements are reviewedby: (L2-3, C1, 2)



Software-relatedgroups

Members of the software engineering groupand other software-related groups aretrained to perform their requirementsmanagement activities. (L2-5, Ab4)

SQA group The software quality assurance groupreviews and/or audits the activities andwork products for managing the allocatedrequirements and reports results. (L2-9,V3)


RM Process - Entry Cr i ter ia

Input-basedentry criteria

The CMM recommends that inputs satisfy the states described in the table belowbefore entering the requirements management process.

Input State References


are documented. (L2-3, C1, 1)

The CMM recommends that the conditions described in the table below besatisfied before entering the requirements management process.

General entrycriteria

Condition References

The project follows a written organizational policy formanaging the system requirements allocated to software.(L2-2, C1)

[Refer to Level 2 Policies for additional informationregarding RM policy.]

For each project, responsibility is established for analyzingthe system requirements and allocating them to hardware,software, and other system components. (L2-3, Ab1)

This responsibility covers:

q Managing and documenting the system requirementsand their allocation throughout the project's life.

q Effecting changes to the system requirements and theirallocation.

Adequate resources and funding are provided for managingthe allocated requirements. (L2-5, Ab3)

Individuals who have experience and expertise in theapplication domain and in software engineering are assignedto manage the allocated requirements. (L2-5, Ab3, 1)

Tools to support the activities for managing requirementsare made available. (L2-5, Ab3, 2)

Members of the software engineering group and othersoftware-related groups are trained to perform theirrequirements management activities. (L2-5, Ab4)


RM Process - Inputs

Inputs The table below lists the recommended inputs to the requirements managementprocess.


Allocated requirements. (L2-2, C1)


Changes to the allocated requirements.(L2-4, Ab1, 2)

Changes to the system requirements. (L2-4, Ab1, 2)

Existing commitments. (L2-7, A3, 1)

Software activities. (L2-3, C1, 3)

Software plans. (L2-3, C1, 3)

Software work products. (L2-3, C1, 3)

System requirements. (L2-3, Ab1)


RM Process - Act iv i t ies

Activities The table below lists the recommended activities for the requirementsmanagement process.

Activities References

The software engineering group reviews allocatedrequirements before they are incorporated into the softwareproject. (L2-5, A1)

[Refer to RM Process Reviews and Audits for additionalinformation.]

Commitments resulting from the allocated requirements arenegotiated with the affected groups. (L2-6, A1,4)

The software engineering group uses the allocatedrequirements as the basis for software plans, work products,and activities. (L2-6, A2)

Changes to the allocated requirements are reviewed andincorporated into the software project. (L2-7, A3)

q The impact to existing commitments is assessed andchanges are negotiated as appropriate.

q Changes to commitments made to individuals andgroups external to the organization are reviewedwith senior management.

q Changes to commitments within the organizationare negotiated with the affected groups.

q Changes that need to be made to the software plans,work products, and activities resulting from changes tothe allocated requirements are:

q identified,

q evaluated,


q documented,

q planned,

q communicated to the affected groups andindividuals, and


Measurements are made and used to determine the status ofthe activities for managing the allocated requirements. (L2-8, M1)

The activities for managing requirements are reviewed withsenior management on a periodic basis. (L2-9, V1)



RM Process - Act iv i t ies , Continued

Activities,continued

The table below lists the recommended activities for the requirementsmanagement process, continued from the previous page.


The activities for managing the allocated requirements arereviewed with the project manager on both a periodic andevent-driven basis. (L2-9, V2)

The software quality assurance group reviews and/oraudits the activities and work products for managing theallocated requirements and reports the results. (L2-9, V3)

[Refer to RM Process Reviews and Audits for additionalinformation.]


RM Process - Outputs

Outputs The table below lists the recommended outputs produced by the requirementsmanagement process.

Output Org. Output References

Allocated requirements. (L2-5, A1)

Changes that need to be made to thesoftware plans, work products, andactivities resulting from changes to theallocated requirements. (L2-8, A3, 2)

Changes to allocated requirements. (L2-7,A3)

Changes to commitments made toindividuals and groups external to theorganization. (L2-7, A3, 1.1)

Changes to commitments within theorganization. (L2-7, A3, 1.2)

Commitments resulting from the allocatedrequirements. (L2-6, A1, 4)

Impact to existing commitments. (L2-7,A3, 1)

Measurements. (L2-8, M1)

Software activities. (L2-10, V3, 2)

Software plans. (L2-10, V3, 2)

Software requirements. (L2-7, A2, 3)

Software work products. (L2-10, V3, 2)


RM Process - Ex i t Cr i ter ia

Output-basedexit criteria

The CMM recommends that outputs satisfy the states described in the table belowto exit the requirements management process.

Output State References


q are documented. (L2-3, C1, 1)

q are reviewed by: (L2-3, C1, 2)



q (that are incomplete andmissing) are identified. (L2-5,A1, 1)

q are reviewed to determinewhether they are: (L2-6, A1, 2)

q feasible and appropriate toimplement in software,

q clearly and properly stated,

q consistent with each other,and

q testable.

q identified as having potentialproblems are reviewed with thegroup responsible foranalyzing and allocatingsystem requirements, andnecessary changes are made.(L2-6, A1, 3)

q are managed and controlled.(L2-7, A2, 1)

q are the basis for the softwaredevelopment plan. (L2-7, A2, 2)

q are the basis for developing thesoftware requirements. (L2-7,A2, 3)

q are reviewed, and problems areresolved before the softwareengineering group commits tothem. (L2-10, V3, 1)

Changes to allocatedrequirements

q are reviewed. (L2-7, A3)

q are incorporated into thesoftware project. (L2-7, A3)


RM Process - Ex i t Cr i ter ia , Continued

Output-basedexit criteria,continued

The CMM recommends that outputs satisfy the states described in the table belowto exit the requirements management process, continued from the previous page.


Changes tocommitmentsresulting fromchanges to theallocatedrequirements

are negotiated with the affectedgroups. (L2-10, V3, 3)

Changes tocommitments madeto individuals andgroups external tothe organization

are reviewed with seniormanagement. (L2-7, A3, 1.1)

Changes tocommitments withinthe organization

are negotiated with the affectedgroups. (L2-7, A3, 1.2)

Changes that need tobe made to thesoftware plans, workproducts, andactivities resultingfrom changes to theallocatedrequirements

are: (L2-8, A3, 2)

q identified,

q evaluated,


q documented,

q planned,



Commitmentsresulting from theallocatedrequirements

are negotiated with the affectedgroups. (L2-6, A1, 4)

Impact to existingcommitments(resulting fromchanges to theallocatedrequirements)

is assessed. (L2-7, A3, 1)

Measurements (todetermine the statusof the activities formanaging theallocatedrequirements)

q are made. (L2-8, M1)

q are used. (L2-8, M1)


RM Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the requirements management process, continued from the previous page.


Software plans q are changed to be consistentwith changes to the allocatedrequirements. (L2-3, C1, 3)

q are appropriately revised whenthe allocated requirementschange. (L2-10, V3, 2)

Software workproducts

q are changed to be consistentwith changes to the allocatedrequirements. (L2-3, C1, 3)

q are appropriately revised whenthe allocated requirementschange. (L2-10, V3, 2)

The CMM recommends that the conditions described in the table below besatisfied to exit the requirement management process.

General exitcriteria


The activities for managing the allocated requirements arereviewed with senior management on a periodic basis.(L2-9, V1)

The activities for managing the allocated requirements arereviewed with the project manager on both a periodic andevent-driven basis. (L2-9, V2)

The software quality assurance group reviews and/oraudits the activities and work products for managing theallocated requirements and reports the results. (L2-9, V3)

The allocated requirements are reviewed, and problems areresolved before the software engineering group commitsto them. (L2-10, V3, 1)


RM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the requirementsmanagement process.

Review or Audit ReviewParticipants

References

Allocated requirements are reviewed by:(L2-3, C1, 2)



Softwaremanagers

Affectedgroups

The software engineering group reviewsallocated requirements before they areincorporated into the software project.(L2-5, A1)

q Incomplete and missing allocatedrequirements are identified.

q The allocated requirements arereviewed to determine whether theyare:


q clearly and properly stated,

q consistent with each other, and

q testable.

q Any allocated requirements identifiedas having potential problems arereviewed with the group responsiblefor analyzing and allocating systemrequirements, and necessary changesare made.


Groupresponsiblefor analyzingand allocatingsystemrequirements

Changes to the allocated requirements arereviewed and incorporated into thesoftware project. (L2-7, A3)

Not specifiedin CMM

Changes to commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement. (L2-7, A3, 1.1)

Seniormanagement



RM Process - Rev iews and Audi ts , Continued

Reviews andaudits,continued

The table below lists the recommended reviews and audits for the requirementsmanagement process, continued from the previous page.


References

The activities for managing requirementsare reviewed with senior management ona periodic basis. (L2-9, V1)

Seniormanagement

The activities for managing the allocatedrequirements are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-9, V2)

Projectmanager

The software quality assurance groupreviews and/or audits the activities andwork products for managing the allocatedrequirements and reports the results. (L2-9, V3)

At a minimum, these reviews and/or auditsverify that:

q The allocated requirements arereviewed, and problems are resolvedbefore the software engineeringgroup commits to them.

q The software plans, work products, andactivities are appropriately revisedwhen the allocated requirementschange.

q Changes to commitments resultingfrom changes to the allocatedrequirements are negotiated with theaffected groups.

SQA group


Affectedgroups


RM Process - Work Products Managed andContro l led

Work productsmanaged andcontrolled

The table below lists the work products that are recommended to be managed andcontrolled during the requirements management process.

Work Products Managed and Controlled References

Allocated requirements. (L2-7, A2, 1)


RM Process - Measurements

Measurements The table below describes the recommended measurements for the requirementsmanagement process.

Measurements References

Measurements are made and used to determine the status ofthe activities for managing the allocated requirements. (L2-8, M1)

Examples of measurements include:

q Status of each of the allocated requirements.

q Change activity for the allocated requirements.

q Cumulative number of changes to the allocatedrequirements, including total number of changesproposed, open, approved, and incorporated into thesystem baseline.


RM Process - Documented Procedures

Documentedprocedures

The CMM does not recommend that any activities be performed according to adocumented procedure for the requirements management process.


RM Process - T ra in ing

Training The table below lists the training recommended for the requirements managementprocess.

Training References

Members of the software engineering group and othersoftware-related groups are trained to perform theirrequirements management activities. (L2-5, Ab4)


RM Process - Too ls

Tools The table below lists the tools recommended for the requirements managementprocess.

Tools References

Tools to support the activities for managing requirements.(L2-5, Ab3, 2)

Examples of support tools include:

q spreadsheet programs,

q tools for configuration management,

q tools for traceability, and

q tools for test management.


Sof tware Pro jec t P lanning (SPP) Process

S P P P r o c e s s - O v e r v i e w

The purpose of Software Project Planning is to establish reasonable plans forperforming the software engineering and for managing the software project.(L2-11)

SPP processpurpose

Software Project Planning involves developing estimates for the work to beperformed, establishing the necessary commitments, and defining the plan toperform the work.

The software planning begins with a statement of the work to be performed andother constraints and goals that define and bound the software project (thoseestablished by the practices of the Requirements Management key process area).The software planning process includes steps to estimate the size of the softwarework products and the resources needed, produce a schedule, identify and assesssoftware risks, and negotiate commitments. Iterating through these steps may benecessary to establish the plan for the software project (i.e., the softwaredevelopment plan).

This plan provides the basis for performing and managing the software project'sactivities and addresses the commitments to the software project's customeraccording to the resources, constraints, and capabilities of the software project.(L2-11)

SPP processdescription



S P P P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L2-Process-25



L2-Process-36


L2-Process-37


L2-Process-40


L2-Process-42

Reviews andAudits




L2-Process-53




L2-Process-55




SPP Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware project planning process.


Affectedgroups

q Affected groups review the softwareproject's: (L2-13, C2, 4)



q schedules, and


q The statement of work is reviewed by:(L2-15, Ab1, 2)


q the project software manager,

q the other software managers, and


q The software engineering groupparticipates with other affected groupsin the overall project planningthroughout the project's life. (L2-17,A3)

q The software development plan isreviewed by: (L2-19, A6, 4)





q The plans for the project’s softwareengineering facilities and support toolsare reviewed by all affected groups.(L2-25, A14, 3)

q A summary report from each reviewwith senior management is preparedand distributed to the affected groupsand individuals. (L2-26, V1, 5)

Role continues on the next page



SPP Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware project planning process, continued from the previous page.


Affectedgroups,continued

q The activities for software projectplanning are reviewed with the projectmanager on both a periodic and event-driven basis. (L2-26, V2)

q Affected groups are represented.

q A summary report from each reviewwith the project manager is preparedand distributed to the affected groupsand individuals. (L2-27, V2, 7)

Affectedindividuals

q A summary report from each reviewwith senior management is preparedand distributed to the affected groupsand individuals. (L2-26, V1, 5)

q A summary report from each reviewwith the project manager is preparedand distributed to the affected groupsand individuals. (L2-27, V2, 7)

Engineeringgroups

q Involvement of other engineeringgroups in the software activities isnegotiated with these groups and isdocumented. (L2-13, C2, 3)

q Plans for software-related groups andother engineering groups involved inthe activities of the softwareengineering group are negotiated withthose groups, the support efforts arebudgeted, and the agreements aredocumented. (L2-18, A6, 2)

q Plans for involvement of the softwareengineering group in the activities ofother software-related groups and otherengineering groups are negotiatedwith those groups, the support effortsare budgeted, and the agreements aredocumented. (L2-19, A6, 3)




Roles,continued



Individuals q Where feasible, experiencedindividuals, who have expertise in theapplication domain of the softwareproject being planned, are available todevelop the software development plan.(L2-16, Ab3, 1)

q The software managers, softwareengineers, and other individualsinvolved in the software projectplanning are trained in the softwareestimating and planning proceduresapplicable to their areas ofresponsibility. (L2-16, Ab4)


q Senior management reviews allsoftware project commitments made toindividuals and groups external tothe organization. (L2-13, C2, 5)

q Software project commitments made toindividuals and groups external tothe organization are reviewed withsenior management according to adocumented procedure. (L2-17, A4)




Roles,continued



Projectmanager

q The software project's commitmentsare negotiated between: (L2-12, C2,2)














q The activities for software projectplanning are reviewed with the projectmanager on both a periodic and event-driven basis. (L2-26, V2)




Roles,continued



Projectsoftwaremanager

q A project software manager isdesignated to be responsible fornegotiating commitments anddeveloping the project's softwaredevelopment plan. (L2-12, C1)



q the project software manager,and







q The project software manager,directly or by delegation, coordinatesthe project's software planning. (L2-15,Ab2, 1)









Roles,continued



Seniormanagement

q Senior management reviews allsoftware project commitments made toindividuals and groups external to theorganization. (L2-13, C2, 5)

q Software project commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement according to adocumented procedure. (L2-17, A4)

q The activities for software projectplanning are reviewed with seniormanagement on a periodic basis. (L2-26, V1)


q The software engineering groupparticipates on the project proposalteam. (L2-16, A1)

q The software engineering group isinvolved in: (L2-17, A1, 1)

q proposal preparation andsubmission,

q clarification discussions andsubmissions, and

q negotiations of changes tocommitments that affect thesoftware project.

q The software engineering groupreviews the project's proposedcommitments. (L2-17, A1, 2)





Roles,continued



Softwareengineeringgroup,continued

q The software engineering groupparticipates with other affected groupsin the overall project planningthroughout the project's life. (L2-17,A3)

q The software engineering groupreviews the project-level plans. (L2-17, A3, 1)

q Plans for software-related groups andother engineering groups involved inthe activities of the softwareengineering group are negotiatedwith those groups, the support effortsare budgeted, and the agreements aredocumented. (L2-18, A6, 2)

q Plans for involvement of the softwareengineering group in the activities ofother software-related groups and otherengineering groups are negotiated withthose groups, the support efforts arebudgeted, and the agreements aredocumented. (L2-19, A6, 3)

Softwareengineers

The software managers, softwareengineers, and other individuals involvedin the software project planning are trainedin software estimating and planningprocedures applicable to their areas ofresponsibility. (L2-16, Ab4)




Roles,continued



Softwaremanager










q Responsibilities for the software workproducts and activities are partitionedand assigned to software managers ina traceable, accountable manner. (L2-15, Ab2, 2)

q The software managers, softwareengineers, and other individualsinvolved in the software projectplanning are trained in softwareestimating and planning proceduresapplicable to their areas ofresponsibility. (L2-16, Ab4)









Roles,continued




q Plans for software-related groups andother engineering groups involved inthe activities of the softwareengineering group are negotiated withthose groups, the support efforts arebudgeted, and the agreements aredocumented. (L2-18, A6, 2)

q Plans for involvement of the softwareengineering group in the activities ofother software-related groups andother engineering groups are negotiatedwith those groups, the support effortsare budgeted, and the agreements aredocumented. (L2-19, A6, 3)

SQA group The software quality assurance groupreviews and/or audits the activities andwork products for software project planningand reports the results. (L2-27, V3)


SPP Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the software project planning process.


Cost data q are from the organization’sprojects when possible. (L2-22,A10, 2.1)

q take into account the effort andsignificant costs that go intomaking the software workproducts. (L2-22, A10, 2.2)

Historical data are used where available. (L2-21,A9, 3)

Productivity data q are from the organization’sprojects when possible. (L2-22,A10, 2.1)

q take into account the effort andsignificant costs that go intomaking the software workproducts. (L2-22, A10, 2.2)

Statement of work q is documented. (L2-14, Ab1)

q is approved. (L2-14, Ab1)

q exists for the software project.(L2-14, Ab1)

q is reviewed by: (L2-15, Ab1, 2)


q the project softwaremanager,

q the other softwaremanagers, and


q is managed and controlled. (L2-15, Ab1, 3)


SPP Process - Entry Cr i ter ia , Continued


The CMM recommends that the conditions described in the table below besatisfied before entering the software project planning process.


A project software manager is designated to beresponsible for negotiating commitments and developing theproject's software development plan. (L2-12, C1)

The project follows a written organizational policy forplanning a software project. (L2-12, C2)

[Refer to Level 2 Policies for additional informationregarding SPP policy.]

Responsibilities for developing the software developmentplan are assigned. (L2-15, Ab2)

Responsibilities for the software work products andactivities are partitioned and assigned to softwaremanagers in a traceable, accountable manner. (L2-15,Ab2, 2)

Adequate resources and funding are provided for planningthe software project. (L2-16, Ab3)

Where feasible, experienced individuals who haveexpertise in the application domain of the software projectbeing planned are available to develop the softwaredevelopment plan. (L2-16, Ab3, 1)

Tools to support the software project planning activities aremade available. (L2-16, Ab3, 2)

The software managers, software engineers, and otherindividuals involved in the software project planning aretrained in the software estimating and planning proceduresapplicable to their areas of responsibility. (L2-16, Ab4)

Software project planning is initiated in the early stages of,and in parallel with, the overall project planning. (L2-17,A2)


SPP Process - Inputs

Inputs The table below lists the recommended inputs to the software project planningprocess.


Allocated requirements. (L2-18, A6, 1.4)


Cost data. (L2-22, A10, 2.1)

Customer's standards. (L2-18, A6, 1.1)

Historical data (where available). (L2-21,A9, 3)

Productivity data (historical and/orcurrent). (L2-22, A10, 2)

Project proposal. (L2-16, A1)

Project's standards. (L2-18, A6, 1.2)

Proposed commitments. (L2-17, A1, 2)

Statement of work. (L2-14, Ab1)



SPP Process - Act iv i t ies

Activities The table below lists the recommended activities for the software project planningprocess.


The software engineering group participates on theproject proposal team. (L2-16, A1)

q The software engineering group is involved in: (L2-17, A1, 1)

q proposal preparation and submission,

q clarification discussions and submissions, and

q negotiations of changes to commitments that affectthe software project.

q The software engineering group reviews the project'sproposed commitments. (L2-17, A1, 2)

The software engineering group reviews the project-levelplans. (L2-17, A3, 1)

Software project commitments made to individuals andgroups external to the organization are reviewed withsenior management according to a documented procedure.(L2-17, A4)

A software life cycle with predefined stages of manageablesize is identified or defined. (L2-17, A5)

The project's software development plan is developedaccording to a documented procedure. (L2-18, A6)

[Refer to Level 2 Procedure Checklists for additionalinformation.]

The plan for the software project is documented. (L2-19,A7)

Software work products that are needed to establish andmaintain control of the software project are identified. (L2-20, A8)

Estimates for the size of the software work products (orchanges to the size of software work products) are derivedaccording to a documented procedure. (L2-21, A9)


Estimates for the software project's effort and costs arederived according to a documented procedure. (L2-22, A10)



SPP Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software project planningprocess, continued from the previous page.


Estimates for critical computer resources are derivedaccording to a documented procedure. (L2-23, A11)


The project's software schedule is derived according to adocumented procedure. (L2-23, A12)


The software risks associated with the cost, resource,schedule, and technical aspects of the project are identified,assessed, and documented. (L2-24, A13)

q The risks are analyzed and prioritized based on theirpotential impact to the project.

q Contingencies for the risks are identified.

Plans for the project's software engineering facilities andsupport tools are prepared. (L2-25, A14)

q Responsibilities are assigned and commitments arenegotiated to procure or develop these facilities andsupport tools. (L2-25, A14, 2)

q The plans are reviewed by all affected groups. (L2-25,A14, 3)

Software planning data are recorded. (L2-25, A15)

q Information recorded includes the estimates and theassociated information needed to reconstruct theestimates and assess their reasonableness. (L2-25, A15,1)

Measurements are made and used to determine the status ofthe software planning activities. (L2-25, M1)

The activities for software project planning are reviewedwith senior management on a periodic basis. (L2-26, V1)

[Refer to SPP Process Reviews and Audits for additionalinformation.]



SPP Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software project planningprocess continued from the previous page.


The activities for software project planning are reviewedwith the project manager on both a periodic and event-driven basis. (L2-26, V2)


The software quality assurance group reviews and/oraudits the activities and work products for software planningand reports the results. (L2-27, V3)



SPP Process - Outputs

Outputs The table below lists the recommended outputs produced by the software projectplanning process.

Output Org. Outputs References

Action items resulting from reviews withsenior management. (L2-26, V1, 4)

Action items resulting from reviews withthe project manager. (L2-27, V2, 6)

Assumptions made in deriving theestimates for the software project's effortand costs. (L2-23, A10, 4)

Assumptions made in deriving the project'ssoftware schedule. (L2-24, A12, 5)

Contingencies for the risks associated withthe cost, resource, schedule, and technicalaspects of the project. (L2-24, A13, 2)

Distributions of effort, staffing, and costestimates over the software life cycle.(L2-23, A10, 3.3)

Estimates for the project's criticalcomputer resources. (L2-23, A11)

Estimates for the size of the software workproducts (or changes to the size ofsoftware work products). (L2-21, A9)

Estimates for the software project's effortand costs. (L2-22, A10)

Estimates of capacity requirements for theproject's software engineering facilitiesand support tools. (L2-25, A14, 1)

Estimates of the critical computerresources for the project. (L2-23, A11, 3)

Measurements to determine the status ofthe software planning activities. (L2-25,M1)

Plans for involvement of the softwareengineering group in the activities ofother software-related groups and otherengineering groups. (L2-19, A6, 3)

Plans for software-related groups andother engineering groups involved in theactivities of the software engineeringgroup. (L2-18, A6, 2)


SPP Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the software projectplanning process, continued from the previous page.


Plans for the project's software engineeringfacilities and support tools. (L2-25, A14)

Project's software development plan. (L2-15, Ab2)

[Refer to Level 2 Standards for additionalinformation regarding the softwaredevelopment plan.]

Project's software schedule. (L2-23, A12)

Size estimating assumptions. (L2-21, A9,4)

Software life cycle. (L2-17, A5)

Software planning data. (L2-25, A15)

Software project commitments. (L2-17,A4)

Software risks associated with the cost,resource, schedule, and technical aspectsof the project. (L2-24, A13)

Software work products that are needed toestablish and maintain control of thesoftware project. (L2-20, A8)

Sources and rationale for productivity dataused for estimating the software project'seffort and costs. (L2-22, A10, 2)

Summary report from each review withsenior management. (L2-26, V1, 5)

Summary report from each review with theproject manager. (L2-27, V2, 7)

Time phasing of activities. (L2-22, A10,3.2)


SPP Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software project planning process.


Action itemsresulting fromreviews with seniormanagement

q are assigned. (L2-26, V1, 4)

q are reviewed. (L2-26, V1, 4)

q are tracked to closure. (L2-26,V1, 4)

Action itemsresulting fromreviews with theproject manager




Assumptions made inderiving theestimates for thesoftware project'scosts

q are documented. (L2-23, A10,4)

q are reviewed. (L2-23, A10, 4)

q are agreed to. (L2-23, A10, 4)

Assumptions made inderiving theestimates for thesoftware project'seffort




Assumptions made inderiving the(project's software)schedule

are documented. (L2-24, A12, 5)

Contingencies for therisks (associated withthe cost, resource,schedule, andtechnical aspects ofthe project)

are identified. (L2-24, A13, 2)

Critical computerresources for theproject


Distributions of costestimates over thesoftware life cycle

are prepared. (L2-23, A10, 3.3)

Distributions of effortestimates over thesoftware life cycle



SPP Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software project planning process, continued from the previous page.


Distributions ofstaffing estimatesover the software lifecycle


Estimates for theproject's criticalcomputer resources

q are derived according to adocumented procedure. (L2-23,A11)

q are related to the estimates of:(L2-23, A11, 2)

q the size of the software workproducts,

q the operational processingload, and

q the communications traffic.




Estimates for the sizeof the software workproducts (or changesto the size ofsoftware workproducts)


q are made for all major softwarework products and activities.(L2-21, A9, 1)

q are documented. (L2-21, A9, 5)









Estimates for thesoftware project'scosts


q are related to the size estimatesof the software work products (orthe size of the changes). (L2-22,A10, 1)

q are based on past experience.(L2-22, A10, 3)

Estimates for thesoftware project'seffort


q are related to the size estimatesof the software work products (orthe size of the changes). (L2-22,A10, 1)

q are based on past experience.(L2-22, A10, 3)

Estimates of capacityrequirements for (theproject’s softwareengineering)facilities and supporttools

are based on the size estimates ofthe software work products and othercharacteristics. (L2-25, A14, 1)

Measurements (todetermine the statusof the softwareplanning activities)

are made. (L2-25, M1)

are used. (L2-25, M1)

Plans forinvolvement of thesoftwareengineering groupin the activities ofother software-related groups andother engineeringgroups

are negotiated with those groups, thesupport efforts are budgeted, and theagreements are documented. (L2-19,A6, 3)


Plans for software-related groups andother engineeringgroups involved inthe activities of thesoftwareengineering group

are negotiated with those groups, thesupport efforts are budgeted, and theagreements are documented. (L2-18,A6, 2)







Plans for theproject’s softwareengineering facilitiesand support tools

q are prepared. (L2-25, A14)

q are reviewed by all affectedgroups. (L2-25, A14, 3)


q is managed and controlled. (L2-13, C2, 6)

q is developed according to adocumented procedure. (L2-18,A6)

q is based on and conforms to:(L2-18, A6, 1)

q the customer's standards, asappropriate;

q the project's standards;

q the approved statement ofwork; and

q the allocated requirements.

q is reviewed by: (L2-19, A6, 4)


q the project softwaremanager,

q the other softwaremanagers, and









Project's softwareschedule

q is derived according to adocumented procedure. (L2-23,A12)

q is related to: (L2-24, A12, 1)

q the size estimate of thesoftware work products (orthe size of changes), and

q the software effort and costs.

q is based on past experience.(L2-24, A12, 2)

q Similar projects are usedwhen possible.

q accommodates the imposedmilestone dates, criticaldependency dates, and otherconstraints. (L2-24, A12, 3)

q activities are of appropriateduration and the milestones areof appropriate time separation tosupport accuracy in progressmeasurement. (L2-24, A12, 4)

q is documented. (L2-24, A12, 6)

q is reviewed. (L2-24, A12, 6)

q is agreed to. (L2-24, A12, 6)

Results (of SQAgroup reviews and/oraudits of theactivities and workproducts for softwareproject planning)

are reported. (L2-27, V3)

Size estimatingassumptions


Software life cycle q is identified or defined. (L2-17,A5)

q has predefined stages ofmanageable size. (L2-17, A5)






Software planningdata

q are recorded. (L2-25, A15)

q Information recordedincludes the estimates andthe associated informationneeded to reconstruct theestimates and assess theirreasonableness. (L2-25,A15, 1)


Software project'scommitments

q are negotiated between: (L2-12,C2, 2)


q the project softwaremanager, and

q the other softwaremanagers.

q made to individuals andgroups external to theorganization are reviewed withsenior management accordingto a documented procedure. (L-17, A4)

Software risksassociated with thecost, resource,schedule, andtechnical aspects ofthe project

q are identified. (L2-24, A13)

q are assessed. (L2-24, A13)

q are documented. (L2-24, A13)

q are analyzed. (L2-24, A13, 1)

q are prioritized based on theirpotential impact to the project.(L2-24, A13, 1)


are decomposed to the granularityneeded to meet the estimatingobjectives. (L2-21, A9, 2)







Software workproducts that areneeded to establishand maintain controlof the softwareproject

are identified. (L2-20, A8)

Sources forproductivity data thatare used to estimatethe software project'seffort and costs


Rationale forproductivity data thatare used to estimatethe software project'seffort and costs


Staffing estimates are based on past experience. (L2-22, A10, 3)

Summary report fromeach meeting withsenior management

q is prepared. (L2-26, V1, 5)

q is distributed to the affectedgroups and individuals. (L2-26, V1, 5)

Summary report fromeach meeting withthe project manager



Time phasing ofactivities

is derived. (L2-22, A10, 3.2)





The CMM recommends that the conditions described in the table below besatisfied to exit the software project planning process.


The system requirements allocated to software are used asthe basis for planning the software project. (L2-12, C2, 1)

Involvement of other engineering groups in the softwareactivities is negotiated with these groups and isdocumented. (L2-13, C2, 3)

Affected groups review the project's: (L2-13, C2, 4)



q schedules, and


Senior management reviews all software projectcommitments made to individuals and groups external tothe organization. (L2-13, C2, 5)

The software engineering group participates on theproject proposal team. (L2-16, A1)

The software engineering group reviews the project’sproposed commitments. (L2-17, A1, 2)

The software engineering group participates with otheraffected groups in the overall project planning throughoutthe project’s life. (L2-17, A3)

The software engineering group reviews the project-levelplans. (L2-17, A3, 1)

Productivity data (historical and/or current) are used for theestimates when available. (L2-22, A10, 2)

Responsibilities are assigned and commitments arenegotiated to procure or develop the project's facilities andtools. (L2-25, A14, 2)

The activities for software project planning are reviewedwith senior management on a periodic basis. (L2-26, V1)

The activities for software project planning are reviewedwith the project manager on both a periodic and event-driven basis. (L2-26, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software projectplanning, and reports the results. (L2-27, V3)


SPP Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the software projectplanning process.


References

Affected groups review the softwareproject's: (L2-13, C2, 4)



q schedules, and


Affectedgroups

Senior management reviews all softwareproject commitments made to individualsand groups external to the organization.(L2-13, C2, 5)

Seniormanagement

The statement of work is reviewed by:(L2-15, Ab1, 2)





Projectmanager


Softwaremanagers

Affectedgroups

The software engineering group reviewsthe project's proposed commitments. (L2-17, A1, 2)


The software engineering group reviewsthe project-level plans. (L2-17, A3, 1)


Software project commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement. (L2-17, A4)

Seniormanagement


The software development plan isreviewed by: (L2-19, A6, 4)





Projectmanager


Softwaremanagers

Affectedgroups



SPP Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the software projectplanning process, continued from the previous page.


References

Size estimates are documented, reviewed,and agreed to. (L2-21, A9, 5)

Not specifiedin the CMM

Estimates and the assumptions made inderiving the estimates are documented,reviewed, and agreed to. (L2-23, A10, 4)


Estimates of the critical computerresources are documented, reviewed, andagreed to. (L2-23, A11, 3)


The software schedule is documented,reviewed, and agreed to. (L2-24, A12, 6)


The plans for the project’s softwareengineering facilities and support tools arereviewed by all affected groups. (L2-25,A14, 3)

Affectedgroups

The activities for software project planningare reviewed with senior management ona periodic basis. (L2-26, V1)

q The technical, cost, staffing, andschedule performance is reviewed.

q Conflicts and issues not resolvable atlower levels are addressed.

q Software project risks are addressed.

q Action items are assigned, reviewed,and tracked to closure.

q A summary report from each meetingis prepared and distributed to theaffected groups and individuals.

Seniormanagement

Affectedgroups andindividuals



SPP Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the software projectplanning process, continued from the previous page.


References

The activities for software project planningare reviewed with the project manager onboth a periodic and event-driven basis.(L2-26, V2)


q Status and current results of thesoftware project planning activities arereviewed against the software project'sstatement of work and allocatedrequirements.

q Dependencies between groups areaddressed.


q Software project risks are reviewed.


q A summary report from each meetingis prepared and distributed to theaffected groups and individuals.

Projectmanager

Affectedgroups

The software quality assurance groupreviews and/or audits the activities andwork products for software project planningand reports the results. (L2-27, V3)

At a minimum, the reviews and/or auditsverify:

q The activities for software estimatingand planning.

q The activities for reviewing andmaking project commitments.

q The activities for preparing thesoftware development plan.

q The standards used for preparing thesoftware development plan.

q The content of the softwaredevelopment plan.

SQA group


SPP Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the software project planning process.


Project's software development plan. (L2-13, C2, 6)

Statement of work. (L2-15, Ab1, 3)

Software planning data. (L2-25, A15, 2)


SPP Process - Measurements

Measurements The table below lists the measurements recommended for the software projectplanning process.


Software planning data. (L2-25, A15)

q Information recorded includes the estimates and theassociated information needed to reconstruct theestimates and assess their reasonableness. (L2-25, A15,1)

Measurements are made and used to determine the status ofthe software planning activities. (L2-25, M1)


q Completions of milestones for the software projectplanning activities compared to the plan.

q Work completed, effort expended, and funds expendedin the software project planning activities compared tothe plan.


SPP Process - Documented Procedures


The table below lists the activities for the software project planning processrecommended to be performed according to a documented procedure.

Documented procedures References

Software project commitments made to individuals andgroups external to the organization are reviewed withsenior management according to a documented procedure.(L2-17, A4)







Estimates for the project's critical computer resources arederived according to a documented procedure. (L2-23, A11)





SPP Process - T ra in ing

Training The table below lists the training recommended for the software project planningprocess.

Training References

The software managers, software engineers, and otherindividuals involved in the software project planning aretrained in the software estimating and planning proceduresapplicable to their areas of responsibility. (L2-16, Ab4)


S P P P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the software project planningprocess.

Tools References

Tools to support software project planning activities. (L2-16, Ab3, 2)



q estimating models, and

q project planning and scheduling programs.


Sof tware Pro ject Track ing and Overs ight (SPTO)Process

S P T O P r o c e s s - O v e r v i e w

The purpose of Software Project Tracking and Oversight is to provide adequatevisibility into actual progress so that management can take effective actions whenthe software project's performance deviates significantly from the software plans.(L2-29)

SPTO processpurpose

Software Project Tracking and Oversight involves tracking and reviewing thesoftware accomplishments and results against documented estimates,commitments, and plans, and adjusting these plans based on the actualaccomplishments and results.

A documented plan for the software project (i.e., the software development plan,as described in the Software Project Planning key process area) is used as thebasis for tracking the software activities, communicating status, and revisingplans. Software activities are monitored by the management. Progress isprimarily determined by comparing the actual software size, effort, cost, andschedule to the plan when selected software work products are completed and atselected milestones. When it is determined that the software project's plans arenot being met, corrective actions are taken. These actions may include revisingthe software development plan to reflect the actual accomplishments andreplanning the remaining work or taking actions to improve the performance. (L2-29)

SPTO processdescription



S P T O P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L2-Process-61



L2-Process-70


L2-Process-71


L2-Process-75


L2-Process-79

Reviews andAudits




L2-Process-92




L2-Process-94




SPTO Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware project tracking and oversight process.


Affectedgroups

q Changes to the software commitmentsare made with the involvement andagreement of the affected groups.(L2-30, C2, 4)

q Changes in size estimates of thesoftware work products that affectsoftware commitments are negotiatedwith the affected groups and aredocumented. (L2-36, A5, 5)

q Changes in staffing and other softwarecosts that affect software commitmentsare negotiated with the affectedgroups and are documented. (L2-36,A6, 4)

q Changes in estimates of criticalcomputer resources that affect softwarecommitments are negotiated with theaffected groups and are documented.(L2-37, A7, 2)

q Software schedule revisions that affectsoftware commitments are negotiatedwith the affected groups and aredocumented. (L2-37, A8, 3)

q Formal reviews to address theaccomplishments and results of thesoftware project are conducted atselected project milestones accordingto a documented procedure. (L2-39,A13)

These reviews:

q Are conducted with the customer,end user, and affected groupswithin the organization, asappropriate. (L2-39, A13, 2)

q A summary status report from eachreview (meeting) with seniormanagement is prepared anddistributed to the affected groups.(L2-40, V1, 5)



S P T O P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware project tracking and oversight process, continued from the previous page.


Affectedgroups,continued

q The activities for software projecttracking and oversight are reviewedwith the project manager on both aperiodic and event-driven basis. (L2-41, V2)

q Affected groups are represented.(L2-41, V2, 1)

q A summary status report from each(review meeting) with the projectmanager is prepared anddistributed to the affected groups.(L2-41, V2, 8)

Customer q Formal reviews to address theaccomplishments and results of thesoftware project are conducted atselected project milestones accordingto a documented procedure. (L2-39,A13)

These reviews:


End user q Formal reviews to address theaccomplishments and results of thesoftware project are conducted atselected project milestones accordingto a documented procedure. (L2-39,A13)

These reviews:





Roles,continued



First-linesoftwaremanagers

q First-line software managers receiveorientation in the technical aspects ofthe software project. (L2-32, Ab5)

q Members of the software engineeringgroup report their technical status totheir first-line manager on a regularbasis. (L2-37, A9, 1)

q The software engineering groupconducts periodic internal reviews totrack technical progress, plans,performance, and issues against thesoftware development plan. (L2-38,A12)

These reviews are conducted between:

q The first-line software managersand their software task leaders.

q The project software manager,first-line software managers, andother software managers, asappropriate.


q Senior management reviews allcommitment changes and new softwareproject commitments made toindividuals and groups external tothe organization. (L2-31, C2, 5)

q Software project commitments andchanges to commitments made toindividuals and groups external tothe organization are reviewed withsenior management according to adocumented procedure. (L2-35, A3)



SPTO Process - Ro les , Continued

Roles,continued



Projectmanager

q The project manager is kept informedof the software project's status andissues. (L2-30, C2, 2)

q High-risk areas associated with cost,resource, schedule, and technicalaspects of the project are reviewedwith the project manager on a regularbasis. (L2-38, A10, 2)

q The activities for software projecttracking and oversight are reviewedwith the project manager on both aperiodic and event-driven basis. (L2-41, V2)


q A project software manager isdesignated to be responsible for theproject's software activities and results.(L2-30, C1)

q The project software managerexplicitly assigns responsibility forsoftware work products and activities.(L2-31, Ab2)







SPTO Process - Ro les , Continued

Roles,continued



Seniormanagement

q Senior management reviews allcommitment changes and new softwareproject commitments made toindividuals and groups external to theorganization. (L2-31, C2, 5)

q Software project commitments andchanges to commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement according to adocumented procedure. (L2-35, A3)

q The activities for software projecttracking and oversight are reviewedwith senior management on aperiodic basis. (L2-40, V1)


q Approved changes to commitments thataffect the software project arecommunicated to the members of thesoftware engineering group and othersoftware-related groups. (L2-35, A4)

q Members of the software engineeringgroup report their technical status totheir first-line manager on a regularbasis. (L2-37, A9, 1)





Roles,continued



Softwaremanager

q The software managers and thesoftware task leaders are assignedspecific responsibilities for tracking thesoftware project. (L2-32, Ab3, 1)

q The software managers are trained inmanaging the technical and personnelaspects of the software project. (L2-32,Ab4)




q The project software manager, first-line software managers, and othersoftware managers, asappropriate.

q Formal review to address theaccomplishments and results of thesoftware project are conducted atselected project milestones accordingto a documented procedure. (L2-39,A13)

These reviews:

q Use materials that are reviewedand approved by the responsiblesoftware managers. (L2-39, A13,3)




Roles,continued




Approved changes to commitments thataffect the software project arecommunicated to the members of thesoftware engineering group and othersoftware-related groups. (L2-35, A4)

SQA group The software quality assurance groupreviews and/or audits the activities andwork products for software project trackingand oversight and reports the results. (L2-41, V3)

Software taskleaders

q The software managers and thesoftware task leaders are assignedspecific responsibilities for tracking thesoftware project. (L2-32, Ab3, 1)




q The project software manager, first-line software managers, and othersoftware managers, as appropriate.


SPTO Process - Ent ry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the software project tracking and oversight process.


Softwaredevelopment plan(for the softwareproject)

q is documented. (L2-31, Ab1)

q is approved. (L2-31, Ab1)

The CMM recommends that the conditions described in the table below besatisfied before entering the software project tracking and oversight process.



A project software manager is designated to beresponsible for the project's software activities and results.(L2-30, C1)

The project follows a written organizational policy formanaging the software project. (L2-30, C2)

[Refer to Level 2 Policies for additional informationregarding SPTO policy.]

A software development plan for the software project isdocumented and approved. (L2-31, Ab1)

The project software manager explicitly assignsresponsibility for software work products and activities. (L2-31, Ab2)

The assigned responsibilities cover:

q The software work products to be developed or servicesto be provided.

q The effort and cost for these software activities.

q The schedule for these software activities.

q The budget for these software activities.

Adequate resources and funding are provided for trackingthe software project. (L2-32, Ab3)

The software managers and the software task leaders areassigned specific responsibilities for tracking the softwareproject. (L2-32, Ab3, 1)

Tools to support software tracking are made available. (L2-32, Ab3, 2)



SPTO Process - Ent ry Cr i te r ia , Continued

General entrycriteria,continued

The CMM recommends that the conditions described in the table below besatisfied before entering the software project tracking and oversight process,continued from the previous page.


The software managers are trained in managing thetechnical and personnel aspects of the software project.(L2-32, Ab4)

First-line software managers receive orientation in thetechnical aspects of the software project. (L2-32, Ab5)


SPTO Process - Inputs

Inputs The table below lists the recommended inputs to the software project tracking andoversight process.


Changes to commitments. (L2-34, A2, 2)

Changes to the software development plan.(L2-34, A2, 1)

New software project commitments. (L2-34, A2, 2)

Refinements to the software developmentplan. (L2-34, A2, 1)

Software commitments. (L2-36, A5, 5)

Software development plan. (L2-30, C1)

[Refer to Level 2 Standards for additionalinformation regarding a softwaredevelopment plan.]



SPTO Process - Act iv i t ies

Activities The table below lists the recommended activities for the software project trackingand oversight process.


A documented software development plan is used fortracking the software activities and communicating status.(L2-33, A1)

q This software development plan is updated as the workprogresses to reflect accomplishments, particularlywhen milestones are completed. (L2-33, A1, 1)

The project's software development plan is revisedaccording to a documented procedure. (L2-33, A2)


Software project commitments and changes to commitmentsmade to individuals and groups external to theorganization are reviewed with senior managementaccording to a documented procedure. (L2-35, A3)

Approved changes to commitments that affect the softwareproject are communicated to the members of the softwareengineering group and other software-related groups.(L2-35, A4)

The size of the software work products (or size of thechanges to the software work products) are tracked, andcorrective actions are taken as necessary. (L2-35, A5)

q Sizes for all major software work products (or the sizeof the changes) are tracked.

q Actual size of code (generated, fully tested, anddelivered) is compared to the estimates documented inthe software development plan.

q Actual units of delivered documentation are comparedto the estimates documented in the softwaredevelopment plan.

q Overall projected size of the software work products(estimates combined with actuals) is refined,monitored, and adjusted on a regular basis.

q Changes in size estimates of the software work productsthat affect software commitments are negotiated withthe affected groups and are documented.



SPTO Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software project trackingand oversight process, continued from the previous page.


The project's software effort and costs are tracked, andcorrective actions are taken as necessary. (L2-36, A6)

q Actual expenditures of effort and costs over time andagainst work completed are compared to the estimatesdocumented in the software development plan toidentify potential overruns and underruns.

q Software costs are tracked and compared to theestimates documented in the software developmentplan.

q Effort and staffing are compared to the estimatesdocumented in the software development plan.

q Changes in staffing and other software costs that affectsoftware commitments are negotiated with the affectedgroups and are documented.

The project's critical computer resources are tracked, andcorrective actions are taken as necessary. (L2-36, A7)

q The actual and projected use of the project's criticalcomputer resources are tracked and compared to theestimates for each major software component asdocumented in the software development plan.

q Changes in estimates of critical computer resources thataffect software commitments are negotiated with theaffected groups and are documented.

The project's software schedule is tracked, and correctiveactions are taken as necessary. (L2-37, A8)

q Actual completion of software activities, milestones,and other commitments is compared against thesoftware development plan.

q Effects of late and early completion of softwareactivities, milestones, and other commitments areevaluated for impacts on future activities andmilestones.

q Software schedule revisions that affect softwarecommitments are negotiated with the affected groupsand are documented.







Software engineering technical activities are tracked, andcorrective actions are taken as necessary. (L2-37, A9)

q Members of the software engineering group reporttheir technical status to their first-line manager on aregular basis.

q Software release contents for successive builds arecompared to the plans documented in the softwaredevelopment plan.

q Problems identified in any of the software work productsare reported and documented.

q Problem reports are tracked to closure.

The software risks associated with cost, resource, schedule,and technical aspects of the project are tracked. (L2-37,A10)

q The priorities of the risks and the contingencies for therisks are adjusted as additional information becomesavailable.

q High-risk areas are reviewed with the project manageron a regular basis.

Actual measurement data and replanning data for thesoftware project are recorded. (L2-38, A11)

q Information recorded includes the estimates andassociated information needed to reconstruct theestimates and verify their reasonableness.

q The software replanning data are managed andcontrolled.

q The software planning data, replanning data, and theactual measurement data are archived for use byongoing and future projects.

The software engineering group conducts periodic internalreviews to track technical progress, plans, performance, andissues against the software development plan. (L2-38, A12)

[Refer to SPTO Process Reviews and Audits for additionalinformation.]







Formal reviews to address the accomplishments and resultsof the software project are conducted at selected projectmilestones according to a documented procedure. (L2-39,A13)


Measurements are made and used to determine the status ofthe software tracking and oversight activities. (L2-39, M1)

The activities for software project tracking and oversight arereviewed with senior management on a periodic basis.(L2-40, V1)


The activities for software project tracking and oversight arereviewed with the project manager on both a periodic andevent-driven basis. (L2-41, V2)


The software quality assurance group reviews and/oraudits the activities and work products for software projecttracking and oversight and reports the results. (L2-41, V3)



SPTO Process - Outputs

Outputs The table below lists the recommended outputs produced by the software projecttracking and oversight process.


Action items (from reviews with seniormanagement). (L2-40, V1, 4)

Action items (from reviews with theproject manager). (L2-41, V2, 7)

Actual completion of milestones. (L2-37,A8, 1)

Actual completion of other (software)commitments. (L2-37, A8, 1)

Actual completion of software activities.(L2-37, A8, 1)

Actual expenditures of costs over time andagainst work completed. (L2-36, A6, 1)

Actual expenditures of effort over time andagainst work completed. (L2-36, A6, 1)

Actual measurement data for the softwareproject. (L2-38, A11)

Actual replanning data for the softwareproject. (L2-38, A11)

Actual size of code (generated, fullytested, and delivered). (L2-35, A5, 2)

Actual units of delivered documentation.(L2-35, A5, 3)

Actual use of the project's criticalcomputer resources. (L2-36, A7, 1)

Approved changes to commitments thataffect the software project. (L2-35, A4)

Changes in estimates of critical computerresources that affect softwarecommitments. (L2-37, A7, 2)

Changes in size estimates of the softwarework products that affect softwarecommitments. (L2-36, A5, 5)

Changes in staffing and other softwarecosts that affect software commitments.(L2-36, A6, 4)


Changes to commitments made toindividuals and groups external to theorganization. (L2-35, A3)



SPTO Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the software projecttracking and oversight process, continued from the previous page.


Changes to the software commitments.(L2-31, C2, 5)

Conflicts and issues (not resolvable atlower levels). (L2-40, V1, 2)

Contingencies for the (software) risks.(L2-38, A10, 1)

Corrective actions (taken when thesoftware plan is not being achieved). (L2-30, C2, 3)

Current estimates and actual use of criticalcomputer resources. (L2-41, V2, 3)

Effects of late and early completion ofsoftware activities, milestones, and othercommitments. (L2-37, A8, 2)

Effort and staffing. (L2-36, A6, 3)

High-risk areas. (L2-38, A10, 2)

Measurements (to determine the status ofthe software tracking and oversightactivities). (L2-39, M1)

New software project commitments madeto individuals and groups external to theorganization. (L2-31, C2, 5)

Overall projected size of the software workproducts (estimates combined withactuals). (L2-35, A5, 4)

Performance (cost). (L2-40, V1, 1)

Performance (schedule). (L2-40, V1, 1)

Performance (staffing). (L2-40, V1, 1)

Performance (technical). (L2-40, V1, 1)

Priorities of the (software) risks. (L2-38,A10, 1)

Problem reports. (L2-37, A9, 4)

Problems identified in any of the softwarework products. (L2-37, A9, 3)

Projected use of the project's criticalcomputer resources. (L2-36, A7, 1)


Project's critical computer resources. (L2-36, A7)




Outputs,continued



Project's software costs. (L2-36, A6)

Project's software effort. (L2-36, A6)

Project's software schedule. (L2-37, A8)

Results of SQA group reviews and/oraudits of the activities and work productsfor software project tracking and oversight.(L2-41, V3)

Size of the changes to the software workproducts. (L2-35, A5)

Size of the software work products. (L2-35, A5)

Sizes for all major software work products.(L2-35, A5, 1)

Sizes of the changes to all major softwarework products. (L2-35, A5, 1)

Software costs. (L2-36, A6, 2)

Software development plan. (L2-33, A2)


Software project commitments made toindividuals and groups external to theorganization. (L2-35, A3)

Software project risks. L2-40, V1, 3)

Software project's status and issues. (L2-30, C2, 2)

Software release contents for successivebuilds. (L2-37, A9, 2)

Software risks associated with cost aspectsof the project. (L2-37, A10)

Software risks associated with resourceaspects of the project. (L2-37, A10)

Software risks associated with scheduleaspects of the project. (L2-37, A10)

Software risks associated with technicalaspects of the project. (L2-37, A10)




Outputs,continued



Software schedule revisions that affectsoftware commitments. (L2-37, A8, 3)

Status of software activities. (L2-33, A1)

Summary report from each review ofactivities for software project tracking andoversight with the project manager. (L2-41, V2, 8)

Summary status report from each periodicreview of activities for software projecttracking and oversight with seniormanagement. (L2-40, V1, 5)


SPTO Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software project tracking and oversight process.


Action items (fromreviews with seniormanagement)




Action items (fromreviews with theproject manager)




Actual completion ofmilestones

is compared against the softwaredevelopment plan. (L2-37, A8, 1)

Actual completion ofother (software)commitments


Actual completion ofsoftware activities


Actual expendituresof costs over timeand against workcompleted

are compared to the estimatesdocumented in the softwaredevelopment plan to identifypotential overruns and underruns.(L2-36, A6, 1)

Actual expendituresof effort over timeand against workcompleted

are compared to the estimatesdocumented in the softwaredevelopment plan to identifypotential overruns and underruns.(L2-36, A6, 1)

Actual measurementdata for the softwareproject


q include in the informationrecorded the estimates andassociated information needed toreconstruct the estimates andverify their reasonableness. (L2-38, A11, 1)

q are archived for use by ongoingand future projects. (L2-38, A11,3)



SPTO Process - Ex i t Cr i te r ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software project tracking and oversight process, continued from theprevious page.


Actual replanningdata for the softwareproject


q include in the informationrecorded the estimates andassociated information needed toreconstruct the estimates andverify their reasonableness. (L2-38, A11, 1)


q are archived for use by ongoingand future projects. (L2-38, A11,3)

Actual size of code(generated, fullytested, anddelivered)

is compared to the estimatesdocumented in the softwaredevelopment plan. (L2-35, A5, 2)

Actual units ofdelivereddocumentation

are compared to the estimatesdocumented in the softwaredevelopment plan. (L2-35, A5, 3)

Actual use of theproject's criticalcomputer resources

q is tracked. (L2-36, A7, 1)

q is compared to the estimates foreach major software componentas documented in the softwaredevelopment plan. (L2-36, A7,1)

Approved changes tocommitments thataffect the softwareproject

are communicated to the members ofthe software engineering groupand other software-related groups.(L2-35, A4)

Changes in estimatesof critical computerresources that affectsoftwarecommitments

q are negotiated with the affectedgroups. (L2-37, A7, 2)



Changes in sizeestimates of thesoftware workproducts that affectsoftwarecommitments









Changes in staffingand other softwarecosts that affectsoftwarecommitments



Changes tocommitments madeto individuals andgroups external tothe organization

are reviewed with seniormanagement according to adocumented procedure. (L2-35, A3)

Changes to thesoftwarecommitments

are made with the involvement andagreement of the affected groups.(L2-30, C2, 4)

Conflicts and issues(not resolvable atlower levels)

q are addressed (during reviewswith senior management). L2-40, V1, 2)

q are addressed (during reviewswith the project manager).(L2-41, V2, 2). (L2-40, V1, 5)

Contingencies for the(software) risks

are adjusted as additionalinformation becomes available. (L2-38, A10, 1)

Corrective actions are taken when the software plan isnot being achieved, either byadjusting performance or byadjusting the plans. (L2-30, C2, 3)

Effects of late andearly completion ofsoftware activities,milestones, and othercommitments

are evaluated for impacts on futureactivities and milestones. (L2-37,A8, 2)

Effort and staffing are compared to the estimatesdocumented in the softwaredevelopment plan. (L2-36, A6, 3)

High-risk areas are reviewed with the projectmanager on a regular basis. (L2-38,A10, 1)







Measurements (todetermine the statusof the softwaretracking andoversight activities)



Overall projectedsize of the softwarework products(estimates combinedwith actuals)

is refined, monitored, and adjustedon a regular basis. (L2-35, A5, 4)

Performance (cost) q is reviewed (during reviews withsenior management). L2-40,V1, 1)

q is reviewed against the softwaredevelopment plan (duringreviews with the projectmanager). (L2-41, V2, 2)

Performance(schedule)

q is reviewed (during reviews withsenior management). L2-40,V1, 1)


Performance(staffing)



Performance(technical)








Priorities of the(software) risks

are adjusted as additionalinformation becomes available. (L2-38, A10, 1)

Problem reports are tracked to closure. (L2-37, A9,4)

Problems identifiedin any of the softwarework products

q are reported. (L2-37, A9, 3)


Project's criticalcomputer resources

are tracked, and corrective actionsare taken as necessary. (L2-36, A7)

Project's softwarecosts

are tracked, and corrective actionsare taken as necessary. (L2-36, A6)

Project's softwareeffort

is tracked, and corrective actions aretaken as necessary. (L2-36, A6)

Project's softwareschedule


Projected use of theproject's criticalcomputer resources

q is tracked. (L2-36, A7, 1)

q is compared to the estimates foreach major software componentas documented in the softwaredevelopment plan. (L2-36, A7,1)

Results of SQAgroup reviews and/oraudits of theactivities and workproducts for softwareproject tracking andoversight


Size of the changesto the software workproducts


Size of the softwarework products


Sizes for all majorsoftware workproducts

are tracked, and corrective actionsare taken as necessary. (L2-35, A5,A1)






Sizes of the changesto all major softwarework products

are tracked, and corrective actionsare taken as necessary. (L2-35, A5,A1)

Software costs q are tracked. (L2-36, A6, 2)

q are compared to the estimatesdocumented in the softwaredevelopment plan. (L2-36, A6,2)







Softwaredevelopment plan


q is used for tracking the softwareactivities and communicatingstatus. (L2-33, A1)

q is updated as the work progressesto reflect accomplishments,particularly when milestones arecompleted. (L2-33, A1, 1)

q is readily available to: (L2-33,A1, 2)

q the software engineeringgroup (including allsubgroups, such as softwaredesign),

q the software managers,


q senior management, and


q is revised according to adocumented procedure. (L2-33,A2)

q is revised, as appropriate, toincorporate plan refinements andincorporate plan changes,particularly when plans changesignificantly. (L2-34, A2, 1)

q is updated to incorporate all newsoftware project commitmentsand changes to commitments.(L2-34, A2, 2)

q is reviewed at each revision.(L2-34, A2, 3)

q is managed and controlled. (L2-34, A2, 4)

Software planningdata

are archived for use by ongoing andfuture projects. (L2-38, A11, 3)






Software projectcommitments madeto individuals andgroups external tothe organization

are reviewed with seniormanagement according to adocumented procedure. (L2-35, A3)

Software project risks q are addressed (during reviewswith senior management). L2-40, V1, 3)

q are addressed (during reviewswith the project manager).(L2-41, V2, 6). (L2-40, V1, 5)

Software releasecontents forsuccessive builds

are compared to the plansdocumented in the softwaredevelopment plan. (L2-37, A9, 2)

Software risksassociated with costaspects of the project

are tracked. (L2-37, A10)

Software risksassociated withresource aspects ofthe project


Software risksassociated withschedule aspects ofthe project


Software risksassociated withtechnical aspects ofthe project


Software schedulerevisions that affectsoftwarecommitments



Summary statusreport (from eachreview with seniormanagement)


q is distributed to the affectedgroups. (L2-40, V1, 5)







Summary statusreport (from eachreview with theproject manager)


q is distributed to the affectedgroups. (L2-41, V2, 8)

The CMM recommends that the conditions described in the table below besatisfied to exit the software project tracking and oversight process.



The project manager is kept informed of the softwareproject’s status and issues. (L2-30, C2, 2)

Senior management reviews all commitment changes andnew software project commitments made to individualsand groups external to the organization. (L2-31, C2, 5)

Software engineering technical activities are tracked, andcorrective actions are taken as necessary. (L2-37, A9)

Members of the software engineering group report theirtechnical status to their first-line manager on a regularbasis. (L2-37, A9, 1)

The software engineering group conducts periodic internalreviews to track technical progress, plans, performance, andissues against the software development plan. (L2-38, A12)


The activities for software project tracking and oversight arereviewed with senior management on a periodic basis.(L2-40, V1)

The activities for software project tracking and oversight arereviewed with the project manager on both a periodic andevent-driven basis. (L2-41, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software projecttracking and oversight and reports the results. (L2-41, V3)


SPTO Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the software projecttracking and oversight process.


References

Senior management reviews allcommitment changes and new softwareproject commitments made to individualsand groups external to the organization.(L2-31, C2, 5)

Seniormanagement

The software development plan isreviewed at each revision. (L2-34, A2, 3)

Not specifiedin CMM

Software project commitments andchanges to commitments made toindividuals and groups external to theorganization are reviewed with seniormanagement according to a documentedprocedure. (L2-35, A3)

Seniormanagement

High-risk areas are reviewed with theproject manager on a regular basis. (L2-38, A10, 2)

Projectmanager

The software engineering groupconducts periodic internal reviews to tracktechnical progress, plans, performance,and issues against the softwaredevelopment plan. (L2-38, A12)


q The first-line software managers andtheir software task leaders.

q The project software manager, first-line software managers, and othersoftware managers, as appropriate.




Softwaremanagers




SPTO Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the software projecttracking and oversight process, continued from the previous page.


References

Formal reviews to address theaccomplishments and results of thesoftware project are conducted at selectedproject milestones according to adocumented procedure. (L2-39, A13)

These reviews:

q Are planned to occur at meaningfulpoints in the software project'sschedule, such as the beginning orcompletion of selected stages.

q Are conducted with the customer, enduser, and affected groups within theorganization, as appropriate.

q Use materials that are reviewed andapproved by the responsible softwaremanagers.

q Address the commitments, plans, andstatus of the software activities.

q Result in the identification anddocumentation of significant issues,action items, and decisions.

q Address the software project risks.

q Result in the refinement of thesoftware development plan asnecessary.

Customer

End user

Softwaremanagers

Affectedgroups


The activities for software project trackingand oversight are reviewed with seniormanagement on a periodic basis. (L2-40,V1)

q The technical, cost, staffing, andschedule performance are reviewed.




q A summary status report from eachmeeting is prepared and distributed tothe affected groups.

Seniormanagement

Affectedgroups







References

The activities for software project trackingand oversight are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-41, V2)


q The technical, cost, staffing, andschedule performance is reviewedagainst the software development plan.

q Use of critical computer resources isreviewed; current estimates and actualuse of these critical computerresources are reported against theoriginal estimates.

q Dependencies between groups areaddressed.




q A summary report from each meetingis prepared and distributed to theaffected groups.

Projectmanager

Affectedgroups







References

The software quality assurance groupreviews and/or audits the activities andwork products for software project trackingand oversight and reports the results. (L2-41, V3)


q The activities for reviewing andrevising commitments.

q The activities for revising the softwaredevelopment plan.

q The content of the revised softwaredevelopment plan.

q The activities for tracking the softwareproject's cost, schedule, risks,technical and design constraints, andfunctionality and performance.

q The activities for conducting theplanned technical and managementreviews.

SQA group


SPTO Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the software project tracking and oversight process.


Software development plan. (L2-34, A2, 4)

Software replanning data. (L2-38, A11, 2)


SPTO Process - Measurements

Measurements The table below lists the measurements recommended for the software projecttracking and oversight process.


Actual measurement data for the software project. (L2-38,A11)

Replanning data for the software project. (L2-38, A11)

Measurements to determine the status of the softwaretracking and oversight activities. (L2-39, M1)


q Effort and other resources expended in performing thetracking and oversight activities.

q Change activity for the software development plan,which includes changes to size estimates of thesoftware work products, software cost estimates, criticalcomputer resources estimates, and schedule.


SPTO Process - Documented Procedures


The table below lists the activities for the software process tracking and oversightprocess recommended to be performed according to a documented procedure.




Software project commitments and changes to commitmentsmade to individuals and groups external to theorganization are reviewed with senior managementaccording to a documented procedure. (L2-35, A3)



SPTO Process - T ra in ing

Training The table below lists the training recommended for the software project trackingand oversight process.

Training References

The software managers are trained in managing thetechnical and personnel aspects of the software project.(L2-32, Ab4)

First-line software managers receive orientation in thetechnical aspects of the software project. (L2-32, Ab5)


S P T O P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the software project tracking andoversight process.

Tools References

Tools to support software tracking. (L2-32, Ab3, 2)


q spreadsheet programs, and

q project planning/scheduling programs.


Sof tware Subcontract Management (SSM)Process

S S M P r o c e s s - O v e r v i e w

The purpose of Software Subcontract Management is to select qualified softwaresubcontractors and manage them effectively. (L2-43)

SSM processpurpose

Software Subcontract Management involves selecting a software subcontractor,establishing commitments with the subcontractor, and tracking and reviewing thesubcontractor's performance and results. These practices cover the managementof a software (only) subcontract, as well as the management of the softwarecomponent of a subcontract that includes software, hardware, and possibly othersystem components.

The subcontractor is selected based on its ability to perform the work. Manyfactors contribute to the decision to subcontract a portion of the prime contractor'swork. Subcontractors may be selected based on strategic business alliances, aswell as technical considerations. The practices of this key process area addressthe traditional acquisition process associated with subcontracting a defined portionof the work to another organization.

When subcontracting, a documented agreement covering the technical andnontechnical (e.g., delivery dates) requirements is established and is used as thebasis for managing the subcontract. The work to be done by the subcontractor andthe plans for the work are documented. The standards that are to be followed bythe subcontractor are compatible with the prime contractor's standards.

The software planning, tracking, and oversight activities for the subcontractedwork are performed by the subcontractor. The prime contractor ensures that theseplanning, tracking, and oversight activities are performed appropriately and thatthe software products delivered by the subcontractor satisfy their acceptancecriteria. The prime contractor works with the subcontractor to manage theirproduct and process interfaces. (L2-43)

SSM processdescription



S S M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L2-Process-99



L2-Process-107


L2-Process-109


L2-Process-111


L2-Process-113

Reviews andAudits




L2-Process-124




L2-Process-126




S S M P r o c e s s - R o l e s

Roles The table below lists the roles and the activities in which they participate in thesoftware subcontract management process.


Affectedgroups(parties)

q Changes to the software subcontractor'sstatement of work, subcontract termsand conditions, and other commitmentsare resolved according to adocumented procedure. (L2-51, A6)

q This procedure typically specifiesthat all affected groups of both theprime contractor and thesubcontractor are involved.

q The subcontract manager is responsiblefor coordinating the technical scope ofwork to be subcontracted and the termsand conditions of the subcontract withthe affected parties. (L2-45, C2, 2)

Customers The subcontractor is provided withvisibility of the needs and desires of theproduct's customers and end users, asappropriate. (L2-52, A7, 1)

End users The subcontractor is provided withvisibility of the needs and desires of theproduct's customers and end users, asappropriate. (L2-52, A7, 1)


Individuals q The subcontract manager isknowledgeable and experienced insoftware engineering or hasindividuals assigned who have thatknowledge and experience. (L2-45,C2, 1)

q Software managers and otherindividuals are assigned specificresponsibilities for managing thesubcontract. (L2-46, Ab1, 1)

q Software managers and otherindividuals who are involved inestablishing and managing the softwaresubcontract are trained to perform theseactivities. (L2-46, Ab2)

q Software managers and otherindividuals who are involved inmanaging the software subcontractreceive orientation in the technicalaspects of the subcontract. (L2-46,Ab3)



S S M P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware subcontract management process, continued from the previous page.


Primecontractor

q Changes to the subcontract are madewith the involvement and agreement ofboth the prime contractor and thesubcontractor. (L2-45, C1, 3)

q The contractual agreement between theprime contractor and the softwaresubcontractor is used as the basis formanaging the subcontract. (L2-50,A3)

q A documented subcontractor's softwaredevelopment plan is reviewed andapproved by the prime contractor.(L2-51, A4)

q Critical dependencies andcommitments between the primecontractor and the subcontractor areaddressed. (L2-52, A7, 5)

q Subcontractor commitments to theprime contractor and primecontractor commitments to thesubcontractor are both reviewed.

q The prime contractor and thesubcontractor coordinate their activitieson matters relating to softwareconfiguration management to ensurethat the subcontractor's products can bereadily integrated or incorporated intothe project environment of the primecontractor. (L2-54, A11, 2)

q The prime contractor conductsacceptance testing as part of thedelivery of the subcontractor's softwareproducts according to a documentedprocedure. (L2-55, A12)

q The acceptance procedures andacceptance criteria for each productare defined, reviewed, and approved byboth the prime contractor and thesubcontractor prior to the acceptancetest. (L2-55, A12, 1)




Roles,continued



Primecontractor'sSCM group

The prime contractor's softwareconfiguration management groupmonitors the subcontractor's activities forsoftware configuration managementaccording to a documented procedure.(L2-54, A11)

Primecontractor'sSQA group orSQA group

q The prime contractor's softwarequality assurance group monitors thesubcontractor's software qualityassurance activities according to adocumented procedure. (L2-53, A10)

q The prime contractor's softwarequality assurance group spot checksthe subcontractor's softwareengineering activities and products.(L2-54, A10, 2.1)

q The prime contractor's softwarequality assurance group audits thesubcontractor's software qualityassurance records, as appropriate. (L2-54, A10, 2.2)

q The software quality assurancegroup reviews and/or audits theactivities and work products formanaging the software subcontract andreports the results. (L2-57, V3)

Primecontractor'smanagement

The prime contractor's managementconducts periodic status/coordinationreviews with the software subcontractor'smanagement. (L2-51, A7)

Projectmanager

The activities for managing the softwaresubcontract are reviewed with the projectmanager on both a periodic and event-driven basis. (L2-56, V2)




Roles,continued



Seniormanagement

The activities for managing the softwaresubcontract are reviewed with seniormanagement on a periodic basis. (L2-56,V1)

Softwaremanagers

q Software managers and otherindividuals are assigned specificresponsibilities for managing thesubcontract. (L2-46, Ab1, 1)

q Software managers and otherindividuals who are involved inestablishing and managing the softwaresubcontract are trained to perform theseactivities. (L2-46, Ab2)

q Software managers and otherindividuals who are involved inmanaging the software subcontractreceive orientation in the technicalaspects of the subcontract. (L2-46,Ab3)

Software sub-contractor'smanagement


Subcontractbidder

The software subcontractor is selected,based on an evaluation of the subcontractbidders' ability to perform the work,according to a documented procedure.(L2-49, A2)




Roles,continued



Subcontractmanager

q A subcontract manager is designatedto be responsible for establishing andmanaging the software subcontract.(L2-45, C2)

q The subcontract manager isknowledgeable and experienced insoftware engineering or has individualsassigned who have that knowledge andexperience. (L2-45, C2, 1)

q The subcontract manager isresponsible for coordinating thetechnical scope of work to besubcontracted and the terms andconditions of the subcontract with theaffected parties. (L2-45, C2, 2)

q The subcontract manager isresponsible for: (L2-45, C2, 3)

q selecting the softwaresubcontractor,

q managing the software subcontract,and

q arranging for the post-subcontractsupport of the subcontractedproducts.




Roles,continued



Softwaresubcontractor

q Changes to the subcontract are madewith the involvement and agreement ofboth the prime contractor and thesubcontractor. (L2-45, C1, 3)

q The software subcontractor isselected, based on an evaluation of thesubcontract bidders' ability to performthe work, according to a documentedprocedure. (L2-49, A2)

q The contractual agreement between theprime contractor and the softwaresubcontractor is used as the basis formanaging the subcontract. (L2-50, A3)

q The subcontractor is provided withvisibility of the needs and desires ofthe product's customers and end users,as appropriate. (L2-52, A7, 1)

q Critical dependencies andcommitments between the primecontractor and the subcontractor areaddressed. (L2-52, A7, 5)


q Periodic technical reviews andinterchanges are held with the softwaresubcontractor. (L2-52, A8)

q The prime contractor and thesubcontractor coordinate theiractivities on matters relating tosoftware configuration management toensure that the subcontractor's productscan be readily integrated orincorporated into the projectenvironment of the prime contractor.(L2-54, A11, 2)




Roles,continued



Softwaresubcontractor, continued

q The acceptance procedures andacceptance criteria for each productare defined, reviewed, and approved byboth the prime contractor and thesubcontractor prior to the test. (L2-55, A12, 1)

q The software subcontractor'sperformance is evaluated on a periodicbasis, and the evaluation is reviewedwith the subcontractor. (L2-55, A13)

Softwaresubcontractorgroups

Critical dependencies and commitmentsbetween the subcontractor's softwareengineering group and other subcontractorgroups are addressed. (L2-52, A7, 4)

Software sub-contractor'ssoftwareengineeringgroup

Critical dependencies and commitmentsbetween the subcontractor's softwareengineering group and othersubcontractor groups are addressed. (L2-52, A7, 4)


SSM Process - Ent ry Cr i te r ia


There are no input-based entry criteria in the software subcontract managementprocess.


The CMM recommends that the conditions described in the table below besatisfied before entering the software subcontract management process.


The project follows a written organizational policy formanaging the software subcontract. (L2-44, C1)

[Refer to Level 2 Policies for additional informationregarding SSM policy.]

A subcontract manager is designated to be responsible forestablishing and managing the software subcontract. (L2-45, C2)

The subcontract manager is knowledgeable andexperienced in software engineering or has individualsassigned who have that knowledge and experience. (L2-45,C2, 1)

Adequate resources and funding are provided for selectingthe software subcontractor and managing the subcontract.(L2-46, Ab1)

Software managers and other individuals are assignedspecific responsibilities for managing the subcontract. (L2-46, Ab1, 1)

Tools to support managing the subcontract are madeavailable. (L2-46, Ab1, 2)

Software managers and other individuals who areinvolved in establishing and managing the softwaresubcontract are trained to perform these activities. (L2-46,Ab2)

Software managers and other individuals who areinvolved in managing the software subcontract receiveorientation in the technical aspects of the subcontract. (L2-46, Ab3)


SSM Process - Inputs

Inputs The table below lists the recommended inputs to the software subcontractmanagement process.


Acceptance procedures and acceptancecriteria for each product. (L2-55, A12, 1)

Computer resources designated as criticalfor the project. (L2-52, A7, 3)

Conflicts and issues not resolvable by thesubcontractor. (L2-52, A7, 8)

Critical dependencies and commitmentsbetween the prime contractor and thesubcontractor. (L2-52, A7, 5)

Critical dependencies and commitmentsbetween the subcontractor's softwareengineering group and othersubcontractor groups. (L2-52, A7, 4)

Needs and desires of the product'scustomers and end users. (L2-52, A7, 1)

Prior performance records on similar work,if available. (L2-49, A2, 2)

Project risks involving the subcontractor'swork. (L2-52, A7, 7)

Project's software development plan. (L2-47, A1, 2.4)

Project's software requirements. (L2-47,A1, 2.3)

Project's standards and procedures. (L2-47, A1, 2.5)

Project's statement of work. (L2-47, A1,2.1)


Project's system requirements allocated tosoftware. (L2-47, A1, 2.2)

[Refer to Level 2 Standards for additionalinformation regarding system requirementsallocated to software.]

Proposals submitted for the plannedsubcontract. (L2-49, A2, 1)

Subcontracted products. (L2-45, C2, 3.3)


SSM Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the software subcontractmanagement process, continued from the previous page.


Subcontractor's cost performance. (L2-52,A7, 2)

Subcontractor's plans. (L2-54, A10, 1)

Subcontractor's procedures. (L2-54, A10,1)

Subcontractor's products. (L2-54, A10,2.1)

Subcontractor's resources. (L2-54, A10, 1)

Subcontractor's schedule performance.(L2-52, A7, 2)

Subcontractor's software baseline library.(L2-54, A11, 3)

Subcontractor's software engineeringaccomplishments and results. (L2-53, A9)

Subcontractor's SQA records. (L2-54, A10,2.2)

Subcontractor's staffing performance. (L2-52, A7, 2)

Subcontractor's standards. (L2-54, A10, 1)

Subcontractor's technical performance.(L2-52, A7, 2)

Technical and nontechnical characteristicsof the project. (L2-47, A1, 1)


SSM Process - Act iv i t ies

Activities The table below lists the recommended activities for the software subcontractmanagement process.


The work to be subcontracted is defined and plannedaccording to a documented procedure. (L2-47, A1)


The software subcontractor is selected based on anevaluation of the subcontract bidders' ability to perform thework, according to a documented procedure. (L2-49, A2)


The contractual agreement between the prime contractorand the software subcontractor is used as the basis formanaging the subcontract. (L2-50, A3)

[ Refer to SPF Standards for additional informationregarding the contractual agreement. ]

A documented subcontractor's software development plan isreviewed and approved by the prime contractor. (L2-51,A4)

[Refer to SSM Process Reviews and Audits for additionalinformation.]

A documented and approved subcontractor's softwaredevelopment plan is used for tracking the software activitiesand communicating status. (L2-51, A5)

Changes to the software subcontractor's statement of work,subcontract terms and conditions, and other commitmentsare resolved according to a documented procedure. (L2-51,A6)


The prime contractor's management conducts periodicstatus/coordination reviews with the softwaresubcontractor's management. (L2-51, A7)


Periodic technical reviews and interchanges are held withthe software subcontractor. (L2-52, A8)



SSM Process - Act iv i t i es , Continued


The table below lists the recommended activities for the software subcontractmanagement process, continued from the previous page.


Formal reviews to address the subcontractor's softwareengineering accomplishments and results are conducted atselected milestones according to a documented procedure.(L2-53, A9)


The prime contractor's software quality assurancegroup monitors the subcontractor's software qualityassurance activities according to a documented procedure.(L2-53, A10)


The prime contractor's software configurationmanagement group monitors the subcontractor's activitiesfor software configuration management according to adocumented procedure. (L2-54, A11)


The prime contractor conducts acceptance testing as partof the delivery of the subcontractor's software productsaccording to a documented procedure. (L2-55, A12)


The software subcontractor's performance is evaluated ona periodic basis, and the evaluation is reviewed with thesubcontractor. (L2-55, A13)

Measurements are made and used to determine the status ofthe activities for managing the software subcontract. (L2-55, M1)

The activities for managing the software subcontract arereviewed with senior management on a periodic basis.(L2-56, V1)

The activities for managing the software subcontract arereviewed with the project manager on both a periodic andevent-driven basis. (L2-56, V2)


The software quality assurance group reviews and/oraudits the activities and work products for managing thesoftware subcontract and reports the results. (L2-57, V3)



SSM Process - Outputs

Outputs The table below lists the recommended outputs produced by the softwaresubcontract management process.


Acceptance criteria for each product. (L2-55, A12, 1)

Acceptance procedures for each product.(L2-55, A12, 1)

Action items resulting from periodicstatus/coordination reviews with thesoftware subcontractor's management.(L2-52, A7, 9)

Action plan for any software product thatdoes not pass its acceptance test. (L2-55,A12, 3)

Changes to the software subcontractor'sstatement of work. (L2-51, A6)

Changes to the subcontract terms andconditions. (L2-51, A6)

Changes to the subcontract. (L2-45, C1,3)

Contractual agreements. (L2-45, C1, 2)

[Refer to Level 2 Standards for additionalinformation regarding contractualagreements.]

Evaluation of the subcontract bidders'ability to perform the work. (L2-49, A2)

Functions or subsystems to besubcontracted. (L2-47, A1, 1.1)

List of dependencies between thesubcontractor and the prime contractor.(L2-50, A3, 4)

Measurements (to determine the status ofthe activities for managing the softwaresubcontract). (L2-55, M1)

Nonconformance to the subcontract. (L2-52, A7, 6)

Plan for selecting a subcontractor. (L2-48, A1, 4)

Requirements for the products to bedeveloped (by the subcontractor). (L2-50, A3, 3)


SSM Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the softwaresubcontract management process, continued from the previous page.


Results of the acceptance tests. (L2-55,A12, 2)

Significant issues, action items, anddecisions resulting from formal reviews ofthe subcontractor's software engineeringaccomplishments. (L2-53, A9, 3)

Software products and activities to besubcontracted. (L2-47, A1, 1)

Software risks. (L2-53, A9, 4)

Specification of the software products andactivities to be subcontracted. (L2-47, A1,1.2)

Specification of work to be subcontracted.(L2-47, A1, 2)

Subcontract statement of work. (L2-47,A1, 3)

Subcontractor’s software developmentplan. (L2-51, A4)

Work to be subcontracted. (L2-47, A1)


SSM Process - Ex i t Cr i te r ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software subcontract management process.


Acceptance criteriafor each product

q are defined by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

q are reviewed by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

q are approved by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

Acceptanceprocedures for eachproduct

q are defined by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

q are reviewed by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

q are approved by both the primecontractor and thesubcontractor prior toacceptance testing. (L2-55,A12, 1)

Action itemsresulting fromperiodicstatus/coordinationreviews with thesoftwaresubcontractor'smanagement

q are assigned. (L2-52, A7, 9)


q are tracked to closure. (L2-52,A7, 9)



SSM Process - Ex i t Cr i te r ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software subcontract management process, continued from the previouspage.


Action plan for anysoftware product thatdoes not pass itsacceptance test

is established. (L2-55, A12, 3)

Changes to thesoftwaresubcontractor'sstatement of work

are resolved according to adocumented procedure. (L2-51, A6)

Changes to thesoftware subcontractterms and conditionsand othercommitments

are resolved according to adocumented procedure. (L2-51, A6)

Changes to thesubcontract

are made with the involvement andagreement of both the primecontractor and the subcontractor.(L2-45, C1, 3)

Contractualagreement(s)

form the basis for managing thesubcontract. (L2-45, C1, 2)

Functions orsubsystems to besubcontracted

are selected to match the skills andcapabilities of potentialsubcontractors. (L2-47, A1, 1.1)

Measurements (todetermine the statusof the activities formanaging thesoftware subcontract)



Nonconformance tothe subcontract

is addressed. (L2-52, A7, 6)

Plan for selecting asubcontractor

q is prepared concurrent with thesubcontract statement of work.(L2-48, A1, 4)

q is reviewed, as appropriate. (L2-48, A1, 4)

Results of theacceptance tests








Significant issues,action items, anddecisions resultingfrom formal reviewsof the subcontractor'ssoftware engineeringaccomplishments

q are identified. (L2-53, A9, 3)


Software productsand activities to besubcontracted

are selected based on a balancedassessment of both technical andnontechnical characteristics of theproject. (L2-47, A1, 1)

Specification of thesoftware products andactivities to besubcontracted

is determined based on a systematicanalysis and appropriate partitioningof the system and softwarerequirements. (L2-47, A1, 1.2)

Specification of workto be subcontracted

is derived from the project’s: (L2-47, A1, 2)

q statement of work,

q system requirements allocated tosoftware,

q software requirements,

q software development plan, and

q software standards andprocedures.

Subcontractstatement of work

is: (L2-47, A1, 3)

q prepared,

q reviewed,

q agreed to,

q revised when necessary, and

q managed and controlled.







Subcontractor'ssoftwaredevelopment plan


q is reviewed and approved by theprime contractor. (L2-51, A4)

q covers (directly or by reference)the appropriate items from theprime contractor's softwaredevelopment plan. (L2-51, A4,1)

q is used for tracking the softwareactivities and communicatingstatus. (L2-51, A5)

q is refined, as appropriate. (L2-53, A9, 5)

Work to besubcontracted

is defined and planned according toa documented procedure. (L2-47,A1)

The CMM recommends that the conditions described in the table below besatisfied to exit the software subcontract management process.



Documented standards and procedures are used in selectingsoftware subcontractors and managing the softwaresubcontracts. (L2-45, C1, 1)





General exitcriteria,continued

The CMM recommends that the conditions described in the table below besatisfied to exit the software subcontract management process, continued from theprevious page.


The prime contractor's management conducts periodicstatus/coordination reviews with the softwaresubcontractor's management. (L2-51, A7)

q The subcontractor is provided with visibility of theneeds and desires of the product's customers and endusers, as appropriate.

q The subcontractor's technical, cost, staffing, andschedule performance is reviewed against thesubcontractor's software development plan.

q Computer resources designated as critical for the projectare reviewed; the subcontractor's contribution to thecurrent estimates are tracked and compared to theestimates for each software component as documentedin the subcontractor's software development plan.

q Critical dependencies and commitments between thesubcontractor's software engineering group andother subcontractor groups are addressed.

q Critical dependencies and commitments between theprime contractor and the subcontractor areaddressed.

q Subcontractor commitments to the primecontractor and prime contractor commitments tothe subcontractor are both reviewed.

q Nonconformance to the subcontract is addressed.

q Project risks involving the subcontractor's work areaddressed.

q Conflicts and issues not resolvable internally by thesubcontractor are addressed.

q Action items are assigned, reviewed, and tracked toclosure.

Periodic technical reviews and interchanges are held withthe software subcontractor. (L2-52, A8)






The CMM recommends that the conditions described in the table below besatisfied to exit the software subcontract management process, continued from theprevious page.





The software subcontractor’s performance is evaluated on aperiodic basis, and the evaluation is reviewed with thesubcontractor. (L2-55, A13)

The activities for managing the software subcontract arereviewed with senior management on a periodic basis.(L2-56, V1)

The activities for managing the software subcontract arereviewed with the project manager on both a periodic andevent-driven basis. (L2-56, V2)

The software quality assurance group reviews and/oraudits the activities and work products for managing thesoftware subcontract and reports the results. (L2-57, V3)


SSM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the softwaresubcontract management process.


References

A documented subcontractor's softwaredevelopment plan is reviewed andapproved by the prime contractor. (L2-51, A4)

q This software development plan covers(directly or by reference) theappropriate items from the primecontractor's software development plan.

Primecontractor


q The subcontractor is provided withvisibility of the needs and desires ofthe product's customers and endusers, as appropriate.

q The subcontractor's technical, cost,staffing, and schedule performance isreviewed against the subcontractor'ssoftware development plan.

q Computer resources designated ascritical for the project are reviewed;the subcontractor's contribution to thecurrent estimates are tracked andcompared to the estimates for eachsoftware component as documented inthe subcontractor's softwaredevelopment plan.

q Critical dependencies andcommitments between thesubcontractor's softwareengineering group and othersubcontractor groups are addressed.


Software sub-contractor'smanagement

Subcontractor

Sub-contractor'ssoftwareengineeringgroup

Subcontractorgroups

Review continues on the next page



SSM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the softwaresubcontract management process, continued from the previous page.


References

Review continued from previous page

q Critical dependencies andcommitments between the primecontractor and the subcontractor areaddressed.


q Nonconformance to the subcontract isaddressed.

q Project risks involving thesubcontractor's work are addressed.

q Conflicts and issues not resolvableinternally by the subcontractor areaddressed.


Primecontractor

Subcontractor

Periodic technical reviews andinterchanges are held with the softwaresubcontractor. (L2-52, A8)

These reviews:

q Provide the subcontractor withvisibility of the customer's and endusers' needs and desires, asappropriate.

q Monitor the subcontractor's technicalactivities.

q Verify that the subcontractor'sinterpretation and implementation ofthe technical requirements conform tothe prime contractor's requirements.

q Verify that commitments are beingmet.

q Verify that technical issues areresolved in a timely manner.

Softwaresubcontractor

Subcontractor


SSM Process - Rev iews and Aud i ts , Continued




References

Formal reviews to address thesubcontractor's software engineeringaccomplishments and results areconducted at selected milestonesaccording to a documented procedure.(L53, A9)

q Reviews are preplanned anddocumented in the statement of work.(L53, A9, 1)

q Reviews address the subcontractor'scommitments for, plans for, and statusof the software activities. (L2-53, A9,2)

Not specifiedin CMM

The prime contractor’s software qualityassurance group monitors thesubcontractor’s software qualityassurance activities according to adocumented procedure. (L2, 53, A10)

q The subcontractor's plans, resources,procedures, and standards for softwarequality assurance are periodicallyreviewed to ensure they are adequateto monitor the subcontractor'sperformance. (L2-54, A10, 1)

Primecontractor'sSQA group

Regular reviews of the subcontractor areconducted to ensure the approvedprocedures and standards are beingfollowed. (L2-54, A10, 2)

q The prime contractor's softwarequality assurance group spot checksthe subcontractor's softwareengineering activities and products.

q The prime contractor's softwarequality assurance group audits thesubcontractor's software qualityassurance records, as appropriate.

Subcontractor



The subcontractor's records of its softwarequality assurance activities areperiodically audited to assess how well thesoftware quality assurance plans,standards, and procedures are beingfollowed. (L2-54, A10, 3)








References

The subcontractor's plans, resources,procedures, and standards for softwareconfiguration management are reviewed toensure they are adequate. (L2-54, A11, 1)


The subcontractor's software baselinelibrary is periodically audited to assesshow well the standards and procedures forsoftware configuration management arebeing followed and how effective they arein managing the software baseline. (L2-54, A11, 3)


The acceptance procedures andacceptance criteria for each product aredefined, reviewed, and approved by boththe prime contractor and thesubcontractor prior to the test. (L2-55,A12, 1)

Primecontractor

Subcontractor

The software subcontractor's performanceis evaluated on a periodic basis, and theevaluation is reviewed with thesubcontractor. (L2-55, A13)

Subcontractor

The activities for managing the softwaresubcontract are reviewed with seniormanagement on a periodic basis. (L2-56,V1)

Seniormanagement

The activities for managing the softwaresubcontract are reviewed with the projectmanager on both a periodic and event-driven basis. (L2-56, V2)

Projectmanager







References

The software quality assurance groupreviews and/or audits the activities andwork products for managing the softwaresubcontract and reports the results. (L2-57,V3)


q The activities for selecting thesubcontractor.

q The activities for managing thesoftware subcontract.

q The activities for coordinatingconfiguration management activities ofthe prime contractor andsubcontractor.

q The conduct of planned reviews withthe subcontractor.

q The conduct of reviews that establishcompletion of key project milestonesor stages for the subcontract.

q The acceptance process for thesubcontractor's software products.

SQA group


SSM Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the software subcontract management process.


Subcontract statement of work. (L2-48, A1, 3.5)


SSM Process - Measurements

Measurements The table below lists the measurements recommended for the software subcontractmanagement process.


Measurements are made and used to determine the status ofthe activities for managing the software subcontract. (L2-55, M1)


q Costs of the activities for managing the subcontractcompared to the plan.

q Actual delivery dates for subcontracted productscompared to the plan.

q Actual dates of prime contractor deliveries to thesubcontractor compared to the plan.


SSM Process - Documented Procedures


The table below lists the activities for the software subcontract managementprocess recommended to be performed according to a documented procedure.

Documented Procedure(s) References

The work to be subcontracted is defined and plannedaccording to a documented procedure. (L2-47, A1)




Changes to the software subcontractor's statement of work,subcontract terms and conditions, and other commitmentsare resolved according to a documented procedure. (L2-51,A6)











S S M P r o c e s s - T r a i n i n g

Training The table below lists the training recommended for the software subcontractmanagement process.

Training References

Software managers and other individuals who areinvolved in establishing and managing the softwaresubcontract are trained to perform these activities. (L2-46,Ab2)

Software managers and other individuals who areinvolved in managing the software subcontract receiveorientation in the technical aspects of the subcontract. (L2-46, Ab3)


S S M P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the software subcontractmanagement process.

Tools References

Tools to support managing the subcontract. (L2-46, Ab1, 2)


q estimating models,


q project management and scheduling programs.


Software Qual i ty Assurance (SQA) Process

SQA Process - Overv iew

The purpose of Software Quality Assurance is to provide management withappropriate visibility into the process being used by the software project and of theproducts being built. (L2-59)

SQA processpurpose

Software Quality Assurance involves reviewing and auditing the software productsand activities to verify that they comply with the applicable procedures andstandards and providing the software project and other appropriate managers withthe results of these reviews and audits.

The software quality assurance group works with the software project during itsearly stages to establish plans, standards, and procedures that will add value tothe software project and satisfy the constraints of the project and theorganization's policies. By participating in establishing the plans, standards, andprocedures, the software quality assurance group helps ensure they fit the project'sneeds and verifies that they will be usable for performing reviews and auditsthroughout the software life cycle. The software quality assurance group reviewsproject activities and audits software work products throughout the life cycle andprovides management with visibility as to whether the software project is adheringto its established plans, standards, and procedures.

Compliance issues are first addressed within the software project and resolvedthere if possible. For issues not resolvable within the software project, thesoftware quality assurance group escalates the issue to an appropriate level ofmanagement for resolution.

This key process area covers the practices for the group performing the softwarequality assurance function. The practices identifying the specific activities andwork products that the software quality assurance group reviews and/or audits aregenerally contained in the Verifying Implementation common feature of the otherkey process areas. (L2-59)

SQA processdescription



SQA Process - Overv iew , Continued

Sectionoverview




L2-Process-131



L2-Process-137


L2-Process-138


L2-Process-140


L2-Process-142

Reviews andAudits




L2-Process-149




L2-Process-151




SQA Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware quality assurance process.


Affectedgroups

The SQA plan is reviewed by the affectedgroups and individuals. (L2-63, A1, 2)

Affectedindividuals


Customer The deliverable software products areevaluated before they are delivered to thecustomer. (L2-66, A5, 1)

Customer’sSQApersonnel

The SQA group conducts periodic reviewsof its activities and findings with thecustomer's SQA personnel, asappropriate. (L2-67, A8)

Expertsindependentof the SQAgroup

Experts independent of the SQA groupperiodically review the activities andsoftware work products of the project’sSQA group. (L2-69, V3)

Manager q A manager is assigned specificresponsibilities for the project's SQAactivities. (L2-62, Ab2, 1)

q All managers in the SQA reportingchain to the senior manager areknowledgeable in the SQA role,responsibilities, and authority. (L2-62,Ab2, 2.1)



SQA Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware quality assurance process, continued from the previous page.


Projectmanager

q Deviations from the softwaredevelopment plan and the designatedproject standards and procedures aredocumented and resolved with theappropriate software task leaders,software managers, or projectmanager, where possible. (L2-67, A7,1)

q Deviations from the softwaredevelopment plan and the designatedproject standards and procedures notresolvable with the software taskleaders, software managers, or projectmanager are documented andpresented to the senior managerdesignated to receive noncomplianceitems. (L2-67, A7, 2)

q The SQA activities are reviewed withthe project manager on both aperiodic and event-driven basis. (L2-69,V2)

Seniormanagement

q Senior management periodicallyreviews the SQA activities and results.(L2-61, C1, 3)

q The SQA activities are reviewed withsenior management on a periodicbasis. (L2-68, V1)




Roles,continued



Seniormanager

q A senior manager, who isknowledgeable in the SQA role and hasthe authority to take appropriateoversight actions, is designated toreceive and act on softwarenoncompliance items. (L2-62, Ab2, 2)

q Deviations from the softwaredevelopment plan and the designatedproject standards and procedures notresolvable with the software taskleaders, software managers, or projectmanager are documented and presentedto the senior manager designated toreceive noncompliance items. (L2-67,A7, 2)

q Noncompliance items presented to thesenior manager are periodicallyreviewed until they are resolved. (L2-67, A7, 3)


The SQA group periodically reports theresults of its activities to the softwareengineering group. (L2-67, A6)

Softwaremanager

q Deviations from the softwaredevelopment plan and the designatedproject standards and procedures aredocumented and resolved with theappropriate software task leaders,software managers, or projectmanager, where possible. (L2-67, A7,1)





Roles,continued



Software taskleader

q Deviations from the softwaredevelopment plan and the designatedproject standards and procedures aredocumented and resolved with theappropriate software task leaders,software managers, or project manager,where possible. (L2-67, A7, 1)


SQA group q Members of the SQA group aretrained to perform their SQA activities.(L2-62, Ab3)

q The SQA group's activities areperformed in accordance with the SQAplan. (L2-64, A2)

q The SQA group participates in thepreparation and review of the project'ssoftware development plan, standards,and procedures. (L2-65, A3)

Role continues on next page




Roles,continued



SQA group,continued

q The SQA group provides consultationand review of the plans, standards, andprocedures with regard to: (L2-66, A3,1)

q compliance to organizationalpolicy,

q compliance to externally imposedstandards and requirements (e.g.,standards imposed by the statementof work),

q standards that are appropriate foruse by the project,

q topics that should be addressed inthe software development plan, and

q other areas assigned by the project.

q The SQA group verifies that plans,standards, and procedures are in placeand can be used to review and auditthe software project. (L2-66, A3, 2)

q The SQA group reviews the softwareengineering activities to verifycompliance. (L2-66, A4)

q The SQA group audits designatedsoftware work products to verifycompliance. (L2-66, A5)

q The SQA group periodically reportsthe results of its activities to thesoftware engineering group. (L2-67,A6)

q The SQA group conducts periodicreviews of its activities and findingswith the customer's SQA personnel, asappropriate. (L2-67, A8)


SQA Process - Entry Cr i ter ia


There are no input-based entry criteria in the software quality assurance process.


The CMM recommends that the conditions described in the table below besatisfied before entering the software quality assurance process.


The project follows a written organizational policy forimplementing software quality assurance (SQA). (L2-60,C1)

[Refer to Level 2 Policies for additional informationregarding SQA policy.]

A group that is responsible for coordinating andimplementing SQA for the project (i.e., the SQA group)exists. (L2-61, Ab1)

Adequate resources and funding are provided for performingthe SQA activities. (L2-62, Ab2)

A manager is assigned specific responsibilities for theproject's SQA activities. (L2-62, Ab2, 1)

A senior manager, who is knowledgeable in the SQA roleand has the authority to take appropriate oversight actions,is designated to receive and act on software noncomplianceitems. (L2-62, Ab2, 2)

All managers in the SQA reporting chain to the seniormanager are knowledgeable in the SQA role,responsibilities, and authority. (L2-62, Ab2, 2.1)

Tools to support the SQA activities are made available.(L2-62, Ab2, 3)

Members of the SQA group are trained to perform theirSQA activities. (L2-62, Ab3)

The members of the software project receive orientationon the role, responsibilities, authority, and value of the SQAgroup. (L2-63, Ab4)


SQA Process - Inputs

Inputs The table below lists the recommended inputs to the software quality assuranceprocess.


Deliverable software products. (L2-66, A5,1)

Designated contractual requirements. (L2-66, A5, 2)

Designated procedures. (L2-66, A4, 1)

Designated software standards. (L2-66,A4, 1)

Designated software work products. (L2-66, A5)

Externally imposed requirements. (L2-66,A3, 1.2)

Externally imposed standards. (L2-66, A3,1.2)

Project's procedures. (L2-65, A3)

Project's software development plan. (L2-65, A3)

Project's standards. (L2-65, A3)

Software work products. (L2-66, A5, 2)

SQA plan. (L2-64, A2)


SQA Process - Act iv i t ies

Activities The table below lists the recommended activities for the software qualityassurance process.


A SQA plan is prepared for the software project according toa documented procedure. (L2-63, A1)


The SQA group participates in the preparation and reviewof the project's software development plan, standards, andprocedures. (L2-65, A3)

q The SQA group provides consultation and review of theplans, standards, and procedures with regard to:

q compliance to organizational policy,

q compliance to externally imposed standards andrequirements (e.g., standards required by thestatement of work),

q standards that are appropriate for use by the project,

q topics that should be addressed in the softwaredevelopment plan, and

q other areas as assigned by the project.

q The SQA group verifies that plans, standards, andprocedures are in place and can be used to review andaudit the software project.

The SQA group reviews the software engineering activitiesto verify compliance. (L2-66, A4)

q The activities are evaluated against the softwaredevelopment plan and the designated software standardsand procedures.

q Deviations are identified, documented, and tracked toclosure.

q Corrections are verified.


The SQA group audits designated software work productsto verify compliance. (L2-66, A5)

q The deliverable software products are evaluated beforethey are delivered to the customer.

q The software work products are evaluated against thedesignated software standards, procedures, andcontractual requirements.

q Deviations are identified, documented, and tracked toclosure.

q Corrections are verified.



SQA Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software qualityassurance process, continued from the previous page.


The SQA group periodically reports the results of itsactivities to the software engineering group. (L2-67, A6)

Deviations identified in the software activities and softwarework products are documented and handled according to adocumented procedure. (L2-67, A7)


The SQA group conducts periodic reviews of its activitiesand findings with the customer's SQA personnel, asappropriate. (L2-67, A8)

Measurements are made and used to determine the cost andschedule status of the SQA activities. (L2-68, M1)

The SQA activities are reviewed with senior managementon a periodic basis. (L2-68, V1)

The SQA activities are reviewed with the project manageron a periodic and event-driven basis. (L2-69, V2)

Experts independent of the SQA group periodicallyreview the activities and software work products of theproject's SQA group. (L2-69, V3)


SQA Process - Outputs

Outputs The table below lists the outputs produced by the software quality assuranceprocess.


Corrections to deviations between thecontractual requirements and thedesignated software work products. (L2-67, A5, 4)

Corrections to deviations between thedesignated software procedures and thedesignated software work products. (L2-67, A5, 4)

Corrections to deviations between thedesignated software procedures and thesoftware engineering activities. (L2-66,A4, 3)

Corrections to deviations between thedesignated software standards and thedesignated software work products. (L2-67, A5, 4)

Corrections to deviations between thedesignated software standards and thesoftware engineering activities. (L2-66,A4, 3)

Corrections to deviations between thesoftware development plan and thesoftware engineering activities. (L2-66,A4, 3)

Deviations between the contractualrequirements and the designated softwarework products. (L2-67, A5, 3)

Deviations between the designatedsoftware procedures and the designatedsoftware work products. (L2-67, A5, 3)

Deviations between the designatedsoftware procedures and the softwareengineering activities. (L2-66 A4, 2)

Deviations between the designatedsoftware standards and the designatedsoftware work products. (L2-67, A5, 3)

Deviations between the designatedsoftware standards and the softwareengineering activities. (L2-66 A4, 2)


SQA Process - Outputs , Continued

Outputs,continued

The table below lists the outputs produced by the software quality assuranceprocess, continued from the previous page.


Deviations between the softwaredevelopment plan and the softwareengineering activities. (L2-66 A4, 2)

Deviations from the designated projectprocedures. (L2-67, A7, 1)

Deviations from the designated projectstandards. (L2-67, A7, 1)

Deviations from the software developmentplan. (L2-67, A7, 1)

Deviations identified in the softwareactivities. (L2-67, A7)

Deviations identified in the software workproducts. (L2-67, A7)

Documentation of noncompliance items.(L2-67, A7, 4)

Measurements (to determine the cost andschedule status of the SQA activities).(L2-68, M1)

Results of SQA group activities. (L2-67,A6)

Software noncompliance items. (L2-62,Ab2, 2)

Software work products of the SQA group.(L2-69, V3)

SQA findings. (L2-67, A8)

SQA plan. (L2-63, A1)

[Refer to Level 2 Standards for additionalinformation regarding a SQA plan.]

SQA results. (L2-61, C1, 3)


SQA Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software quality assurance process.


Corrections todeviations betweenthe contractualrequirements and thedesignated softwarework products


Corrections todeviations betweenthe designatedsoftware proceduresand the designatedsoftware workproducts


Corrections todeviations betweenthe designatedsoftware proceduresand the softwareengineering activities


Corrections todeviations betweenthe designatedsoftware standardsand the designatedsoftware workproducts


Corrections todeviations betweenthe designatedsoftware standardsand the softwareengineering activities


Corrections todeviations betweenthe softwaredevelopment planand the softwareengineering activities



Deviations betweenthe contractualrequirements and thedesignated softwarework products






SQA Process - Exi t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software quality assurance process, continued from the previous page.


Deviations betweenthe designatedsoftware proceduresand the designatedsoftware workproducts




Deviations betweenthe designatedsoftware proceduresand the softwareengineering activities




Deviations betweenthe designatedsoftware standardsand the designatedsoftware workproducts




Deviations betweenthe designatedsoftware standardsand the softwareengineering activities




Deviations betweenthe softwaredevelopment planand the softwareengineering activities




Deviations from thedesignated projectprocedures


q are resolved with the appropriatesoftware task leaders, softwaremanagers, or project manager,where possible. (L2-67, A7, 1)

q not resolvable with the softwaretask leaders, softwaremanagers, or project managerare documented and presented tothe senior manager designatedto receive noncompliance items.(L2-67, A7, 2)







Deviations from thedesignated projectstandards




Deviations from thesoftwaredevelopment plan




Deviations identifiedin the softwareactivities


q are handled according to adocumented procedure. (L2-67,A7)

Deviations identifiedin the software workproducts


q are handled according to adocumented procedure. (L2-67,A7)

Measurements (todetermine the costand schedule statusof the SQAactivities)









Noncomplianceitems (presented tothe senior manager)

q are periodically reviewed untilthey are resolved. (L2-67, A7,3)


q documentation is managed andcontrolled. (L2-67, A7, 4)

Results of SQAgroup activities

are periodically reported to thesoftware engineering group. (L2-67, A6)

SQA plan q is prepared for the softwareproject according to adocumented procedure. (L2-63,A1)

q is developed in the early stagesof, and in parallel with, theoverall project planning. (L2-63,A1, 1)

q is reviewed by the affectedgroups and individuals. (L2-63, A1, 2)


SQA results are reviewed periodically by seniormanagement. (L2-61, C1, 3)

The CMM recommends that the conditions described in the table below besatisfied to exit the software quality assurance process.



The SQA group's activities are performed in accordancewith the SQA plan. (L2-64, A2)





The CMM recommends that the conditions described in the table below besatisfied to exit the software quality assurance process, continued from theprevious page.


The SQA group participates in the preparation and reviewof the project's software development plan, standards, andprocedures. (L2-65, A3)

q The SQA group provides consultation and review of theplans, standards, and procedures with regard to:


q compliance to externally imposed standards andrequirements (e.g., standards required by thestatement of work),

q standards that are appropriate for use by the project,

q topics that should be addressed in the softwaredevelopment plan, and


q The SQA group verifies that plans, standards, andprocedures are in place and can be used to review andaudit the software project.

The SQA group reviews the software engineering activitiesto verify compliance. (L2-66, A4)

The software engineering activities are evaluated againstthe software development plan and the designated softwarestandards and procedures. (L2-66, A4, 1)

The SQA group audits designated software work productsto verify compliance. (L2-66, A5)

q The deliverable software products are evaluated beforethey are delivered to the customer.

q The software work products are evaluated against thedesignated software standards, procedures, andcontractual requirements.

The SQA group conducts periodic reviews of its activitiesand findings with the customer's SQA personnel, asappropriate. (L2-67, A8)

The SQA activities are reviewed with senior managementon a periodic basis. (L2-68, V1)

The SQA activities are reviewed with the project manageron a periodic and event-driven basis. (L2-69, V2)


Experts independent of the SQA group periodicallyreview the activities and software work products of theproject's SQA group. (L2-69, V3)


SQA Process - Reviews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the software qualityassurance process.


References

Senior management periodically reviewsthe SQA activities and results. (L2-61,C1, 3)

Seniormanagement


Affectedgroups

Affectedindividuals

The SQA group participates in thepreparation and review of the project'ssoftware development plan, standards, andprocedures. (L2-65, A3)

SQA group

The SQA group provides consultation andreview of the plans, standards, andprocedures with regard to: (L2-66, A3, 1)


q compliance to externally imposedstandards and requirements (e.g.,standards required by the statement ofwork),

q standards that are appropriate for useby the project,

q topics that should be addressed in thesoftware development plan, and


SQA group

The SQA group reviews the softwareengineering activities to verifycompliance. (L2-66, A4)

SQA group

The SQA group audits designatedsoftware work products to verifycompliance. (L2-66, A5)

SQA group

The SQA group conducts periodic reviewsof its activities and findings with thecustomer's SQA personnel, asappropriate. (L2-67, A8)

SQA group

Customer'sSQApersonnel

The SQA activities are reviewed withsenior management on a periodic basis.(L2-68, V1)

Seniormanagement


SQA Process - Reviews and Audi ts , Continued


The table below lists the recommended reviews and audits for the software qualityassurance process, continued from the previous page.


References

The SQA activities are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-69, V2)

Projectmanager

Experts independent of the SQA groupperiodically review the activities andsoftware work products of the project'sSQA group. (L2-69, V3)


SQA group


SQA Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the software quality assurance process.


SQA plan. (L2-64, A1, 3)

Documentation of noncompliance items. (L2-67, A7, 4)


SQA Process - Measurements

Measurements The table below lists the measurements recommended for the software qualityassurance process.


Measurements are made and used to determine the cost andschedule status of SQA activities. (L2-68, M1)


q Completions of milestones for the SQA activitiescompared to the plan.

q Work completed, effort expended, and funds expendedin the SQA activities compared to the plan.

q Numbers of product audits and activity reviewscompared to the plan.


SQA Process - Documented Procedures


The table below lists the activities for the software quality assurance processrecommended to be performed according to a documented procedure.







SQA Process - T ra in ing

Training The table below lists the training recommended for the software quality assuranceprocess.

Training References

Members of the SQA group are trained to perform theirSQA activities. (L2-62, Ab3)

The members of the software project receive orientation onthe role, responsibilities, authority, and value of the SQAgroup. (L2-63, Ab4)


SQA Process - Too ls

Tools The table below lists the tools recommended for the software quality assuranceprocess.

Tools References

Tools to support the SQA activities. (L2-62, Ab2, 3)


q workstations,

q database programs,


q auditing tools.


Sof tware Conf igurat ion Management (SCM)Process

S C M P r o c e s s - O v e r v i e w

The purpose of Software Configuration Management is to establish and maintainthe integrity of the products of the software project throughout the project'ssoftware life cycle. (L2-71)

SCM processpurpose

Software Configuration Management involves identifying the configuration of thesoftware (i.e., selected software work products and their descriptions) at givenpoints in time, systematically controlling changes to the configuration, andmaintaining the integrity and traceability of the configuration throughout thesoftware life cycle. The work products placed under software configurationmanagement include the software products that are delivered to the customer(e.g., the software requirements document and the code) and the items that areidentified with or required to create these software products (e.g., the compiler).

A software baseline library is established containing the software baselines asthey are developed. Changes to baselines and the release of software productsbuilt from the software baseline library are systematically controlled via thechange control and configuration auditing functions of software configurationmanagement.

This key process area covers the practices for performing the softwareconfiguration management function. The practices identifying specificconfiguration items/units are contained in the key process areas that describe thedevelopment and maintenance of each configuration item/unit. (L2-71)

SCM processdescription



S C M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L2-Process-157



L2-Process-162


L2-Process-163


L2-Process-165


L2-Process-166

Reviews andAudits




L2-Process-174




L2-Process-176




SCM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware configuration management process.


Affectedgroups

q The SCM plan is reviewed by theaffected groups.

q The configuration management librarysystem provides for the sharing andtransfer of configuration items/unitsbetween the affected groups andbetween control levels within thelibrary. (L2-78, A3, 3)

q Standard reports documenting the SCMactivities and the contents of thesoftware baseline are developed andmade available to affected groups andindividuals. (L2-81, A9)

Affectedindividuals

Standard reports documenting the SCMactivities and the contents of the softwarebaseline are developed and made availableto affected groups and individuals. (L2-81, A9)

Manager A manager is assigned specificresponsibilities for SCM. (L2-75, Ab3, 1)

Personresponsiblefor eachconfigurationunit/item

The person responsible for eachconfiguration item/unit (i.e., the owner,from a configuration management point ofview) is identified. (L2-79, A4, 6)

Projectmanager

The SCM activities are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-83, V2)


The results of software baseline audits arereported to the project software manager.(L2-82, A10, 6)

Seniormanagement

The SCM activities are reviewed withsenior management on a periodic basis.(L2-82, V1)



SCM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware configuration management process, continued from the previous page.


Softwareconfigurationcontrol board(SCCB)

q A board having the authority formanaging the project’s softwarebaselines (i.e., a softwareconfiguration control board - SCCB)exists or is established. (L2-73, Ab1)

The SCCB:

q Authorizes the establishment ofsoftware baselines and theidentification of configurationitems/units.

q Represents the interests of theproject manager and all groups whomay be affected by changes to thesoftware baselines.

q Reviews and authorizes changes tothe software baselines.

q Authorizes the creation of productsfrom the software baseline library.

q Only configuration items/units that areapproved by the SCCB are entered intothe software baseline library. (L2-80,A6, 2)




Roles,continued



Softwareconfigurationmanagement(SCM) group

q A group that is responsible forcoordinating and implementing SCMfor the project (i.e., the SCM group)exists. (L2-74, Ab2)

The SCM group coordinates orimplements:

q Creation and management of theproject's software baseline library.

q Development, maintenance, anddistribution of the SCM plans,standards, and procedures.

q The identification of the set ofwork products to be placed underSCM.

q Management of the access to thesoftware baseline library.

q Updates of the software baselines.

q Creation of products from thesoftware baseline library.

q Recording of SCM actions.

q Production and distribution of SCMreports.

q Members of the SCM group aretrained in the objectives, procedures,and methods for performing their SCMactivities. (L2-76, Ab4)

q The SCM group periodically auditssoftware baselines to verify that theyconform to the documentation thatdefines them. (L2-83, V3)


Members of the software engineeringgroup and other software-related groupsare trained to perform their SCM activities.(L2-76, Ab5)




Roles,continued




q Members of the software engineeringgroup and other software-relatedgroups are trained to perform theirSCM activities. (L2-76, Ab5)

q The SCM plan covers the SCMrequirements and activities to beperformed by the software engineeringgroup and other software-relatedgroups. (L2-77, A2, 2)

SQA group The software quality assurance groupreviews and/or audits the activities andwork products for SCM and reports theresults. (L2-83, V4)


SCM Process - Ent ry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the software configuration management process.


Change requests forconfigurationitems/units

are initiated according to adocumented procedure. (L2-79, A5)

Problem reports forconfigurationitems/units

are initiated according to adocumented procedure. (L2-79, A5)

SCM plan q is documented. (L2-77, A2)


The CMM recommends that the conditions described in the table below besatisfied before entering the software configuration management process.



The project follows a written organizational policy forimplementing software configuration management (SCM).(L2-72, C1)

[Refer to Level 2 Policies for additional informationregarding SCM policy.]

Responsibility for SCM for each project is explicitlyassigned. (L2-72, C1, 1)

A board having the authority for managing the project'ssoftware baselines (i.e., a software configuration controlboard - SCCB) exists or is established. (L2-73, Ab1)

A group that is responsible for coordinating andimplementing SCM for the project (i.e., the SCM group)exists. (L2-74, Ab2)

Adequate resources and funding are provided for performingthe SCM activities. (L2-75, Ab3)

A manager is assigned specific responsibilities for SCM.(L2-75, Ab3, 1)

Tools to support the SCM activities are made available.(L2-75, Ab3, 2)

Members of the SCM group are trained in the objectives,procedures, and methods for performing their SCMactivities. (L2-76, Ab4)


Members of the software engineering group and othersoftware-related groups are trained to perform their SCMactivities. (L2-76, Ab5)


SCM Process - Inputs

Inputs The table below lists the recommended inputs to the software configurationmanagement process.


Change requests for configurationitems/units. (L2-79, A5)

Changes to baselines. (L2-80, A6)

Configuration items/units. (L2-78, A3, 2)

Designated internal software workproducts. (L2-72, C1, 3)

Designated support tools used inside theproject. (L2-72, C1, 3)

Externally deliverable software products.(L2-72, C1, 3)

Problem reports for configurationitems/units. (L2-79, A5)

SCM plan. (L2-77, A2)

[Refer to Level 2 Standards for additionalinformation regarding a SCM plan.]

Software baselines. (L2-73, C1, 5)

Software work products. (L2-78, A4)

Updates of the software baselines. (L2-75,Ab2, 5)

Work products to be placed under SCM.(L2-75, Ab2, 3)


SCM Process - Act iv i t ies

Activities The table below lists the recommended activities for the software configurationmanagement process.


A SCM plan is prepared for each software project accordingto a documented procedure. (L2-76, A1)


A documented and approved SCM plan is used as the basisfor performing the SCM activities. (L2-77, A2)

A configuration management library system is establishedas a repository for the software baselines. (L2-77, A3)

[Refer to SCM Process Tools for additional informationregarding a configuration management library system.]

The software work products to be placed under configurationmanagement are identified. (L2-78, A4)

q The configuration items/units are selected based ondocumented criteria.

q The configuration items/units are assigned uniqueidentifiers.

q The characteristics of each configuration item/unit arespecified.

q The software baselines to which each configurationitem/unit belongs are specified.

q The point in its development that each configurationitem/unit is placed under configuration management isspecified.

q The person responsible for each configuration item/unit(i.e., the owner, from a configuration management pointof view) is identified.

Change requests and problem reports for all configurationitems/units are initiated, recorded, reviewed, approved, andtracked according to a documented procedure. (L2-79, A5)

Changes to baselines are controlled according to adocumented procedure. (L2-80, A6)




SCM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software configurationmanagement process, continued from the previous page.


Products from the software baseline library are created andtheir release is controlled according to a documentedprocedure. (L2-80, A7,)


The status of configuration items/units is recorded accordingto a documented procedure. (L2-80, A8)


Standard reports documenting the SCM activities and thecontents of the software baseline are developed and madeavailable to affected groups and individuals. (L2-81, A9)

Software baseline audits are conducted according to adocumented procedure. (L2-81, A10)


Measurements are made and used to determine the status ofthe SCM activities. (L2-82, M1)

The SCM activities are reviewed with senior managementon a periodic basis. (L2-82, V1)

The SCM activities are reviewed with the project manageron both a periodic and event-driven basis. (L2-83, V2)

The SCM group periodically audits software baselines toverify that they conform to the documentation that definesthem. (L2-83, V3)

The software quality assurance group reviews and/oraudits the activities and work products for SCM and reportsthe results. (L2-83, V4)

[Refer to SCM Process Reviews and Audits for additionalinformation.]


SCM Process - Outputs

Outputs The table below lists the recommended outputs produced by the softwareconfiguration management process.


Action items from the software baselineaudit. (L2-82, A10, 7)

Archive versions of configurationitems/units. (L2-78, A3, 5)

Changes to the software baselines. (L2-74,Ab1, 3)

Configuration items/units. (L2-73, Ab1, 1)

Current status and history (i.e., changesand other actions) of each configurationitem/unit. (L2-81, A8, 2)

Measurements (to determine the status ofthe SCM activities). (L2-82, M1)

Products from the software baseline library.(L2-74, Ab1, 4)

Project's software baseline library (orrepository). (L2-75, Ab2, 1)

Results of the software baseline audit.(L2-82, A10, 6)

Results of SQA group reviews and/oraudits of the activities and work productsfor SCM. (L2-83, V4)

SCM plan. (L2-75, Ab2, 2)

SCM procedures. (L2-75, Ab2, 2)

SCM records. (L2-72, C1, 4)

SCM reports. (L2-75, Ab2, 8)

SCM standards. (L2-75, Ab2, 2)

Software baselines. (L2-73, Ab1)

Standard reports documenting the SCMactivities and the contents of the softwarebaseline. (L2-81, A9)

Work products to be placed under SCM.(L2-75, Ab2, 3)


SCM Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software configuration management process.


Action items fromthe software baselineaudit

are tracked to closure. (L2-82, A10,7)

Changes to thesoftware baselines

q are reviewed by the SCCB. (L2-74, Ab1, 3)

q are authorized by the SCCB.(L2-74, Ab1, 3)

q are controlled according to adocumented procedure. (L2-80,A6)

Configurationitems/units

q identification is authorized bythe SCCB. (L2-73, Ab1, 1)

q are selected based ondocumented criteria. (L2-79,A4, 1)

q are assigned unique identifiers.(L2-79, A4, 2)

q characteristics are specified.(L2-79, A4, 3)

q are checked in and out in amanner that maintains thecorrectness and integrity of thesoftware baseline library. (L2-80, A6, 3)

q current status and history (i.e.,changes and other actions) aremaintained. (L2-81, A8, 2)

Configurationitem’s/unit’s history(i.e., changes andother actions)

is maintained. (L2-81, A8, 2)

Configurationitem’s/unit’s status

q is recorded according to adocumented procedure. (L2-80,A8)

q is maintained. (L2-81, A8, 2)


Measurements (todetermine the statusof the SCMactivities)





SCM Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software configuration management process, continued from theprevious page.


Products from thesoftware baselinelibrary

q are authorized to be created bythe SCCB. (L2-74, Ab1, 4)

q creation is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 6)

q are created and their release iscontrolled according to adocumented procedure. (L2-80,A7)

q for both internal and externaluse, are built only fromconfiguration items/units in thesoftware baseline library. (L2-80, A7, 2)

Project's softwarebaseline library (orrepository)

q is established or is accessible tothe projects for storingconfiguration items/units and theassociated SCM records. (L2-72, C1, 4)

q creation is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 1)

q management is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 1)

q access management iscoordinated or implemented bythe SCM group. (L2-75, Ab2,4)

q completeness of contents isverified. (L2-81, A10, 4)

q correctness of contents isverified. (L2-81, A10, 4)

Results of thesoftware baselineaudit

are reported to the project softwaremanager. (L2-82, A10, 6)







Results of SQAgroup reviews and/oraudits of theactivities and workproducts for SCM


SCM plan q development is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 2)

q distribution is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 2)

q maintenance is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 2)

q is prepared for each softwareproject according to adocumented procedure. (L2-76,A1)

q is developed in the early stagesof, and in parallel with, overallproject planning. (L2-76, A1, 1)

q is reviewed by the affectedgroups. (L2-77, A1, 2)




q is used as the basis forperforming the SCM activities.(L2-77, A2)


SCM procedures q development is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 2)









SCM reports q distribution is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 8)

q production is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 8)

SCM standards q development is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 2)



Software baselines q are authorized to be establishedby the SCCB. (L2-73, Ab1, 1)

q updates are coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 5)

q to which each configurationitem/unit belongs are specified.(L2-79, A4, 4)

q integrity is assessed. (L2-81,A10, 2)

Standard reportsdocumenting theSCM activities

q are developed. (L2-81, A9)

q are made available to affectedgroups and individuals. (L2-81, A9)

Standard reportsdocumenting thecontents of thesoftware baseline


q are made available to affectedgroups and individuals. (L2-81, A9)

Work products to beplaced under SCM

q identification is coordinated orimplemented by the SCMgroup. (L2-75, Ab2, 3)

q are identified. (L2-78, A4)




The CMM recommends that the conditions described in the table below besatisfied to exit the software configuration management process.


SCM is implemented throughout the project’s life cycle.(L2-72, C1, 2)

SCM is implemented for externally deliverable softwareproducts, designated internal software work products, anddesignated support tools used inside the project (e.g.,compilers). (L272, C1, 3)

The SCM group coordinates or implements the recording ofSCM actions. (L2-75, Ab2, 7)


The point in its development that each configurationitem/unit is placed under configuration management isspecified. (L2-79, A4, 5)

The person responsible for each configuration item/unit (i.e.,the owner, from a configuration management point of view)is identified. (L2-79, A4, 6)


Reviews and/or regression tests are performed to ensure thatchanges have not caused unintended effects on the baseline.(L2-80, A6, 1)

Only configuration items/units that are approved by theSCCB are entered into the software baseline library. (L2-80, A6, 2)

The configuration management actions are recorded insufficient detail so that the content and status of eachconfiguration item/unit are known and previous versions canbe recovered. (L2-81, A8, 1)


The SCM activities are reviewed with senior managementon a periodic basis. (L2-82, V1)

The SCM activities are reviewed with the project manageron both a periodic and event-driven basis. (L2-83, V2)





The CMM recommends that the conditions described in the table below besatisfied to exit the software configuration management process, continued fromthe previous page.


The SCM group periodically audits software baselines toverify that they conform to the documentation that definesthem. (L2-83, V3)

The software quality assurance group reviews and/oraudits the activities and work products for SCM and reportsthe results. (L2-83, V4)


SCM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the softwareconfiguration management process.


References

The software baselines and SCM activitiesare audited on a periodic basis. (L2-73,C1, 5)

Not specifiedin CMM

The SCCB reviews and authorizes changesto the software baselines. (L2-74, Ab1, 3)

SCCB

The SCM plan is reviewed by the affectedgroups. (L2-77, A1, 2)

Affectedgroups

Change requests and problem reports forall configuration items/units are initiated,recorded, reviewed, approved, and trackedaccording to a documented procedure.(L2-79, A5)

Not specifiedin CMM

Reviews and/or regression tests areperformed to ensure that changes have notcaused unintended effects on the baseline.(L2-80, A6, 1)

Not specifiedin CMM

Software baseline audits are conductedaccording to a documented procedure.(L2-81, A10)

Not specifiedin CMM

The SCM activities are reviewed withsenior management on a periodic basis.(L2-82, V1)

Seniormanagement

The SCM activities are reviewed with theproject manager on both a periodic andevent-driven basis. (L2-83, V2)

Projectmanager

The SCM group periodically auditssoftware baselines to verify that theyconform to the documentation that definesthem. (L2-83, V3)

SCM group



SCM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the softwareconfiguration management process, continued from the previous page.


References

The software quality assurance groupreviews and/or audits the activities andwork products for SCM and reports theresults. (L2-83, V4)


q Compliance with the SCM standardsand procedures by:

q the SCM group,

q the SCCB,

q the software engineering group,and

q other software-related groups.

q Occurrence of periodic baseline audits.

SQA group


SCM Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the configuration management process.


SCM plan. (L2-77, A1, 3)


SCM Process - Measurements

Measurements The table below lists the measurements recommended for the softwareconfiguration management process.


Measurements are made and used to determine the status ofthe SCM activities. (L2-82, M1)


q Number of change requests processed per unit time.

q Completions of milestones for the SCM activitiescompared to the plan.

q Work completed, effort expended, and funds expendedin the SCM activities.


SCM Process - Documented Procedures


The table below lists the activities for the software configuration managementprocess recommended to be performed according to a documented procedure.







Products from the software baseline library are created andtheir release is controlled according to a documentedprocedure. (L2-80, A7)







SCM Process - T ra in ing

Training The table below lists the training recommended for the software configurationmanagement process.

Training References

Members of the SCM group are trained in the objectives,procedures, and methods for performing their SCMactivities. (L2-76, Ab4)

Members of the software engineering group and othersoftware-related groups are trained to perform their SCMactivities. (L2-76, Ab5)


S C M P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the software configurationmanagement process.

Tools References

Tools to support the SCM activities. (L2-75, Ab3, 2)


q workstations,

q database programs, and

q configuration management tools.


This library system:

q Supports multiple control levels of SCM.

q Provides for the storage and retrieval of configurationitems/units.

q Provides for the sharing and transfer of configurationitems/units between the affected groups and betweencontrol levels within the library.

q Helps in the use of product standards for configurationitems/units.

q Provides for the storage and recovery of archive versionsof configuration items/units.

q Helps to ensure correct creation of products from thesoftware baseline library.

q Provides for the storage, update, and retrieval of SCMrecords.

q Supports production of SCM reports.

q Provides for the maintenance of the library structure andcontents.


Leve l 2 Procedure Check l is ts

O v e r v i e w

This section describes all the explicit documented procedures recommended inthe Capability Maturity Model for maturity level 2.

Introduction

The purpose of the procedure checklists is to provide:Purpose

• Guidance in identifying which procedures are recommended by the CMM atlevel 2.

• Criteria that an organization can use to evaluate its software procedures todetermine if those procedures are consistent with the CMM at level 2.

• Information that can be used to develop software procedures that are consistentwith the CMM at level 2.

This section covers the following documented procedures:In this section

CMM Level 2 Procedures See Page

Requirements management procedures L2-Procedures-2

Software project planning procedures L2-Procedures-3

Software project tracking & oversight procedures L2-Procedures-6

Software subcontract management procedures L2-Procedures-7

Software quality assurance procedures L2-Procedures-11

Software configuration management procedures L2-Procedures-12

CMU/SEI-94-HB-1 L2-Procedures-1

Requi rements Management (RM) Procedures


There are no recommended documented procedures for the requirementsmanagement process.

L2-Procedures-2 CMU/SEI-94-HB-1

Sof tware Pro jec t P lann ing (SPP) Procedures


The table below lists the recommended documented procedures for the softwareproject planning process.

Documented Procedures References

Software project commitments made to individuals andgroups external to the organization are reviewed with seniormanagement according to a documented procedure. (L2-17, A4)


This procedure typically specifies that:

q The software development plan is based on andconforms to:

q the customer's standards, as appropriate;

q the project's standards;

q the approved statement of work; and

q the allocated requirements.

q Plans for software-related groups and otherengineering groups involved in the activities of thesoftware engineering group are negotiated with thosegroups, the support efforts are budgeted, and theagreements are documented.

q Plans for involvement of the software engineeringgroup in the activities of other software-relatedgroups and other engineering groups are negotiatedwith those groups, the support efforts are budgeted, andthe agreements are documented.

q The software development plan is reviewed by:





q The software development plan is managed andcontrolled.



Sof tware Pro jec t P lann ing (SPP) Procedures ,Continued

Documentedprocedures,continued

The table below lists the recommended documented procedures for the softwareproject planning process, continued from the previous page.




q Size estimates are made for all major software workproducts and activities.

q Software work products are decomposed to thegranularity needed to meet the estimating objectives.

q Historical data are used where available.

q Size estimating assumptions are documented.

q Size estimates are documented, reviewed, and agreedto.



q Estimates for the software project's effort and costs arerelated to the size estimates of the software workproducts (or the size of the changes).

q Productivity data (historical and/or current) are used forthe estimates when available; sources and rationale forthese data are documented.

q The productivity and cost data are from theorganization's projects when possible.

q The productivity and cost data take into account theeffort and significant costs that go into making thesoftware work products.

q Effort, staffing, and cost estimates are based on pastexperience.

q Similar projects should be used when possible.

q Time phasing of activities is derived.

q Distributions of the effort, staffing, and costestimates over the software life cycle are prepared.

q Estimates and the assumptions made in deriving theestimates are documented, reviewed, and agreed to.



Sof tware Pro jec t P lann ing (SPP) Procedures ,Continued


The table below lists the recommended documented procedures for the softwareproject planning process, continued from the previous page.


Estimates for the project's critical computer resources arederived according to a documented procedure. (L2-23, A11)


q Critical computer resources for the project areidentified.

q Estimates for the critical computer resources are relatedto the estimates of:

q The size of the software work products.

q The operational processing load.

q The communications traffic.

q Estimates of the critical computer resources aredocumented, reviewed, and agreed to.



q The software schedule is related to:

q The size estimate of the software work products (orthe size of changes).

q The software effort and costs.

q The software schedule is based on past experience.

q Similar projects are used when possible.

q The software schedule accommodates the imposedmilestone dates, critical dependency dates, and otherconstraints.

q The software schedule activities are of appropriateduration and the milestones are of appropriate timeseparation to support accuracy in progress measurement.

q Assumptions made in deriving the schedule aredocumented.

q The software schedule is documented, reviewed, andagreed to.


Sof tware Pro ject Track ing & Overs ight (SPTO)Procedures


The table below lists the recommended documented procedures for the softwareproject tracking and oversight process.




q The software development plan is revised, asappropriate, to incorporate plan refinements andincorporate plan changes, particularly when planschange significantly.

q The software development plan is updated toincorporate all new software project commitments andchanges to commitments.

q The software development plan is reviewed at eachrevision.

q The software development plan is managed andcontrolled.

Software project commitments and changes to commitmentsmade to individuals and groups external to the organizationare reviewed with senior management according to adocumented procedure. (L2-35, A3)

Formal reviews to address the accomplishments and resultsof the software project are conducted at selected projectmilestones according to a documented procedure. (L2-39.A13)


Sof tware Subcontract Management (SSM)Procedures


The table below lists the recommended documented procedures for the softwaresubcontract management process.

Documented Procedures

The work to be subcontracted is defined and planned according to adocumented procedure. (L2-47, A1)


q The software products and activities to be subcontracted areselected based on a balanced assessment of both technical andnontechnical characteristics of the project.

q The functions or subsystems to be subcontracted are selected tomatch the skills and capabilities of potential subcontractors.

q The specification of the software products and activities to besubcontracted is determined based on a systematic analysis andappropriate partitioning of the system and softwarerequirements.

q The specification of the work to be subcontracted and the standardsand procedures to be followed are derived from the project's:

q statement of work,

q system requirements allocated to software,

q software requirements,

q software development plan, and

q software standards and procedures.

q A subcontract statement of work is:

q prepared,

q reviewed,

q agreed to,

q revised when necessary, and

q managed and controlled.

q A plan for selecting a subcontractor is prepared concurrent withthe subcontract statement of work and is reviewed, as appropriate.



Sof tware Subcontract Management (SSM)Procedures , Continued


The table below lists the recommended documented procedures for the softwaresubcontract management process, continued from the previous page.


The software subcontractor is selected based on an evaluation of thesubcontract bidders' ability to perform the work, according to adocumented procedure. (L2-49, A2)

This procedure covers the evaluation of:

q Proposals submitted for the planned subcontract.

q Prior performance records on similar work, if available.

q The geographic locations of the subcontract bidders'organizations relative to the prime contractor.

q Software engineering and software management capabilities.

q Staff available to perform the work.

q Prior experience in similar applications, including softwareexpertise on the subcontractor's software management team.

q Available resources.

Changes to the software subcontractor's statement of work, subcontractterms and conditions, and other commitments are resolved according toa documented procedure. (L2-51, A6)


q All affected groups of both the prime contractor and thesubcontractor are involved.







Formal reviews to address the subcontractor's software engineeringaccomplishments and results are conducted at selected milestonesaccording to a documented procedure. (L2-53, A9)


q Reviews are preplanned and documented in the statement of work.

q Reviews address the subcontractor's commitments for, plans for,and status of the software activities.

q Significant issues, action items, and decisions are identified anddocumented.

q Software risks are addressed.

q The subcontractor's software development plan is refined, asappropriate.

The prime contractor's software quality assurance group monitorsthe subcontractor's software quality assurance activities according to adocumented procedure. (L2-53, A10)


q The subcontractor's plans, resources, procedures, and standards forsoftware quality assurance are periodically reviewed to ensure theyare adequate to monitor the subcontractor's performance.

q Regular reviews of the subcontractor are conducted to ensure theapproved procedures and standards are being followed.

q The prime contractor's software quality assurance groupspot checks the subcontractor's software engineering activitiesand products.

q The prime contractor's software quality assurance groupaudits the subcontractor's software quality assurance records, asappropriate.

q The subcontractor's records of its software quality assuranceactivities are periodically audited to assess how well the softwarequality assurance plans, standards, and procedures are beingfollowed.







The prime contractor's software configuration management groupmonitors the subcontractor's activities for software configurationmanagement according to a documented procedure. (L2-54, A11)


q The subcontractor's plans, resources, procedures, and standards forsoftware configuration management are reviewed to ensure they areadequate.

q The prime contractor and the subcontractor coordinate theiractivities on matters relating to software configuration managementto ensure that the subcontractor's products can be readily integratedor incorporated into the project environment of the primecontractor.

q The subcontractor's software baseline library is periodically auditedto assess how well the standards and procedures for softwareconfiguration management are being followed and how effectivethey are in managing the software baseline.

The prime contractor conducts acceptance testing as part of thedelivery of the subcontractor's software products according to adocumented procedure. (L2-55, A12)


q The acceptance procedures and acceptance criteria for eachproduct are defined, reviewed, and approved by both the primecontractor and the subcontractor prior to the test.

q The results of the acceptance tests are documented.

q An action plan is established for any software product that does notpass its acceptance test.


Software Qual i ty Assurance (SQA) Procedures


The table below lists the recommended documented procedures for the softwarequality assurance process.




q The SQA plan is developed in the early stages of, andin parallel with, the overall project planning.

q The SQA plan is reviewed by the affected groups andindividuals.

q The SQA plan is managed and controlled.



q Deviations from the software development plan and thedesignated project standards and procedures aredocumented and resolved with the appropriate softwaretask leaders, software managers, or projectmanager, where possible.

q Deviations from the software development plan and thedesignated project standards and procedures notresolvable with the software task leaders, softwaremanagers, or project manager are documented andpresented to the senior manager designated to receivenoncompliance items.

q Noncompliance items presented to the senior managerare periodically reviewed until they are resolved.

q The documentation of noncompliance items is managedand controlled.


Sof tware Conf igurat ion Management (SCM)Procedures


The table below lists the recommended documented procedures for the softwareconfiguration management process.




q The SCM plan is developed in the early stages of, andin parallel with, the overall project planning.

q The SCM plan is reviewed by the affected groups.

q The SCM plan is managed and controlled.




q Reviews and/or regression tests are performed to ensurethat changes have not caused unintended effects on thebaseline.

q Only configuration items/units that are approved by theSCCB are entered into the software baseline library.

q Configuration items/units are checked in and out in amanner that maintains the correctness and integrity ofthe software baseline library.

Products from the software baseline library are created andtheir release is controlled according to a documentedprocedure. (L2-80, A7)


q The SCCB authorizes the creation of products from thesoftware baseline library.

q Products from the software baseline library, for bothinternal and external use, are built only fromconfiguration items/units in the software baselinelibrary.



Sof tware Conf igurat ion Management (SCM)Procedures , Continued


The table below lists the recommended documented procedures for the softwareconfiguration management process, continued from the previous page.




q The configuration management actions are recorded insufficient detail so that the content and status of eachconfiguration item/unit are known and previous versionscan be recovered.

q The current status and history (i.e., changes and otheractions) of each configuration item/unit are maintained.

Software baseline audits are conducted according to adocumented procedure. (L2-81, A10).


q There is adequate preparation for the audit.

q The integrity of software baselines is assessed.

q The structure and facilities of the configurationmanagement library system are reviewed.

q The completeness and correctness of the softwarebaseline library contents are verified.

q Compliance with applicable SCM standards andprocedures is verified.

q The results of the audit are reported to the projectsoftware manager.

q Action items from the audit are tracked to closure.


Level 2 Summary

Overview

The purpose of this section is to provide checklists that provide a summary of therepeatable level (level 2). This section contains three perspectives of a CMM level.

Section purpose

• Key process area (KPA) specific information:KPA purposeKPA goals

• Operational framework information (from a maturity level viewpoint):PoliciesStandardsProcess descriptionsProceduresTrainingTools

• Other key process information (from a maturity level viewpoint):Reviews and auditsWork products managed and controlledMeasurements

This section contains the following topics.Sectionoverview

Topic Page

Level 2 - KPA Purposes L2-Summary-2

Level 2 - KPA Goals L2-Summary-3

Level 2 - Policies L2-Summary-5

Level 2 - Standards L2-Summary-6

Level 2 - Process Descriptions L2-Summary-7

Level 2 - Procedures L2-Summary-10

Level 2 - Training L2-Summary-13

Level 2 - Tools L2-Summary-14

Level 2 - Reviews and Audits L2-Summary-15

Level 2 - Work Products Managed and Controlled L2-Summary-20

Level 2 - Measurements L2-Summary-21

CMU/SEI-94-HB-1 L2-Summary-1

Level 2 - KPA Purposes

Level 2 KPApurposes

The following table describes the purpose of each key process area in the CMM atlevel 2.

KPA Purpose of KPAs at Level 2

RM The purpose of Requirements Management is to establish a commonunderstanding between the customer and the software project of thecustomer's requirements that will be addressed by the software project.(L2-1)

SPP The purpose of Software Project Planning is to establish reasonableplans for performing the software engineering and for managing thesoftware project. (L2-11)

SPTO The purpose of Software Project Tracking and Oversight is to provideadequate visibility into actual progress so that management can takeeffective actions when the software project's performance deviatessignificantly from the software plans. (L2-29)

SSM The purpose of Software Subcontract Management is to select qualifiedsoftware subcontractors and manage them effectively. (L2-43)

SQA The purpose of Software Quality Assurance is to provide managementwith appropriate visibility into the process being used by the softwareproject and of the products being built. (L2-59)

SCM The purpose of Software Configuration Management is to establish andmaintain the integrity of the products of the software projectthroughout the project's software life cycle. (L2-71)

L2-Summary-2 CMU/SEI-94-HB-1

Level 2 - KPA Goals

Level 2 KPAgoals

The following table lists the goals that are described in the CMM for each key processarea at level 2.

KPA CMM Goals at Level 2 References

RM System requirements allocated to software arecontrolled to establish a baseline for softwareengineering and management use. (L2-2, G1)

RM Software plans, products, and activities are keptconsistent with the system requirements allocated tosoftware. (L2-2, G2)

SPP Software estimates are documented for use in planningand tracking the software project. (L2-12, G1)

SPP Software project activities and commitments areplanned and documented. (L2-12, G2)

SPP Affected groups and individuals agree to theircommitments related to the software project. (L2-12,G3)

SPTO Actual results and performances are tracked against thesoftware plans. (L2-30, G1)

SPTO Corrective actions are taken and managed to closurewhen actual results and performance deviatesignificantly from the software plans. (L2-30, G2)

SPTO Changes to software commitments are agreed to by theaffected groups and individuals. (L2-30, G3)

SSM The prime contractor selects qualified softwaresubcontractors. (L2-44, G1)

SSM The prime contractor and the softwaresubcontractor agree to their commitments to eachother. (L2-44, G2)

SSM The prime contractor and the softwaresubcontractor maintain ongoing communications.(L2-44, G3)

SSM The prime contractor tracks the softwaresubcontractor's actual results and performance againstits commitments. (L2-44, G4)



Level 2 - KPA Goals, Continued

Level 2 KPAgoals, continued

The following table lists the goals that are described in the CMM for each key processarea at level 2, continued from the previous page.


SQA Software quality assurance activities are planned. (L2-60, G1)

SQA Adherence of software products and activities toapplicable standards, procedures, and requirements isverified objectively. (L2-60, G2)

SQA Affected groups and individuals are informed ofsoftware quality assurance activities and results. (L2-60, G3)

SQA Noncompliance issues that cannot be resolved withinthe software project are addressed by seniormanagement. (L2-60, G4)

SCM Software configuration management activities areplanned. (L2-72, G1)

SCM Selected software work products are identified,controlled, and available. (L2-72, G2)

SCM Changes to identified software work products arecontrolled. (L2-72, G3)

SCM Affected groups and individuals are informed of thestatus and content of software baselines. (L2-72, G4)


Level 2 - Policies

Level 2 policies The following table lists the recommended policies in the CMM at level 2.

KPA Description References

RM Written organizational policy for managing the systemrequirements allocated to software. (L2-2, C1)

SPP Written organizational policy for planing a softwareproject. (L2-12, C2)

SPTO Written organizational policy for managing thesoftware project. (L2-30, C2)

SSM Written organizational policy for managing thesoftware subcontract. (L2-44, C1)

SQA Written organizational policy for implementingsoftware quality assurance (SQA). (L2-60, C1)

SCM Written organizational policy for implementingsoftware configuration management (SCM). (L2-72,C1)


Level 2 - Standards

Level 2standards

The CMM recommends the contents of the following work products at level 2:

KPA Standards at Level 2 References

RM Allocated requirements. (L2-4, Ab2, 1-3)

SPP Statement of work. (L2-14, Ab1, 1)

SPP Software development plan. (L2-19, A7, 1-10)

SSM Contractual agreement. (L2-50, A3, 1-8)

SQA Software quality assurance plan. (L2-64, A2, 1-10)

SCM Software configuration management plan. (L2-77, A2,1-2)

Refer to the Level 2 Standards Checklists for additional information regarding thecontent of each standard.

Reference


Level 2 - Process Descriptions

RM processdescription

Requirements Management involves establishing and maintaining an agreement withthe customer on the requirements for the software project. This agreement is referredto as the "system requirements allocated to the software." The "customer" may beinterpreted as the system engineering group, the marketing group, another internalorganization, or an external customer. The agreement covers both the technical andnontechnical (e.g., delivery dates) requirements. The agreement forms the basis forestimating, planning, performing, and tracking the software project's activitiesthroughout the software life cycle.

The allocation of the system requirements to software, hardware, and other systemcomponents (e.g., humans) may be performed by a group external to the softwareengineering group (e.g., the system engineering group), and the software engineeringgroup may have no direct control of this allocation. Within the constraints of theproject, the software engineering group takes appropriate steps to ensure that thesystem requirements allocated to software, which they are responsible for addressing,are documented and controlled.

To achieve this control, the software engineering group reviews the initial and revisedsystem requirements allocated to software to resolve issues before they areincorporated into the software project. Whenever the system requirements allocated tosoftware are changed, the affected software plans, work products, and activities areadjusted to remain consistent with the updated requirements. (L2-1)

SPP processdescription

Software Project Planning involves developing estimates for the work to beperformed, establishing the necessary commitments, and defining the plan to performthe work.

The software planning begins with a statement of the work to be performed and otherconstraints and goals that define and bound the software project (those established bythe practices of the Requirements Management key process area). The softwareplanning process includes steps to estimate the size of the software work products andthe resources needed, produce a schedule, identify and assess software risks, andnegotiate commitments. Iterating through these steps may be necessary to establishthe plan for the software project (i.e., the software development plan).

This plan provides the basis for performing and managing the software project'sactivities and addresses the commitments to the software project's customer accordingto the resources, constraints, and capabilities of the software project. (L2-11)



Level 2 - Process Descriptions, Continued

SPTO processdescription

Software Project Tracking and Oversight involves tracking and reviewing the softwareaccomplishments and results against documented estimates, commitments, and plans,and adjusting these plans based on the actual accomplishments and results.

A documented plan for the software project (i.e., the software development plan, asdescribed in the Software Project Planning key process area) is used as the basis fortracking the software activities, communicating status, and revising plans. Softwareactivities are monitored by the management. Progress is primarily determined bycomparing the actual software size, effort, cost, and schedule to the plan when selectedsoftware work products are completed and at selected milestones. When it isdetermined that the software project's plans are not being met, corrective actions aretaken. These actions may include revising the software development plan to reflectthe actual accomplishments and replanning the remaining work or taking actions toimprove the performance. (L2-29)

SSM processdescription

Software Subcontract Management involves selecting a software subcontractor,establishing commitments with the subcontractor, and tracking and reviewing thesubcontractor's performance and results. These practices cover the management of asoftware (only) subcontract, as well as the management of the software component ofa subcontract that includes software, hardware, and possibly other system components.

The subcontractor is selected based on its ability to perform the work. Many factorscontribute to the decision to subcontract a portion of the prime contractor's work.Subcontractors may be selected based on strategic business alliances, as well astechnical considerations. The practices of this key process area address the traditionalacquisition process associated with subcontracting a defined portion of the work toanother organization.

When subcontracting, a documented agreement covering the technical andnontechnical (e.g., delivery dates) requirements is established and is used as the basisfor managing the subcontract. The work to be done by the subcontractor and the plansfor the work are documented. The standards that are to be followed by thesubcontractor are compatible with the prime contractor's standards.

The software planning, tracking, and oversight activities for the subcontracted workare performed by the subcontractor. The prime contractor ensures that these planning,tracking, and oversight activities are performed appropriately and that the softwareproducts delivered by the subcontractor satisfy their acceptance criteria. The primecontractor works with the subcontractor to manage their product and processinterfaces. (L2-43)




SQA processdescription

Software Quality Assurance involves reviewing and auditing the software productsand activities to verify that they comply with the applicable procedures and standardsand providing the software project and other appropriate managers with the results ofthese reviews and audits.

The software quality assurance group works with the software project during its earlystages to establish plans, standards, and procedures that will add value to the softwareproject and satisfy the constraints of the project and the organization's policies. Byparticipating in establishing the plans, standards, and procedures, the software qualityassurance group helps ensure they fit the project's needs and verifies that they will beusable for performing reviews and audits throughout the software life cycle. Thesoftware quality assurance group reviews project activities and audits software workproducts throughout the life cycle and provides management with visibility as towhether the software project is adhering to its established plans, standards, andprocedures.

Compliance issues are first addressed within the software project and resolved there ifpossible. For issues not resolvable within the software project, the software qualityassurance group escalates the issue to an appropriate level of management forresolution.

This key process area covers the practices for the group performing the softwarequality assurance function. The practices identifying the specific activities and workproducts that the software quality assurance group reviews and/or audits are generallycontained in the Verifying Implementation common feature of the other key processareas. (L2-59)

SCM processdescription

Software Configuration Management involves identifying the configuration of thesoftware (i.e., selected software work products and their descriptions) at given pointsin time, systematically controlling changes to the configuration, and maintaining theintegrity and traceability of the configuration throughout the software life cycle. Thework products placed under software configuration management include the softwareproducts that are delivered to the customer (e.g., the software requirements documentand the code) and the items that are identified with or required to create these softwareproducts (e.g., the compiler).

A software baseline library is established containing the software baselines as they aredeveloped. Changes to baselines and the release of software products built from thesoftware baseline library are systematically controlled via the change control andconfiguration auditing functions of software configuration management.

This key process area covers the practices for performing the software configurationmanagement function. The practices identifying specific configuration items/units arecontained in the key process areas that describe the development and maintenance ofeach configuration item/unit. (L2-71)


Level 2 - Procedures

Level 2procedures

The table below lists the activities that are recommended to be performed according toa documented procedure in the CMM at level 2. Refer to the Level 2 ProcedureChecklists for additional information regarding the content of each documentedprocedure.

KPA Documented Procedures References

RM There are no required procedures for the RM process.

SPP Software project commitments made to individuals andgroups external to the organization are reviewed withsenior management according to a documentedprocedure. (L2-17, A4)

SPP The project's software development plan is developedaccording to a documented procedure. (L2-18, A6)

SPP Estimates for the size of the software work products(or changes to the size of software work products) arederived according to a documented procedure. (L2-21,A9)

SPP Estimates for the software project's effort and costs arederived according to a documented procedure. (L2-22,A10)

SPP Estimates for the project's critical computer resourcesare derived according to a documented procedure.(L2-23, A11)

SPP The project's software schedule is derived according toa documented procedure. (L2-23, A12)

SPTO The project's software development plan is revisedaccording to a documented procedure. (L2-33, A2)

SPTO Software project commitments and changes tocommitments made to individuals and groups externalto the organization are reviewed with seniormanagement according to a documented procedure.(L2-35, A3)

SPTO Formal reviews to address the accomplishments andresults of the software project are conducted at selectedproject milestones according to a documentedprocedure. (L2-39, A13)



Level 2 - Procedures, Continued

Level 2procedures,continued

The table below lists the activities that are recommended to be performed according toa documented procedure in the CMM at level 2, continued from the previous page.


SSM The work to be subcontracted is defined and plannedaccording to a documented procedure. (L2-47, A1)

SSM The software subcontractor is selected based on anevaluation of the subcontract bidders' ability toperform the work, according to a documentedprocedure. (L2-49, A2)

SSM Changes to the software subcontractor's statement ofwork, subcontract terms and conditions, and othercommitments are resolved according to a documentedprocedure. (L2-51, A6)

SSM Formal reviews to address the subcontractor's softwareengineering accomplishments and results areconducted at selected milestones according to adocumented procedure. (L2-53, A9)

SSM The prime contractor's software quality assurancegroup monitors the subcontractor's software qualityassurance activities according to a documentedprocedure. (L2-53, A10)

SSM The prime contractor's software configurationmanagement group monitors the subcontractor'sactivities for software configuration managementaccording to a documented procedure. (L2-54, A11)

SSM The prime contractor conducts acceptance testing aspart of the delivery of the subcontractor's softwareproducts according to a documented procedure. (L2-55, A12)

SQA A SQA plan is prepared for the software projectaccording to a documented procedure. (L2-63, A1)







SQA Deviations identified in the software activities andsoftware work products are documented and handledaccording to a documented procedure. (L2-67, A7)

SCM A SCM plan is prepared for each software projectaccording to a documented procedure. (L2-76, A1)

SCM Change requests and problem reports for allconfiguration items/units are initiated, recorded,reviewed, approved, and tracked according to adocumented procedure. (L2-79, A5)

SCM Changes to baselines are controlled according to adocumented procedure. (L2-80, A6)

SCM Products from the software baseline library are createdand their release is controlled according to adocumented procedure. (L2-80, A7)

SCM The status of configuration items/units is recordedaccording to a documented procedure (L2-80, A8)

SCM Software baseline audits are conducted according to adocumented procedure. (L2-81, A10).


Level 2 - Training

Level 2 training The table below lists the training recommended in the CMM at level 2.

KPA Training References

RM Members of the software engineering group andother software-related groups are trained to performtheir requirements management activities. (L2-5, Ab4)

SPP The software managers, software engineers, andother individuals involved in the software projectplanning are trained in the software estimating andplanning procedures applicable to their areas ofresponsibility. (L2-16, Ab4)

SPTO The software managers are trained in managing thetechnical and personnel aspects of the software project.(L2-32, Ab4)

SPTO First-line software managers receive orientation inthe technical aspects of the software project. (L2-32,Ab5)

SSM Software managers and other individuals who areinvolved in establishing and managing the softwaresubcontract are trained to perform these activities.(L2-46, Ab2)

SSM Software managers and other individuals who areinvolved in managing the software subcontract receiveorientation in the technical aspects of the subcontract.(L2-46, Ab3)

SQA Members of the SQA group are trained to performtheir SQA activities. (L2-62, Ab3)

SQA The members of the software project receiveorientation on the role, responsibilities, authority, andvalue of the SQA group. (L2-63, Ab4)

SCM Members of the SCM group are trained in theobjectives, procedures, and methods for performingtheir SCM activities. (L2-76, Ab4)

SCM Members of the software engineering group andother software-related groups are trained to performtheir SCM activities. (L2-76, Ab5)


Level 2 - Tools

Level 2 tools The table below lists the tools recommended in the CMM for level 2.

KPA Tools References

RM Tools to support the activities for managingrequirements. (L2-5, Ab3, 2)

SPP Tools to support software project planning activities.(L2-16, Ab3, 2)

SPTO Tools to support software tracking. (L2-32, Ab3, 2)

SSM Tools to support managing the subcontract. (L2-46,Ab1, 2)

SQA Tools to support the SQA activities. (L2-62, Ab2, 3)

SCM Tools to support the SCM activities. (L2-75, Ab3, 2)

SCM A configuration management library system isestablished as a repository for the software baselines.(L2-77, A3)

This library system:

q Supports multiple control levels of SCM.

q Provides for the storage and retrieval ofconfiguration items/units.

q Provides for the sharing and transfer ofconfiguration items/units between the affectedgroups and between control levels within thelibrary.

q Helps in the use of product standards forconfiguration items/units.

q Provides for the storage and recovery of archiveversions of configuration items/units.

q Helps to ensure correct creation of products fromthe software baseline library.

q Provides for the storage, update, and retrieval ofSCM records.

q Supports production of SCM reports.

q Provides for the maintenance of the librarystructure and contents.


Level 2 - Reviews and Audits

Level 2 reviewsand audits

The table below lists the recommended reviews and audits in the CMM at level 2.

KPA Review or Audit ReviewParticipants

References

RM The software engineering groupreviews allocated requirements beforethey are incorporated into the softwareproject. (L2-5, A1)


RM Changes to the allocated requirementsare reviewed and incorporated into thesoftware project. (L2-7, A3)

Not specifiedin CMM

RM The activities for managing theallocated requirements are reviewedwith senior management on aperiodic basis. (L2-9, V1)

Seniormanagement

RM The activities for managing theallocated requirements are reviewedwith the project manager on both aperiodic and event-driven basis. (L2-9, V2)

Projectmanager

RM The software quality assurancegroup reviews and/or audits theactivities and work products formanaging the allocated requirementsand reports the results. (L2-9, V3)

SQA group

SPP Software project commitments madeto individuals and groups external tothe organization are reviewed withsenior management. (L2-17, A4)

Seniormanagement

SPP The activities for software projectplanning are reviewed with seniormanagement on a periodic basis. (L2-26, V1)

Seniormanagement

SPP The activities for software projectplanning are reviewed with theproject manager on both a periodicand event-driven basis. (L2-26, V2)

Projectmanager



Level 2 - Reviews and Audits, Continued

Level 2 reviewsand audits,continued

The table below lists the recommended reviews and audits in the CMM at level 2,continued from the previous page.


References

SPP The software quality assurancegroup reviews and/or audits theactivities and work products forsoftware project planning and reportsthe results (L2-27, V3)

SQA group

SPTO Software project commitments andchanges to commitments made toindividuals and groups external tothe organization are reviewed withsenior management according to adocumented procedure. (L2-35, A3)

Seniormanagement

SPTO The software engineering groupconducts periodic internal reviews totrack technical progress, plans,performance, and issues against thesoftware development plan. (L2-38,A12)







Softwaremanagers

Softwaretask leaders

SPTO Formal reviews to address theaccomplishments and results of thesoftware project are conducted atselected project milestones accordingto a documented procedure. (L2-39,A13)

q These reviews are conducted withthe customer, end user, andaffected groups within theorganization, as appropriate. (L2-39, A13, 2)

Affectedgroups

Customer

End user

Softwaremanagers

SPTO The activities for software projecttracking and oversight are reviewedwith senior management on aperiodic basis. (L2-40, V1)

Seniormanagement






References

SPTO The activities for software projecttracking and oversight are reviewedwith the project manager on both aperiodic and event-driven basis. (L2-41, V2)

Projectmanager

SPTO The software quality assurancegroup reviews and/or audits theactivities and work products forsoftware project tracking and oversightand reports the results. (L2-41, V3)

SQA group

SSM A documented subcontractor'ssoftware development plan is reviewedand approved by the primecontractor. (L2-51, A4)

Primecontractor

SSM The prime contractor's managementconducts periodic status/coordinationreviews with the softwaresubcontractor's management. (L2-51, A7)


Sub-contractor'smanagement

SSM Periodic technical reviews andinterchanges are held with thesoftware subcontractor. (L2-52, A8)

Softwaresubcontrac-tor

SSM Formal reviews to address thesubcontractor's software engineeringaccomplishments and results areconducted at selected milestonesaccording to a documented procedure.(L2-53, A9)


SSM The software subcontractor'sperformance is evaluated on a periodicbasis, and the evaluation is reviewedwith the subcontractor. (L2-55, A13)

Subcontrac-tor







References

SSM The activities for managing thesoftware subcontract are reviewedwith senior management on aperiodic basis. (L2-56, V1)

Seniormanagement

SSM The activities for managing thesoftware subcontract are reviewedwith the project manager on both aperiodic and event-driven basis. (L2-56, V2)

Projectmanager

SSM The software quality assurancegroup reviews and/or audits theactivities and work products formanaging the software subcontract andreports the results. (L2-57, V3)

SQA group

SQA The SQA group participates in thepreparation and review of the project'ssoftware development plan, standards,and procedures. (L2-65, A3)

SQA group

SQA The SQA group reviews the softwareengineering activities to verifycompliance. (L2-66, A4)

SQA group

SQA The SQA group audits designatedsoftware work products to verifycompliance. (L2-66, A5)

SQA group

SQA The SQA group conducts periodicreviews of its activities and findingswith the customer's SQA personnel,as appropriate. (L2-67, A8)

SQA group

Customer'sSQApersonnel

SQA The SQA activities are reviewed withsenior management on a periodicbasis. (L2-68, V1)

Seniormanagement







References

SQA The SQA activities are reviewed withthe project manager on both aperiodic and event-driven basis. (L2-69, V2)

Projectmanager

SQA Experts independent of the SQAgroup periodically review theactivities and software work productsof the project's SQA group. (L2-69,V3)


SCM Change requests and problem reportsfor all configuration items/units areinitiated, recorded, reviewed,approved, and tracked according to adocumented procedure. (L2-79, A5)

Not specifiedin CMM

SCM Software baseline audits are conductedaccording to a documented procedure.(L2-81, A10)

Not specifiedin CMM

SCM The SCM activities are reviewed withsenior management on a periodicbasis. (L2-82, V1)

Seniormanagement

SCM The SCM activities are reviewed withthe project manager on both aperiodic and event-driven basis. (L2-83, V2)

Projectmanager

SCM The SCM group periodically auditssoftware baselines to verify that theyconform to the documentation thatdefines them. (L2-83, V3)

SCM group

SCM The software quality assurancegroup reviews and/or audits theactivities and work products for SCMand reports the results. (L2-83, V4)

SQA group


Level 2 - Work Products Managed and Controlled

Level 2 workproductsmanaged andcontrolled

The table below lists the work products that are recommended to be managed andcontrolled in the CMM at level 2.

KPA Work Products Managed and Controlled References

RM Allocated requirements. (L2-7, A2, 1)

SPP Project's software development plan. (L2-13, C2, 6)

SPP Statement of work. (L2-15, Ab1, 3)

SPP Software planning data. (L2-25, A15, 2)

SPTO Software development plan (SDP). (L2-34, A2, 4)

(Same as project’s SDP above in SPP)

SPTO Software replanning data. (L2-38, A11, 2)

SSM Subcontract statement of work. (L2-48, A1, 3.5)

SQA SQA plan. (L2-64, A1, 3)

SQA Documentation of noncompliance items. (L2-67, A7,4)

SCM SCM plan. (L2-77, A1, 3)


Level 2 - Measurements

Level 2measurements

The table below describes the recommended measurements in the CMM at level 2.


RM Measurements to determine the status of the activitiesfor managing the allocated requirements. (L2-8, M1)

SPP Software planning data. (L2-25, A15)

q Information recorded includes the estimates andthe associated information needed to reconstructthe estimates and assess their reasonableness. (L2-25, A15, 1)

SPP Measurements to determine the status of the softwareplanning activities. (L2-25, M1)

SPTO Actual measurement data and replanning data for thesoftware project. (L2-38, A11)

SPTO Measurements to determine the status of the softwaretracking and oversight activities. (L2-39, M1)

SSM Measurements to determine the status of the activitiesfor managing the software subcontract. (L2-55, M1)

SQA Measurements to determine the cost and schedulestatus of the SQA activities. (L2-68, M1)

SCM Measurements to determine the status of the SCMactivities. (L2-82, M1)


Chapter 5. Defined Level (Level 3)

Overview

This chapter contains the checklists for level 3 of the CMM.Introduction


Section Title Page








O v e r v i e w












Policies See Page

Organization process focus policy L3-Policy-2

Organization process definition policy L3-Policy-3

Training program policy L3-Policy-4

Integrated software management policy L3-Policy-5

Software product engineering policy L3-Policy-6

Intergroup coordination policy L3-Policy-7

Peer reviews policy L3-Policy-8


Organizat ion Process Focus (OPF) Pol icy

OPF policychecklist

The organization follows a written organizational policy for coordinating softwareprocess development and improvement activities across the organization (L3-2,C1). This policy typically specifies that:


A group is established that is responsible for theorganization-level software process activities andcoordinating these activities with the projects. (L3-2, C1,1)

The software processes used by the projects are assessedperiodically to determine their strengths and weaknesses.(L3-2, C1, 2)

The software processes used by the projects areappropriately tailored from the organization’s standardsoftware process. (L3-2, C1, 3)

Improvements to, and other useful information on, eachproject’s software process, tools, and methods are availableto other projects. (L3-2, C1, 4)

Implementation of an effective organizational process focus policy has thefollowing results:

OPF policygoals

Results of Effectively Implementing OPF Policy References

Software process development and improvement activitiesare coordinated across the organization. (L3-1, G1)

The strengths and weaknesses of the software processesused are identified relative to the process standard. (L3-2,G2)

Organization-level process development and improvementactivities are planned. (L3-2, G3)


Organizat ion Process Def in i t ion (OPD) Pol icy

OPD policychecklist

The organization follows a written policy for developing and maintaining astandard software process and related process assets (L3-12, C1). This policytypically specifies that:


A standard software process is defined for the organization.(L3-12, C1, 1)

A project’s defined software process is a tailored version ofthe organization’s standard software process. (L3-13, C1, 2)

The organization’s software process assets are maintained.(L3-13, C1, 3)

Information collected from the projects is organized andused to improve the organization’s standard softwareprocess. (L3-13, C1, 4)

Implementation of an effective organizational process definition policy has thefollowing results:

OPD policygoals

Results of Effectively Implementing OPD Policy References

A standard software process for the organization isdeveloped and maintained. (L3-12, G1)

Information related to the use of the organization’s standardsoftware process by the software projects is collected,reviewed, and made available. (L3-12, G2)


Tra in ing Program (TP) Po l icy

TP policychecklist

The organization follows a written policy for meeting its training needs (L3-26,C1). This policy typically specifies that:


The needed skills and knowledge for each softwaremanagement and technical role are identified. (L3-26, C1,1)

Training vehicles for imparting skills and knowledge areidentified and approved. (L3-26, C1, 2)

Training is provided to build the skill base of theorganization, to fill the specific needs of the projects, and todevelop the skills of individuals. (L3-26, C1, 3)

Training is developed within the organization or obtainedfrom outside the organization when appropriate. (L3-26, C1,4)

Implementation of an effective training program policy has the following results:TP policy goals

Results of Effectively Implementing TP Policy References

Training activities are planned. (L3-25, G1)

Training for developing the skills and knowledge needed toperform software management and technical roles isprovided. (L3-25, G2)

Individuals in the software engineering group andsoftware-related groups receive the training necessary toperform their roles. (L3-26, G3)


In tegra ted Sof tware Management ( ISM) Pol icy

ISM policychecklist

The project follows a written organizational policy requiring that the softwareproject be planned and managed using the organization's standard softwareprocess and related process assets (L3-38, C1). This policy typically specifiesthat:


Each project documents the project's defined softwareprocess by tailoring the organization's standard softwareprocess. (L3-39, C1, 1)

The project's deviations from the organization's standardsoftware process are documented and approved. (L3-39, C1,2)

Each project performs its software activities in accordancewith the project's defined software process. (L3-39, C1, 3)

Each project collects and stores appropriate projectmeasurement data in the organization's software processdatabase. (L3-39, C1, 4)

Implementation of an effective integrated software management policy has thefollowing results:

ISM policygoals

Results of Effectively Implementing ISM Policy References

The project's defined software process is a tailored versionof the organization's standard software process. (L3-38, G1)

The project is planned and managed according to theproject's defined software process. (L3-38, G2)


Sof tware Product Engineer ing (SPE) Po l icy

SPE policychecklist

The project follows a written organizational policy for performing the softwareengineering activities (L3-60, C1). This policy typically specifies that:


The software engineering tasks are performed in accordancewith the project's defined software process. (L3-60, C1, 1)

Appropriate methods and tools are used to build andmaintain the software products. (L3-60, C1, 2)

The software plans, tasks, and products are traceable to thesystem requirements allocated to software. (L3-60, C1, 3)

SPE policygoals

Implementation of an effective software product engineering policy has thefollowing results:

Results of Effectively Implementing SPE Policy References

The software engineering tasks are defined, integrated, andconsistently performed to produce the software. (L3-60, G1)

Software work products are kept consistent with each other.(L3-60, G2)


In tergroup Coordinat ion ( IC) Pol icy

IC policychecklist

The project follows a written organizational policy for establishinginterdisciplinary engineering teams (L3-84, C1). This policy typically specifiesthat:


The system requirements and project-level objectives for theproject are defined and reviewed by all affected groups.(L3-84, C1, 1)

The engineering groups coordinate their plans andobjectives. (L3-84, C1, 2)

Managers are responsible for establishing and maintainingan environment to facilitate interaction, coordination,support, and teamwork between the project's engineeringgroups, between the project and the customer or end users,as appropriate, and throughout the organization. (L3-85, C1,3)

IC policy goals Implementation of an effective intergroup coordination policy has the followingresults:

Results of Effectively Implementing IGC Policy References

The customer's requirements are agreed to by all affectedgroups. (L3-84, G1)

The commitments between the engineering groups areagreed to by the affected groups. (L3-84, G2)

The engineering groups identify, track, and resolveintergroup issues. (L3-84, G3)


P e e r R e v i e w s ( P R ) P o l i c y

The project follows a written organizational policy for performing peer reviews(L3-94, C1). This policy typically specifies that:

PR policychecklist


The organization identifies a standard set of software workproducts that will undergo peer review. (L3-94, C1, 1)

Each project identifies the software work products that willundergo peer review. (L3-94, C1, 2)

Peer reviews are led by trained peer review leaders. (L3-94, C1, 3)

Peer reviews focus on the software work product beingreviewed and not on the producer. (L3-94, C1, 4)

Results of the peer reviews are not used by management toevaluate the performance of individuals. (L3-94, C1, 5)

Implementation of an effective Peer Reviews policy has the following results:PR policy goals

Results of Effectively Implementing PR Policy References

Peer reviews are planned. (L3-93, G1)

Defects in the software work products are identified andremoved. (L3-93, G2)



O v e r v i e w



Definition









O v e r v i e w , continued



Action plan OPF L3-Standards-3

Software development and improvement plan OPF L3-Standards-4

Organization’s standard software process OPD L3-Standards-5

Software process element OPD L3-Standards-6

Tailoring guidelines and criteria OPD L3-Standards-7

Software project’s training plan TP L3-Standards-8

Organization’s training plan TP L3-Standards-9

Organizational standards for training courses TP L3-Standards-10

Project’s defined software process ISM L3-Standards-11

Software design documentation SPE L3-Standards-12

Test plan SPE L3-Standards-13

Plan for intergroup commitments IC L3-Standards-14

Plans for peer reviews PR L3-Standards-15


Action Plan

The following table contains what the CMM describes as the recommendedcontent of an action plan:

Standardchecklist

Recommended Content

Which assessment findings will be addressed. (L3-6, A1)

Guidelines for implementing the changes to address findings. (L3-6, A1)

The groups or individuals responsible for implementing the changes. (L3-6,A1)


Software Process Development and ImprovementP lan

The following table contains what the CMM describes as the recommendedcontent of the plan for software process development and improvement. This plan:

Standardchecklist

Recommended Content

Uses the action plans from the software process assessments and otherorganization improvement initiatives as primary inputs. (L3-7, A2, 1)

Defines the activities to be performed and the schedule for these activities.(L3-7, A2, 2)

Specifies the groups and individuals responsible for the (software processdevelopment and improvement) activities. (L3-7, A2, 3)

Identifies the resources required, including staff and tools. (L3-7, A2, 4)


Organizat ion’s Standard Software Process

The following table contains what the CMM describes as the recommendedcontent of an organization's standard software process:

Standardchecklist

Recommended Content

The process is decomposed into constituent process elements to thegranularity needed to understand and describe the process. (L3-17, A2, 1)

Each process element is described. (L3-17, A2, 2)

[Refer to Level 3 Standards for additional information regarding softwareprocess elements.]

The relationships of the process elements are described and address (L3-18, A2, 3):

q the ordering,

q the interfaces, and

q the interdependencies.


Software Process Element

The following table contains what the CMM describes as the recommendedcontent of a software process element:

Standardchecklist

Recommended Content

The required procedures, practices, methods, and technologies. (L3-17, A2,2.1)

The applicable process and product standards. (L3-17, A2, 2.2)

The responsibilities for implementing the process. (L3-18, A2, 2.3)

The required tools and resources. (L3-18, A2, 2.4)

Inputs. (L3-18, A2, 2.5)

The software work products produced. (L3-18, A2, 2.6)

The software work products that should undergo peer review. (L3-18, A2,2.7)

The readiness and completion criteria. (L3-18, A2, 2.8)

The product and process data to be collected. (L3-18, A2, 2.9)


Tai lor ing Guidel ines and Cr i ter ia

The following table contains what the CMM describes as the recommendedcontent of tailoring guidelines and criteria (for tailoring the organization's standardsoftware process). These guidelines and criteria cover:

Standardchecklist

Recommended Content

Selecting and tailoring the software life cycle for the project. (L3-19, A4,1.1)

Tailoring the organization's standard software process to accommodate thesoftware life cycle and the project's characteristics. (L3-19, A4, 1.2)

Standards for documenting the project's defined software process. (L3-20,A4, 1.3)


Software Pro ject ’s Tra in ing Plan

The following table contains what the CMM describes as the recommendedcontent of a software project’s training plan:

Standardchecklist

Recommended Content

The set of skills needed and when those skills are needed. (L3-29, A1, 1)

The skills for which training is required and the skills that will be obtainedvia other vehicles. (L3-29, A1, 2)

The training that is required, for whom it is required, and when it isrequired. (L3-29, A1, 3)

How training will be provided. (L3-30, A1, 4)


Organizat ion's Training Plan

The following table contains what the CMM describes as the recommendedcontent of the organization's training plan:

Standardchecklist

Recommended Content

The specific training needed within the organization and when it is needed.(L3-32, A3, 1)

The training that will be obtained from external sources and training thatwill be provided by the training group. (L3-32, A3, 2)

The funding and resources (including staff, tools, and facilities) needed toprepare and conduct or procure the training. (L3-32, A3, 3)

Standards for instructional materials used in training courses developed bythe training group. (L3-32, A3, 4)

The schedule for developing and revising the training courses that will bedeveloped by the training group. (L3-32, A3, 5)

The schedule for conducting the training, based on the projected need datesand the projected number of students. (L3-32, A3, 6)

The procedures for: (L3-33, A3, 7)

q selecting the individuals who will receive the training,

q registering and participating in the training,

q maintaining records of the training provided, and

q collecting, reviewing, and using training evaluations and other trainingfeedback.


Organizat ional Standards for Training Courses

The following table contains what the CMM describes as the recommendedcontent of organizational standards for training courses. These standards requiresthat:

Standardchecklist

Recommended Content

A description of each training course is developed. (L3-33, A4, 1)

The materials for the training course are reviewed. (L3-33, A4, 2)

The materials for the training courses are managed and controlled. (L3-33,A4, 3)


Project 's Def ined Sof tware Process

The following table contains what the CMM describes as the recommendedcontent of the project's defined software process:

Standardchecklist

Recommended Content

Provisions are made for gathering, analyzing, and reporting measurementdata needed to manage the software project. (L3-44, A4, 1)

The activities for software estimating, planning, and tracking are tied to thekey tasks and work products of the project's defined software process. (L3-44, A4, 2)

Readiness and completion criteria are established, documented, and usedto authorize initiation and determine completion of key tasks. (L3-44, A4,3)

Documented criteria are defined to indicate when to replan the softwareproject. (L3-45, A4, 4)

Technical and management lessons learned are documented and stored inthe organization's library of software process-related documentation. (L3-45, A4, 5)

Technical and management lessons learned from monitoring the activitiesof other projects in the organization are systematically reviewed and usedto estimate, plan, track, and replan the software project. (L3-45, A4, 6)

The staffing plan addresses the software project's needs for individuals withspecial skills and application domain knowledge. (L3-45, A4, 7)

Training needs are identified and documented to fit the specific needs ofthe software project. (L3-45, A4, 8)

The software plans and processes followed in interacting with other groupsare adjusted to account for disparities with these groups and for otherpotential problems. (L3-45, A4, 9)


Software Design Documentat ion

The following table contains what the CMM describes as the recommendedcontent of software design documentation:

Standardchecklist

Recommended Content

The software components. (L3-71, A3, 8.1)

The internal interfaces between software components. (L3-71, A3, 8.1)

The software interfaces to other software systems, to hardware, and toother system components (e.g., humans). (L3-71, A3, 8.1)


Test P lan

The following table contains what the CMM describes as the recommendedcontent of the test plan (for system and acceptance testing):

Standardchecklist

Recommended Content

The overall testing and verification approach. (L3-75, A7, 2.1)

Responsibilities of the developing organization, subcontractors, customer,and end users, as appropriate. (L3-76, A7, 2.2)

Test facility, test equipment, and test support requirements. (L3-76, A7,2.3)

Acceptance criteria. (L3-76, A7, 2.4)


Plan for Intergroup Commitments

The following table contains what the CMM describes as the recommendedcontent of a plan for intergroup commitments. This plan is:

Standardchecklist

Recommended Content

The baseline for: (L3-88, A3, 1)

q the project schedule,

q the contractual and technical aspects of the project, and

q the assignment of responsibilities to the engineering groups.

Updated to incorporate all intergroup commitments and changes to thesecommitments. (L3-88, A3, 4)

Updated as the work progresses to reflect progress and plan changes at theproject level, particularly when major project milestones are completed andwhen plans change significantly. (L3-88, A3, 5)


Plans for Peer Rev iews

The following table contains what the CMM describes as the recommendedcontent of plans for peer reviews. These plans:

Standardchecklist

Recommended Content

Identify the software work products that will undergo peer review. (L3-97,A1, 1)

q The software work products selected include the set identified in theorganization's standard software process. (L3-97, A1, 1.1)

Specify the schedule of peer reviews. (L3-97, A1, 2)



O v e r v i e w







Organization Process Focus L3-Process-3

Organization Process Definition L3-Process-25

Training Program L3-Process-49

Integrated Software Management L3-Process-67

Software Product Engineering L3-Process-103

Intergroup Coordination L3-Process-149

Peer Reviews L3-Process-179


Organizat ion Process Focus (OPF) Process

OPF Process - Overv iew

The purpose of Organization Process Focus is to establish the organizationalresponsibility for software process activities that improve the organization'soverall software process capability. (L3-1)

OPF processpurpose

Organization Process Focus involves developing and maintaining anunderstanding of the organization's and projects' software processes andcoordinating the activities to assess, develop, maintain, and improve theseprocesses.

The organization provides the long-term commitments and resources to coordinatethe development and maintenance of the software processes across current andfuture software projects via a group such as a software engineering process group.This group is responsible for the organization's software process activities. It isspecifically responsible for the development and maintenance of theorganization's standard software process and related process assets (as describedin the Organization Process Definition key process area), and it coordinates theprocess activities with the software projects. (L3-1)

OPF processdescription



OPF Process - Overv iew , Continued

Sectionoverview




L3-Process-5



L3-Process-10


L3-Process-11


L3-Process-13


L3-Process-15

Reviews andAudits




L3-Process-20




L3-Process-22




OPF Process - Ro les

Roles The table below lists the roles and the activities in which they participate in theorganization process focus process.


Affectedgroups

A summary report from each (seniormanagement review of the activities forsoftware process development andimprovement) is prepared and distributedto the affected groups and individuals.(L3-10, V1, 4)

Groupresponsiblefor theorganization’ssoftwareprocessactivities

q Where possible, (the groupresponsible for the organization’ssoftware process activities) is staffedby a core of software technicalprofessionals who are assigned fulltime to the group, possibly supportedby others, on a part-time basis. (L3-4,Ab1, 1)

q The (group responsible for theorganization’s software processactivities) is staffed to represent thesoftware engineering discipline andsoftware-related disciplines. (L3-4,Ab1, 2)

q Members of the group responsible forthe organization’s software processactivities receive required training toperform these activities. (L3-5, Ab3)

q Where appropriate, training (for theorganization’s and projects’ softwareprocesses) may be prepared andconducted by the group responsiblefor the organization’s softwareprocess activities (e.g., softwareengineering process group) or by thetraining group. (L3-8, A6, 2)

Groupsinvolved inimplementingthe softwareprocesses

The groups involved in implementingthe software processes are informed of theorganization’s and projects’ activities forsoftware process development andimprovement. (L3-9, A7)



OPF Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theorganization process focus process, continued from the previous page.


Individuals q Experienced individuals who haveexpertise in specialized areas arecommitted to support (the groupresponsible for the organization’ssoftware process activities). (L3-5,Ab2, 1)

q A summary report from each (seniormanagement) review (of the activitiesfor software process development andimprovement) is prepared anddistributed to the affected groups andindividuals. (L3-10, V1, 4)

Managers q Senior management coordinatessoftware process requirements andissues with higher level staff andmanagers. (L3-3, C3, 3.1)

q Senior management coordinates withthe organization’s managers to securethe managers’ and staff’s support andparticipation. (L3-3, C3, 3.2)

Seniormanagement

q Senior management sponsors theorganization’s activities for softwareprocess development and improvement.(L3-2, C2)

Senior management:

q Demonstrates to the organization’sstaff and managers its commitmentto these software process activities.

q Establishes long-term plans andcommitments for funding, staffing,and other resources.

q Establishes strategies for managingand implementing the activities forprocess development andimprovement.





Roles,continued



Seniormanagement,continued

q Senior management oversees theorganization’s activities for softwareprocess development and improvement.(L3-3, C3)

Senior management:

q Ensures that the organization’sstandard software process supportsits business goals and strategies.

q Advises on setting priorities forsoftware process development andimprovement.

q Participates in establishing plansfor software process developmentand improvement.

q Coordinates software processrequirements and issues withhigher level staff and managers.

q Coordinates with theorganization’s managers tosecure the managers’ andstaff’s support and participation.

q The activities for software processdevelopment and improvement arereviewed with senior management ona periodic basis. (L3-10, V1)

Seniormanagers

(The organizational plan for softwareprocess development and improvementactivities) is reviewed and agreed to by theorganization’s software managers andsenior managers. (L3-7, A2, 6)


Members of the software engineeringgroup and other software-related groupsreceive orientation on the organization’ssoftware process activities and their rolesin those activities. (L3-6, Ab4)




Roles,continued



Softwaremanagers

(The organizational plan for softwareprocess development and improvementactivities) is reviewed and agreed to by theorganization’s software managers andsenior managers. (L3-7, A2, 6)


Members of the software engineering groupand other software-related groups receiveorientation on the organization’s softwareprocess activities and their roles in thoseactivities. (L3-6, Ab4)

Staff Senior management coordinates softwareprocess requirements and issues withhigher level staff and managers. (L3-3,C3, 3.1)

Traininggroup

Where appropriate, training for theorganization’s and projects’ softwareprocesses may be prepared and conductedby the group responsible for theorganization’s software process activities(e.g., software engineering process group)or by the training group. (L3-8, A6, 2)


OPF Process - Entry Cr i ter ia


There are no input-based entry criteria for the organization process focus process.


The CMM recommends that the conditions described in the table below besatisfied before entering the organization process focus process.


The organization follows a written organizational policy forcoordinating software process development andimprovement activities across the organization. (L3-2, C1)

[Refer to Level 3 Policies for additional informationregarding OPF policy.]

Senior management sponsors the organization’s activitiesfor software process development and improvement. (L3-2,C2)

Senior management oversees the organization’s activitiesfor software process development and improvement. (L3-3,C3)

A group that is responsible for the organization’ssoftware process activities exists. (L3-3, Ab1)

Where possible, the group responsible for theorganization’s software process activities is staffed by acore of software technical professionals who are assignedfull time to the group, possibly supported by others, on apart-time basis. (L3-4, Ab1, 1)

The group responsible for the organization’s softwareprocess activities is staffed to represent the softwareengineering discipline and software-related disciplines. (L3-4, Ab1, 2)

Adequate resources and funding are provided for theorganization’s software process activities. (L3-4, Ab2)

Experienced individuals who have expertise in specializedareas are committed to support the group responsible forthe organization’s software process activities. (L3-5,Ab2, 1)

Tools to support the organization’s software processactivities are made available. (L3-5, Ab2, 2)

Members of the group responsible for the organization’ssoftware process activities receive required training toperform these activities. (L3-5, Ab3)


Members of the software engineering group and othersoftware-related groups receive orientation on theorganization’s software process activities and their roles inthose activities. (L3-6, Ab4)


OPF Process - Inputs

Inputs The table below lists the inputs to the organization process focus process.


Action plans from the software processassessments. (L3-7, A2, 1)

Business goals and strategies. (L3-3, C3,1)

Improvements to, and other usefulinformation on, each project’s softwareprocess, tools, and methods. (L3-2, C1, 4)

New processes, methods, and tools inlimited use in the organization. (L3-8, A5)

Organization improvement initiatives.(L3-7, A2, 1)

Organization’s software process database.(L3-8, A4)

Organization’s standard software process.(L3-2, C1, 3)

Plan for the organization’s softwareprocess development and improvementactivities. (L3-7, A2)

Progress and status of the activities todevelop and improve the software process.(L3-10, V1, 1)

Projects’ defined software process. (L3-8,A3, 2)

Software process issues. (L3-3, C3, 3.1)

Software process requirements. (L3-3, C3,3.1)

Software process. (L3-6, A1)

Software processes used by the project.(L3-2, C1, 2)


OPF Process - Act iv i t ies

Activities The table below lists the recommended activities for the organization processfocus process.


The software process is assessed periodically, and actionplans are developed to address the assessment findings.(L3-6, A1)

The organization develops and maintains a plan for itssoftware process development and improvement activities.(L3-7, A2)

The organization’s and projects’ activities for developingand improving their software processes are coordinated atthe organization level. (L3-7, A3)

This coordination covers the development and improvementof:

q The organization’s standard software process.

q The projects’ defined software processes.

The use of the organization’s software process database iscoordinated at the organizational level. (L3-8, A4)

New processes, methods, and tools in limited use in theorganization are monitored, evaluated, and, whereappropriate, transferred to other parts of the organization.(L3-8, A5)

Training for the organization’s and projects’ softwareprocesses is coordinated across the organization. (L3-8, A6)

q Plans for training on subjects related to theorganization’s and projects’ software processes areprepared.

q Where appropriate, training may be prepared andconducted by the group responsible for theorganization’s software process activities (e.g.,software engineering process group) or by the traininggroup.

The groups involved in implementing the softwareprocesses are informed of the organization’s and projects’activities for software process development andimprovement. (L3-9, A7)



OPF Process - Act iv i t ies , Continued


The table below lists the recommended activities for the organization processfocus process, continued from the previous page.


Measurements are made and used to determine the status ofthe organization’s process development and improvementactivities. (L3-9, M1)

The activities for software process development andimprovement are reviewed with senior management on aperiodic basis. (L3-10, V1)

q Progress and status of the activities to develop andimprove the software process are reviewed against theplan.

q Conflicts and issues not resolved at lower levels areaddressed.

q Action items are assigned, reviewed, and tracked toclosure.

q A summary report from each review is prepared anddistributed to the affected groups and individuals.


OPF Process - Outputs

Outputs The table below lists the outputs produced by the organization process focusprocess.


Action items (from senior managementreviews of the activities for softwareprocess development and improvement).(L3-10, V1, 3)

Action plans. (L3-6, A1)

Assessment findings. (L3-6, A1)

Conflicts and issues not resolved at lowerlevels. (L3-10, V1, 2)

Improvements to, and other usefulinformation on, each project’s softwareprocess, tools, and methods. (L3-2, C1, 4)

Long-term plans and commitments forfunding, staffing, and other resources (forthe organization’s activities for softwareprocess development and improvement).(L3-3, C2, 2)

Measurements (to determine the status ofthe organization’s process developmentand improvement activities). (L3-9, M1)

Plan for organizational software processdevelopment and improvement activities.(L3-7, A2)

Plans for software process developmentand improvement. (L3-3, C3, 3)

Plans for training on subjects related to theorganization’s and projects’ softwareprocesses. (L3-8, A6, 1)

Priorities for software process developmentand improvement. (L3-3, C3, 2)

Progress and status of the activities todevelop and improve the software process.(L3-10, V1, 1)

Schedule for the software processdevelopment and improvement activities.(L3-7, A2, 2)

Software process issues. (L3-3, C3, 3.1)

Software process requirements. (L3-3, C3,3.1)


OPF Process - Outputs , Continued

Outputs,continued

The table below lists the outputs produced by the organization process focusprocess, continued from the previous page.


Strategies for managing and implementingthe activities for process development andimprovement. (L3-3, C2, 3)

Summary report from each (seniormanagement) review of the activities forsoftware process development andimprovement. (L3-10, V1, 4)


OPF Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the organization process focus process.


Action items (fromsenior managementreviews of theactivities for softwareprocess developmentand improvement)




Action plans are developed to address softwareprocess assessment findings. (L3-6,A1)

Conflicts and issuesnot resolved at lowerlevels

are addressed (during seniormanagement reviews of theactivities for software processdevelopment and improvement).(L3-10, V1, 2)

Improvements to, andother usefulinformation on, eachproject’s softwareprocess, tools, andmethods

are available to other projects. (L3-2, C1, 4)

Long-term plans andcommitments forfunding, staffing, andother resources (forthe organization’sactivities for softwareprocess developmentand improvement)

are established by seniormanagement. (L3-3, C2, 2)

Measurements (todetermine the statusof the organization’sprocess developmentand improvementactivities)





OPF Process - Exi t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the organization process focus process, continued from the previous page.


Plan fororganizationalsoftware processdevelopment andimprovementactivities

q is developed by the organization.(L3-7, A2)

q is maintained by theorganization. (L3-7, A2)

q undergoes peer review wheninitially released and whenevermajor revisions are made. (L3-7,A2, 5)

q is reviewed and agreed to by theorganization’s softwaremanagers and seniormanagers. (L3-7, A2, 6)

Plans for softwareprocess developmentand improvement

are established with the participationof senior management. (L3-3, C3,3)

Plans for training onsubjects related tothe organization’sand projects’software processes

are prepared. (L3-8, A6, 1)

Priorities for softwareprocess developmentand improvement

are set with the advice of seniormanagement. (L3-3, C3, 2)

Progress and status ofthe activities todevelop and improvethe software process

are reviewed against the plan. (L3-10, V1, 1)

Schedule for thesoftware processdevelopment andimprovementactivities

is defined in the plan (fororganizational software processdevelopment and improvementactivities). (L3-7, A2, 2)

Software processissues

are coordinated by seniormanagement with higher level staffand managers. (L3-3, C3, 3.1)

Software processrequirements

are coordinated by seniormanagement with higher level staffand managers. (L3-3, C3, 3.1)




The CMM recommends that outputs satisfy the states described in the table belowto exit the organization process focus process, continued from the previous page.


Strategies formanaging andimplementing theactivities for processdevelopment andimprovement


Summary report fromeach (seniormanagement) reviewof the activities forsoftware processdevelopment andimprovement



The CMM recommends that the conditions described in the table below besatisfied to exit the organization process focus process.



The software processes used by the projects are assessedperiodically to determine their strengths and weaknesses.(L3-2, C1, 2)

The software processes used by the projects areappropriately tailored from the organization's standardsoftware process. (L3-2, C1, 3)

The organization’s standard software process supports itsbusiness goals and strategies. (L3-3, C3, 1)

The software process is assessed periodically, and actionplans are developed to address the assessment findings.(L3-6, A1)

The organization’s and projects’ activities for developingand improving their software processes are coordinated atthe organization level. (L3-7, A3)

This coordination covers the development and improvementof:

q The organization’s standard software process.

q The projects’ defined software processes.

The use of the organization’s software process database iscoordinated at the organizational level. (L3-8, A4)




The CMM recommends that the conditions described in the table below besatisfied to exit the organization process focus process, continued from theprevious page.


New processes, methods, and tools in limited use in theorganization are monitored, evaluated, and, whereappropriate, transferred to other parts of the organization.(L3-8, A5)

Training for the organization’s and projects’ softwareprocesses is coordinated across the organization. (L3-8, A6)

The groups involved in implementing the softwareprocesses are informed of the organization’s and projects’activities for software process development andimprovement. (L3-9, A7)

The activities for software process development andimprovement are reviewed with senior management on aperiodic basis. (L3-10, V1)


OPF Process - Reviews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the organizationprocess focus process.


References

The plan for organizational softwareprocess development and improvementactivities undergoes peer review wheninitially released and whenever majorrevisions are made. (L3-7, A2, 5)


The plan for organizational softwareprocess development and improvementactivities is reviewed and agreed to by theorganization's software managers andsenior managers. (L3-7, A2, 6)

Softwaremanagers

Seniormanagers

The activities for software processdevelopment and improvement arereviewed with senior management on aperiodic basis. (L3-10, V1)

Seniormanagement

Progress and status of the activities todevelop and improve the software processare reviewed against the plan. (L3-10, V1,1)



OPF Process - Work Products Managed andContro l led


There are no work products that are recommended to be managed and controlledduring the organization process focus process.


OPF Process - Measurements

Measurements The table below lists the recommended measurements for the organization processfocus process.


Measurements to determine the status of the organization’sprocess development and improvement activities. (L3-9,M1)


q Work completed, effort expended, and funds expendedin the organization’s activities for process assessment,development, and improvement compared to the plansfor these activities.

q Results of each software process assessment, comparedto the results and recommendations of previousassessments.


OPF Process - Documented Procedures


There are no activities that are recommended to be performed according to adocumented procedure in the organization process focus process.


OPF Process - Tra in ing

Training The table below lists the training recommended for the organization process focusprocess.

Training References

Members of the group responsible for the organization’ssoftware process activities receive required training toperform these activities. (L3-5, Ab3)

Members of the software engineering group and othersoftware-related groups receive orientation on theorganization’s software process activities and their roles inthose activities. (L3-6, Ab4)

Training for the organization’s and projects’ softwareprocesses. (L3-8, A6)

q Where appropriate, training may be prepared andconducted by the group responsible for theorganization's software process activities (e.g.,software engineering process group) or by thetraining group. (L3-8, A6, 2)


OPF Process - Too ls

Tools The table below lists the tools recommended for the organization process focusprocess.

Tools References

Tools to support the organization’s software processactivities. (L3-5, Ab2, 2)


q statistical analysis tools,

q desktop publishing tools,

q database management systems, and

q process modeling tools.


Organizat ion Process Def in i t ion (OPD) Process

OPD Process - Overv iew

The purpose of Organization Process Definition is to develop and maintain ausable set of software process assets that improve process performance across theprojects and provide a basis for cumulative, long-term benefits to the organization.(L3-11)

OPD processpurpose

Organization Process Definition involves developing and maintaining theorganization's standard software process, along with related process assets, suchas descriptions of software life cycles, process tailoring guidelines and criteria,the organization's software process database, and a library of software process-related documentation.

These assets may be collected in many ways, depending on the organization'simplementation of Organization Process Definition. For example, the descriptionsof the software life cycles may be an integral part of the organization's standardsoftware process or parts of the library of software process-related documentationmay be stored in the organization's software process database.

The organization's software process assets are available for use in developing,implementing, and maintaining the projects' defined software processes. (Thepractices related to the development and maintenance of the project's definedsoftware process are described in the Integrated Software Management keyprocess area.) (L3-11)

OPD processdescription



OPD Process - Overv iew , Continued

Sectionoverview




L3-Process-27



L3-Process-30


L3-Process-31


L3-Process-33


L3-Process-35

Reviews andAudits




L3-Process-43




L3-Process-45




OPD Process - Ro les

Roles The table below lists the roles and the activities in which they participate in theorganization process definition process.


Groupresponsiblefor theorganization’ssoftwareprocessactivities (e.g.,softwareengineeringprocessgroup)

q The development and maintenance ofthe organization's standard softwareprocess and related process assets isperformed or coordinated by the groupresponsible for the organization'ssoftware process activities (e.g.,software engineering process group).(L3-14, Ab1, 1)

q Changes proposed for the organization'sstandard software process aredocumented, reviewed, and approvedby the group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) before they areincorporated. (L3-16, A1, 6)

q Changes proposed for the descriptionsof software life cycles are documented,reviewed, and approved by the groupresponsible for the organization'ssoftware process activities (e.g.,software engineering process group)before they are incorporated. (L3-18,A3, 2)

q Changes proposed for the tailoringguidelines and criteria (for the projects’tailoring of the organization’s standardsoftware process) are documented,reviewed, and approved by the groupresponsible for the organization'ssoftware process activities (e.g.,software engineering process group)before they are incorporated. (L3-20,A4, 2)



OPD Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theorganization process definition process, continued from the previous page.


Individualswho developand maintaintheorganization'sstandardsoftwareprocess andrelatedprocess assets

The individuals who develop andmaintain the organization's standardsoftware process and related processassets receive required training to performthese activities. (L3-14, Ab2)

Softwarequalityassurancegroup

The software quality assurance groupreviews and/or audits the organization'sactivities and work products for developingand maintaining the organization's standardsoftware process and related process assetsand reports the results. (L3-23, V1)


OPD Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the organization process definition process.


Descriptions ofsoftware life cycles

q are approved for use by theprojects. (L3-18, A3)


Organizationalstandards (fordocumenting theorganization’sstandard softwareprocess)

are established. (L3-17, A2)

The CMM recommends that the conditions described in the table below besatisfied before entering the organization process definition process.



The organization follows a written policy for developing andmaintaining a standard software process and related processassets. (L3-12, C1)

[Refer to Level 3 Policies for additional informationregarding OPD policy.]

Adequate resources and funding are provided for developingand maintaining the organization's standard software processand related process assets. (L3-14, Ab1)

The development and maintenance of the organization'sstandard software process and related process assets isperformed or coordinated by the group responsible for theorganization's software process activities (e.g., softwareengineering process group). (L3-14, Ab1, 1)

Tools to support process development and maintenance aremade available. (L3-14, Ab1, 2)

The individuals who develop and maintain theorganization's standard software process and relatedprocess assets receive required training to perform theseactivities. (L3-14, Ab2)


OPD Process - Inputs

Inputs The table below lists the recommended inputs to the organization processdefinition process.


Candidate documentation items. (L3-21,A6, 1)

Changes proposed for the descriptions ofsoftware life cycles. (L3-18, A3, 2)

Changes proposed for the organization'sstandard software process. (L3-16, A1, 6)

Changes proposed for the tailoringguidelines and criteria. (L3-20, A4, 2)

Data entered into the (software process)database. (L3-21, A5, 2)

Data on the software work products(resulting from the software processes).(L3-20, A5, 1)

Data on the software processes. (L3-20,A5, 1)

Descriptions of software life cycles. (L3-18, A3)

Guidelines and criteria for the projects’tailoring of the organization’s standardsoftware process. (L3-19, A4)

Information collected from the projects (toimprove the organization’s standardsoftware process). (L3-13, C1, 4)

Library of software process-relateddocumentation. (L3-21, A6)

Organization’s software process assets orrelated process assets. (L3-12, C1)

Organization’s standard software process.(L3-12, C1)

Organization standards. (L3-17, A2)

Software policies. (L3-15, A1, 1)

Software process standards. (L3-15, A1, 1)

Software product standards. (L3-15, A1, 1)

State-of-the-practice software engineeringmethods. (L3-15, A1, 3)

State-of-the-practice software engineeringtools. (L3-15, A1, 3)


OPD Process - Act iv i t ies

Activities The table below lists the recommended activities for the organization processdefinition process.


The organization's standard software process is developedand maintained according to a documented procedure. (L3-15, A1)


The organization's standard software process is documentedaccording to established organization standards. (L3-17,A2)

[Refer to Level 3 Standards for additional informationregarding the organization's standard software process.]

Descriptions of software life cycles that are approved for useby the projects are documented and maintained. (L3-18,A3)

q Changes proposed for the descriptions of software lifecycles are documented, reviewed, and approved by thegroup responsible for the organization's softwareprocess activities (e.g., software engineering processgroup) before they are incorporated. (L3-18, A3, 2)

q The descriptions of the software life cycles undergo peerreview when initially documented and wheneversignificant changes or additions are made. (L3-19, A3,3)

q The descriptions of the software life cycles are managedand controlled. (L3-19, A3, 4)

Guidelines and criteria for the projects' tailoring of theorganization's standard software process are developed andmaintained. (L3-19, A4)

q The tailoring guidelines and criteria are managed andcontrolled. (L3-20, A4, 3)

[Refer to Level 3 Standards for additional informationregarding tailoring guidelines and criteria.]



OPD Process - Act iv i t ies , Continued


The table below lists the recommended activities for the organization processdefinition process, continued from the previous page.


The organization's software process database is establishedand maintained. (L3-20, A5)

q The database is established to collect and makeavailable data on the software processes and resultingsoftware work products.

q The data entered into the database are reviewed toensure the integrity of the database contents.

q The database is managed and controlled.

q User access to the database contents is controlled toensure completeness, integrity, and accuracy of thedata.

A library of software process-related documentation isestablished and maintained. (L3-21, A6)

q Candidate documentation items are reviewed andappropriate items that may be useful in the future areincluded in the library.

q The documentation items are catalogued for easyaccess.

q Revisions made to documentation items currently in thelibrary are reviewed, and the library contents areupdated as appropriate.

q The library contents are made available for use by thesoftware projects and other software-related groups.

q The use of each documentation item is reviewedperiodically, and the results are used to maintain thelibrary contents.

q The library contents are managed and controlled.

Measurements are made and used to determine the status ofthe organization's process definition activities. (L3-22, M1)

The software quality assurance group reviews and/oraudits the organization's activities and work products fordeveloping and maintaining the organization's standardsoftware process and related process assets and reports theresults. (L3-23, V1)


OPD Process - Outputs

Outputs The table below lists the recommended outputs produced by the organizationprocess definition process.


Candidate documentation items (for thelibrary of software process-relateddocumentation). (L3-21, A6, 1)

Data on the software work products(resulting from the software processes).(L3-20, A5, 1)

Data on the software processes. (L3-20,A5, 1)

Descriptions of software life cycles orsoftware life cycles. (L3-18, A3)

External process interfaces between thesoftware process and the processes of otheraffected groups. (L3-16, A1, 5)

Guidelines and criteria for the projects’tailoring of the organization’s standardsoftware process. (L3-19, A4)

Internal process interfaces between thesoftware disciplines. (L3-15, A1, 4)

Library of software process-relateddocumentation or library contents. (L3-21,A6)

Measurements (to determine the status ofthe organization’s process definitionactivities). (L3-22, M1)

Organization’s software process assets orrelated process assets. (L3-12, C1)

Organization’s standard software process.(L3-12, C1)

Plans for introducing changes to thesoftware process of ongoing projects. (L3-16, A1, 7)

Process element relationships. (L3-18, A2,3)

Process element. (L3-17, A2, 1)

Results of periodic reviews of the use ofsoftware-process related documentationitems. (L3-22, A6, 5)


Results of SQA group reviews and/oraudits. (L3-23, V1)



OPD Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the organizationprocess definition process, continued from the previous page.


Revisions made to documentation itemscurrently in the (software process-relateddocumentation) library. (L3-22, A6, 3)

Software process-related documentation ordocumentation items. (L3-21, A6)


OPD Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the organization process definition process.


Candidate (softwareprocess-related)documentation items


q are included in the library (ofsoftware process-relateddocumentation), if they may beuseful in the future. (L3-21, A6,1)

Data on the softwarework products(resulting from thesoftware processes)

q are collected into theorganization's software processdatabase. (L3-20, A5)

q are made available from theorganization's software processdatabase. (L3-20, A5)

q completeness of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)

q integrity of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)

q accuracy of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)


Data on the softwareprocesses

q are collected into theorganization's software processdatabase. (L3-20, A5)

q are made available from theorganization's software processdatabase. (L3-20, A5)

q completeness of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)

q integrity of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)

q accuracy of is ensured bycontrolling access to thesoftware process database. (L3-21, A5, 4)



OPD Process - Exi t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the organization process definition process, continued from the previouspage.


Descriptions ofsoftware life cycles


q are maintained. (L3-18, A3)

q are compatible with theorganization's standard softwareprocess. (L3-18, A3, 1)

q undergo peer review wheninitially documented andwhenever significant changes oradditions are made. (L3-19, A3,3)


External processinterfaces betweenthe software processand the processes ofother affectedgroups

are described. (L3-16, A1, 5)

Guidelines andcriteria for theprojects’ tailoring ofthe organization’sstandard softwareprocess


q are maintained. (L3-19, A4)


Internal processinterfaces betweenthe softwaredisciplines

are described. (L3-15, A1, 4)

Library of softwareprocess-relateddocumentation orlibrary contents

q is established. (L3-21, A6)

q is maintained. (L3-21, A6)

q is updated as appropriate. (L3-22, A6, 3)

q is made available for use by thesoftware projects and othersoftware-related groups. (L3-22,A6, 4)







Measurements (todetermine the statusof the organization'sprocess definitionactivities)



Organization’ssoftware processassets or relatedprocess assets

q are maintained. (L3-13, C1, 3)

q are controlled. (L3-23, V1, 2)

q are used appropriately. (L3-23,V1, 2)







Organization’sstandard softwareprocess

q is defined for the organization.(L3-12, C1, 1)


q is maintained according to adocumented procedure. (L3-15,A1)

q satisfies the software policies,process standards, and productstandards imposed on theorganization, as appropriate.(L3-15, A1, 1)

q satisfies the software process andproduct standards that arecommonly imposed on theorganization's projects by theircustomers, as appropriate. (L3-15, A1, 2)

q incorporates state-of-the-practicesoftware engineering tools andmethods, as appropriate. (L3-15,A1, 3)

q description undergoes peerreview when initially developedand whenever significantchanges or additions are made.(L3-16, A1, 8)

q is placed under configurationmanagement. (L3-17, A1, 9)

q is documented according toestablished organizationstandards. (L3-17, A2)

q is decomposed into constituentprocess elements to thegranularity needed to understandand describe the process. (L3-17, A2, 1)

Exit criteria continued on next page






Organization’sstandard softwareprocess, continued

q is controlled. (L3-23, V1, 2)

q is used appropriately. (L3-23,V1, 2)

Plans for introducingchanges to thesoftware process ofongoing projects

are defined as appropriate. (L3-16,A1, 7)

Process elementrelationships

q are described. (L3-18, A2, 3)

q address: (L3-18, A2, 3)

q the ordering,

q the interfaces, and

q the interdependencies.

Process element is described. (L3-17, A2, 2)

Results of periodicreviews of the use ofdocumentation items

are used to maintain the library (ofsoftware process-relateddocumentation) contents. (L3-22,A6, 5)

Results of SQAgroup reviews and/oraudits


Revisions made todocumentation itemscurrently in thelibrary

are reviewed. (L3-22, A6, 3)

Software process-relateddocumentation ordocumentation items

q are catalogued for easy access.(L3-22, A6, 2)

q are reviewed periodically. (L3-22, A6, 5)




The CMM recommends that the conditions described in the table below besatisfied to exit the organization process definition process.


A project's defined software process is a tailored version ofthe organization's standard software process. (L3-13, C1, 2)

Information collected from the projects is organized andused to improve the organization's standard softwareprocess. (L3-13, C1, 4)

Changes proposed for the descriptions of software life cyclesare documented, reviewed, and approved by the groupresponsible for the organization's software processactivities (e.g., software engineering process group)before they are incorporated. (L3-18, A3, 2)

Changes proposed for the tailoring guidelines and criteriaare documented, reviewed, and approved by the groupresponsible for the organization's software processactivities (e.g., software engineering process group)before they are incorporated. (L3-20, A4, 2)

The organization's software process database is establishedand maintained. (L3-20, A5)

q The database is established to collect and makeavailable data on the software processes and resultingsoftware work products.

q The data entered into the database are reviewed toensure the integrity of the database contents.

q The database is managed and controlled.

q User access to the database contents is controlled toensure completeness, integrity, and accuracy of thedata.

The software quality assurance group reviews and/oraudits the organization's activities and work products fordeveloping and maintaining the organization's standardsoftware process and related process assets and reports theresults. (L3-23, V1)

The appropriate standards are followed in developing,documenting, and maintaining the organization's standardsoftware process and related process assets. (L3-23, V1, 1)


OPD Process - Reviews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the organizationprocess definition process.


References

Changes proposed for the organization'sstandard software process are documented,reviewed, and approved by the groupresponsible for the organization'ssoftware process activities (e.g., softwareengineering process group) before theyare incorporated. (L3-16, A1, 6)

Groupresponsiblefor theorganization'ssoftwareprocessactivities (e.g.,softwareengineeringprocessgroup)

The description of the organization'sstandard software process undergoes peerreview when initially developed andwhenever significant changes or additionsare made. (L3-16, A1, 8)


Changes proposed for the descriptions ofsoftware life cycles are documented,reviewed, and approved by the groupresponsible for the organization'ssoftware process activities (e.g., softwareengineering process group) before theyare incorporated. (L3-18, A3, 2)


The descriptions of the software life cyclesundergo peer review when initiallydocumented and whenever significantchanges or additions are made. (L3-19,A3, 3)



Changes proposed for the tailoringguidelines and criteria are documented,reviewed, and approved by the groupresponsible for the organization'ssoftware process activities (e.g., softwareengineering process group) before theyare incorporated. (L3-20, A4, 2)




OPD Process - Reviews and Audi ts , Continued


The table below lists the recommended reviews and audits for the organizationprocess definition process, continued from the previous page.


References

The data entered into the (organization'ssoftware process) database is reviewed toensure the integrity of the databasecontents. (L3-21, A5, 2)


Candidate (software process-related)documentation items are reviewed andappropriate items that may be useful in thefuture are included in the library (ofsoftware-process related documentation).(L3-21, A6, 1)


Revisions made to (software process-related) documentation items currently inthe library are reviewed, and the librarycontents are updated as appropriate. (L3-22, A6, 3)


The use of each (software process-related)documentation item is reviewedperiodically, and the results are used tomaintain the library contents. (L3-22, A6,5)


The software quality assurance groupreviews and/or audits the organization'sactivities and work products for developingand maintaining the organization'sstandard software process and relatedprocess assets and reports the results. (L3-23, V1)

At a minimum, these reviews and/or auditsverify that:

q The appropriate standards are followedin developing, documenting, andmaintaining the organization's standardsoftware process and related processassets.

q The organization's standard softwareprocess and related process assets arecontrolled and used appropriately.



OPD Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the organization process definition process.


Description of the organization's standard software process.*

(L3-17, A1, 9)

Descriptions of the software life cycles. (L3-19, A3, 4)

Tailoring guidelines and criteria. (L3-20, A4, 3)

Organization's software process database. (L3-21, A5, 3)

Library of software process-related documentation. (L3-22,A6, 6)

*Indicates that the CMM recommends that this item must be placed underconfiguration management


OPD Process - Measurements

Measurements The table below lists the recommended measurements for the organization processdefinition process.


Data on the software work products (resulting from thesoftware process). (L3-20, A5, 1)

Data on the software processes. (L3-20, A5, 1)

Measurements to determine the status of the organization'sprocess definition activities. (L3-22, M1)


q Status of the schedule milestones for processdevelopment and maintenance.

q Costs for the process definition activities.


OPD Process - Documented Procedures


The table below lists the activities for the organization process definition processrecommended to be performed according to a documented procedure.




OPD Process - T ra in ing

Training The table below lists the training recommended for the organization processdefinition process.

Training References

The individuals who develop and maintain theorganization's standard software process and relatedprocess assets receive required training to perform theseactivities. (L3-14, Ab2)


OPD Process - Too ls

Tools The table below lists the tools recommended for the organization processdefinition process.

Tools References

Tools to support process development and maintenance.(L3-14, Ab1, 2)


q desktop publishing tools,

q database management systems, and


State-of-the-practice software engineering tools. (L3-15,A1, 3)

Organization’s software process database. (L3-20, A5)


Tra in ing Program (TP) Process

T P P r o c e s s - O v e r v i e w

The purpose of the Training Program key process area is to develop the skills andknowledge of individuals so they can perform their roles effectively andefficiently. (L3-25)

TP processpurpose

Training Program involves first identifying the training needed by theorganization, projects, and individuals, then developing or procuring training toaddress the identified needs.

Each software project evaluates its current and future skill needs and determineshow these skills will be obtained. Some skills are effectively and efficientlyimparted through informal vehicles (e.g., on-the-job training and informalmentoring), whereas other skills need more formal training vehicles (e.g.,classroom training and guided self-study) to be effectively and efficientlyimparted. The appropriate vehicles are selected and used.

This key process area covers the practices for the group performing the trainingfunction. The practices identifying the specific training topics (i.e., knowledge orskill needed) are contained in the Ability to Perform common feature of theindividual key process areas. (L3-25)

TP processdescription



T P P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L3-Process-51



L3-Process-53


L3-Process-54


L3-Process-55


L3-Process-56

Reviews andAudits




L3-Process-61




L3-Process-63




TP Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thetraining program process.


Affectedgroups

The organization's training plan is readilyavailable to the affected groups andindividuals. (L3-31, A2, 6)

Affectedindividuals

q The organization's training plan isreviewed by the affected individualswhen it is initially released andwhenever major revisions are made.(L3-31, A2, 4)

q The organization's training plan isreadily available to the affected groupsand individuals. (L3-31, A2, 6)

Manager A manager is designated to be responsiblefor implementing the organization'straining program. (L3-28, Ab2, 1)

Seniormanagement

The training program activities arereviewed with senior management on aperiodic basis. (L3-35, V1)

Softwaremanager

Software managers receive orientation onthe training program. (L3-29, Ab4)

Traininggroup

Members of the training group have thenecessary skills and knowledge to performtheir training activities. (L3-28, Ab3)


TP Process - Entry Cr i ter ia


There are no input-based entry criteria in the training program process.


The CMM recommends that the conditions described in the table below besatisfied before entering the training program process.


The organization follows a written policy for meeting itstraining needs. (L3-26, C1)

[Refer to Level 3 Policies for additional informationregarding TP policy.]

A group responsible for fulfilling the training needs ofthe organization exists. (L3-27, Ab1)

Adequate resources and funding are provided forimplementing the training program. (L3-27, Ab2)

A manager is designated to be responsible forimplementing the organization's training program. (L3-28,Ab2, 1)

Tools to support the training program activities are madeavailable. (L3-28, Ab2, 2)

Appropriate facilities are made available to conducttraining. (L3-28, Ab2, 3)

Members of the training group have the necessary skillsand knowledge to perform their training activities. (L3-28,Ab3)

Software managers receive orientation on the trainingprogram. (L3-29, Ab4)


TP Process - Inputs

Inputs The table below lists the recommended inputs to the training program process.


Changes to the organization’s trainingplan. (L3-31, A2, 3)

Organization’s training plan. (L3-30, A2)

[Refer to Level 3 Standards for additionalinformation regarding the organization’straining plan.]

Organizational standards for trainingcourses. (L3-33, A4)

[Refer to Level 3 Standards for additionalinformation regarding organizationalstandards for training.]

Procedures for collecting, reviewing, andusing training evaluations and othertraining feedback. (L3-33, A3, 7.4)

Procedures for maintaining records of thetraining provided. (L3-33, A3, 7.3)

Procedures for registering and participatingin the training. (L3-33, A3, 7.2)

Procedures for selecting the individualswho will receive the training. (L3-33, A3,7.1)

Skills needed by the organization andwhen those skills are needed. (L3-30, A2,2)

Software projects’ training needs. (L3-29,A1)

Standards for instructional materials usedin training courses. (L3-32, A3, 4)

Training courses prepared at theorganizational level. (L3-33, A4)

Training evaluations. (L3-33, A3, 7.4)

Training plan (for each software project).(L3-29, A1)

Waiver procedure for required training.(L3-34, A5)


TP Process - Act iv i t ies

Activities The table below lists the recommended activities for the training program process.


Each software project develops and maintains a trainingplan that specifies its training needs. (L3-29, A1)

The organization's training plan is developed and revisedaccording to a documented procedure. (L3-30, A2)

[Refer to Level 3 Procedures for additional information.]

The training for the organization is performed in accordancewith the organization's training plan. (L3-32, A3)

Training courses prepared at the organization level aredeveloped and maintained according to organizationstandards. (L3-33, A4)

A waiver procedure for required training is established andused to determine whether individuals already possess theknowledge and skills required to perform in their designatedroles. (L3-34, A5)

Records of training are maintained. (L3-34, A6)

q Records are kept of all students who successfullycomplete each training course or other approved trainingactivity.

q Records are kept of all students who successfullycomplete their designated required training.

q Records of successfully completed training are madeavailable for consideration in assignments of the staffand managers.

Measurements are made and used to determine the status ofthe training program activities. (L3-34, M1)

Measurements are made and used to determine the qualityof the training program. (L3-35, M2)

The training program activities are reviewed with seniormanagement on a periodic basis. (L3-35, V1)

The training program is independently evaluated on aperiodic basis for consistency with, and relevance to, theorganization's needs. (L3-36, V2)

The training program activities and work products arereviewed and/or audited and the results are reported. (L3-36, V3)

[Refer to TP Process Reviews and Audits for additionalinformation]


TP Process - Outputs

Outputs The table below lists the recommended outputs produced by the training programprocess.


Description of each training course. (L3-33, A4, 1)

Materials for the training course. (L3-33,A4, 2)

Measurements. (L3-34, M1)

Needed skills and knowledge for eachsoftware management role. (L3-26, C1, 1)

Needed skills and knowledge for eachtechnical role. (L3-26, C1, 1)

Organization’s training plan. (L3-30, A2)

Records of all students who successfullycomplete each training course or otherapproved training activity. (L3-34, A6, 1)

Records of all students who successfullycomplete their designated requiredtraining. (L3-34, A6, 2)

Records of successfully completedtraining. (L3-34, A6, 3)

Records of training or training records.(L3-34, A6)

Results of reviews and/or audits of thetraining program activities and workproducts. (L3-36, V3)

Specific training to be provided. (L3-30,A2, 2)

Training courses prepared at theorganization level. (L3-33, A4)

Training plan (for each software project).(L3-29, A1)

Training program work products. (L3-36,V3)

Training vehicles for imparting skills andknowledge. (L3-26, C1, 2)

Waiver procedure for required training.(L3-34, A5)


TP Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the training program process.


Description of eachtraining course

is developed. (L3-33, A4, 1)

Materials for thetraining course



Measurements q are made to determine the statusof the training program activities.(L3-34, M1)

q are used to determine the statusof the training program activities.(L3-34, M1)

q are made to determine thequality of the training program.(L3-35, M2)

q are used to determine the qualityof the training program. (L3-35,M2)

Needed skills andknowledge for eachsoftwaremanagement role

are identified. (L3-26, C1, 1)

Needed skills andknowledge for eachtechnical role

are identified. (L3-26, C1, 1)



TP Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the training program process, continued from the previous page.


Organization’straining plan



q uses the software projects'training needs identified in theirtraining plans. (L3-30, A2, 1)

q is revised, as appropriate, toincorporate changes. (L3-31,A2, 3)

q is reviewed by the affectedindividuals when it is initiallyreleased and whenever majorrevisions are made. (L3-31, A2,4)


q is readily available to theaffected groups andindividuals. (L3-31, A2, 6)

Records of allstudents whosuccessfullycomplete eachtraining course orother approvedtraining activity

are kept. (L3-34, A6, 1)

Records of allstudents whosuccessfullycomplete theirdesignated requiredtraining

are kept. (L3-34, A6, 2)

Records ofsuccessfullycompleted training

are made available for considerationin assignments of the staff andmanagers. (L3-34, A6, 3)

Records of training ortraining records

are properly maintained. (L3-36, V3,3)




The CMM recommends that outputs satisfy the states described in the table belowto exit the training program process, continued from the previous page.


Results of reviewsand/or audits of thetraining programactivities and workproducts


Specific training tobe provided

is identified based on the skillsneeded by the organization and whenthose skills are needed. (L3-30, A2,2)

Training coursesprepared at theorganization level

q are developed according toorganization standards. (L3-33,A4)

q are maintained according toorganization standards. (L3-33,A4)

Training plan (foreach softwareproject)

q is developed. (L3-29, A1)

q is maintained. (L3-29, A1)

q specifies the software project’straining needs. (L3-29, A1)

Training programwork products

q are reviewed. (L3-36, V3)

q are audited. (L3-36, V3)

Training vehicles forimparting skills andknowledge

q are identified. (L3-26, C1, 2)

q are approved. (L3-26, C1, 2)

Waiver procedure forrequired training

q is established. (L3-34, A5)

q is used to determine whetherindividuals already possess theknowledge and skills required toperform in their designated roles.(L3-34, A5)




The CMM recommends that the conditions described in the table below besatisfied to exit the training program process.


The training for the organization is performed in accordancewith the organization's training plan. (L3-32, A3)

The training program activities are reviewed with seniormanagement on a periodic basis. (L3-35, V1)

The training program is independently evaluated on aperiodic basis for consistency with, and relevance to, theorganization's needs. (L3-36, V2)

The training program activities and work products arereviewed and/or audited and the results are reported. (L3-36, V3)


TP Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the trainingprogram process.


References

The organization's training plan isreviewed by the affected individualswhen it is initially released and whenevermajor revisions are made. (L3-31, A2, 4)

Affectedindividuals

The materials for the training course arereviewed. (L3-33, A4, 2)


The training program activities arereviewed with senior management on aperiodic basis. (L3-35, V1)

Seniormanagement

The training program is independentlyevaluated on a periodic basis forconsistency with, and relevance to, theorganization's needs. (L3-36, V2)


The training program activities and workproducts are reviewed and/or audited andthe results are reported. (L3-36, V3)

At a minimum, the reviews and/or auditsverify that:

q The process for developing andrevising the organization's training planis followed.

q The process for developing andrevising a training course is followed.

q Training records are properlymaintained.

q Individuals designated as requiringspecific training complete that training.

q The organization's training plan isfollowed.



TP Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the training program process.


The organization's training plan. (L3-31, A2, 5)

The materials for the training courses. (L3-34, A4, 3)


TP Process - Measurements

Measurements The table below lists the measurements recommended for the training programprocess.


Measurements to determine the status of the trainingprogram activities. (L3-34, M1)


q Actual attendance at each training course compared tothe projected attendance.

q Progress in providing training courses compared to theorganization’s and projects’ training plans.

q Number of training waivers approved over time.

Measurements to determine the quality of the trainingprogram. (L3-35, M2)


q Results of post-training tests.

q Reviews of the courses from the students.

q Feedback from the software managers.


TP Process - Documented Procedures


The table below lists the activities for the training program process recommendedto be performed according to a documented procedure.





TP Process - T ra in ing

Training The table below lists the training recommended for the training program process.

Training References

Software managers receive orientation on the trainingprogram. (L3-29, Ab4)


TP Process - Too ls

Tools The table below lists the tools recommended for the training program process.

Tools References

Tools to support the training program activities. (L3-28,Ab2, 2)


q workstations,

q instructional design tools,


q packages for developing presentation materials.


In tegrated Sof tware Management ( ISM) Process

I S M P r o c e s s - O v e r v i e w

The purpose of Integrated Software Management is to integrate the softwareengineering and management activities into a coherent, defined software processthat is tailored from the organization's standard software process and relatedprocess assets, which are described in Organization Process Definition. (L3-37)

ISM processpurpose

Integrated Software Management involves developing the project's definedsoftware process and managing the software project using this defined softwareprocess. The project's defined software process is tailored from the organization'sstandard software process to address the specific characteristics of the project.

The software development plan is based on the project's defined software processand describes how the activities of the project's defined software process will beimplemented and managed. The management of the software project's size,effort, cost, schedule, staffing, and other resources is tied to the tasks of theproject's defined software process.

Since the projects' defined software processes are all tailored from theorganization's standard software process, the software projects can share processdata and lessons learned.

The basic practices for estimating, planning, and tracking a software project aredescribed in the Software Project Planning and Software Project Tracking andOversight key process areas. They focus on recognizing problems when theyoccur and adjusting the plans and/or performance to address the problems. Thepractices of this key process area build on, and are in addition to, the practices ofthose two key process areas. The emphasis of Integrated Software Managementshifts to anticipating problems and acting to prevent or minimize the effects ofthese problems. (L3-37)

ISM processdescription



I S M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L3-Process-69



L3-Process-73


L3-Process-75


L3-Process-78


L3-Process-83

Reviews andAudits




L3-Process-98




L3-Process-100




ISM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in theintegrated software management process.


Affectedgroups

The software engineering group and otheraffected groups and individuals areincluded in the communications on thesoftware risks, the software riskmanagement plans, and the results of riskmitigation. (L3-55, A10, 7)

Affectedindividuals

The software engineering group and otheraffected groups and individuals areincluded in the communications on thesoftware risks, the software riskmanagement plans, and the results of riskmitigation. (L3-55, A10, 7)

Customer Waivers for deviations from contractualsoftware process requirements aredocumented and are reviewed andapproved by senior management and thesoftware project's customer, asappropriate. (L3-42, A1, 4)

Groupresponsibleforcoordinatingtheorganization'ssoftwareprocessactivities (e.g.,softwareengineeringprocessgroup)

Tailoring of the organization's standardsoftware process for the project is reviewedby the group responsible forcoordinating the organization's softwareprocess activities (e.g., softwareengineering process group) and approvedby senior management. (L3-42, A1, 3)

Group that isindependentof the softwareengineeringgroup

A group that is independent of thesoftware engineering group reviews theprocedures for estimating the size of thesoftware work products, and providesguidance in using historical data from theorganization's software process database toestablish credible estimates. (L3-47, A6,1)


Individualswho preparethe sizeestimates

The individuals who prepare the sizeestimates ensure that the procedures anddata used in the estimates are appropriate.(L3-48, A6, 1.1)



I S M P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theintegrated software management process, continued from the previous page.


Individualsresponsiblefor developingthe project'sdefinedsoftwareprocess

The individuals responsible fordeveloping the project's definedsoftware process receive required trainingin how to tailor the organization's standardsoftware process and use the relatedprocess assets. (L3-39, Ab2)

Projectmanager

The activities for managing the softwareproject are reviewed with the projectmanager on both a periodic and event-driven basis. (L3-57, V2)

Seniormanagement

q Tailoring of the organization's standardsoftware process for the project isreviewed by the group responsible forcoordinating the organization's softwareprocess activities (e.g., softwareengineering process group) andapproved by senior management.(L3-42, A1, 3)

q Waivers for deviations from theorganization's standard softwareprocess are documented and arereviewed and approved by seniormanagement. (L3-42, A1, 3.1)

q Waivers for deviations from contractualsoftware process requirements aredocumented and are reviewed andapproved by senior management andthe software project's customer, asappropriate. (L3-42, A1, 4)

q The activities for managing thesoftware project are reviewed withsenior management on a periodicbasis. (L3-56, V1)


The software engineering group andother affected groups and individuals areincluded in the communications on thesoftware risks, the software riskmanagement plans, and the results of riskmitigation. (L3-55, A10, 7)


I S M P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theintegrated software management process, continued from the previous page.


Softwaremanager

The software managers receive requiredtraining in managing the technical,administrative, and personnel aspects ofthe software project based on the project'sdefined software process. (L3-40, Ab3)

Softwarequalityassurance(SQA) group

The software quality assurance groupreviews and/or audits the activities andwork products for managing the softwareproject and reports the results. (L3-57, V3)

Team of peersand experts

When the validity of a size estimate isquestioned, a team of peers and expertsreviews the estimate. (L3-48, A6, 1.2)


ISM Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the integrated software management process.


Available capacityfor the criticalcomputer resources

provides for a specified reservecapacity when the initial estimatesare made. (L3-51, A8, 4)

Software effort, cost,and staffing profilemodels

q if used, are adapted to theproject. (L3-49, A7, 1)

q use available historical datawhere appropriate. (L3-49, A7,1)

Software schedule identifies specific tasks andmilestones whose completion can beobjectively determined (i.e., a binaryor yes/no determination). (L3-51,A9, 1.1)

The CMM recommends that the conditions described in the table below besatisfied before entering the integrated software management process.



The project follows a written organizational policy requiringthat the software project be planned and managed using theorganization's standard software process and related processassets. (L3-38, C1)

Adequate resources and funding are provided for managingthe software project using the project's defined softwareprocess. (L3-39, Ab1)

The individuals responsible for developing the project'sdefined software process receive required training in howto tailor the organization's standard software process and usethe related process assets. (L3-39, Ab2)

The software managers receive required training inmanaging the technical, administrative, and personnelaspects of the software project based on the project'sdefined software process. (L3-40, Ab3)


ISM Process - Inputs

Inputs The table below lists the recommended inputs to the integrated softwaremanagement process.


Actual data on project productivity andother new software costs. (L3-50, A7, 4.2)

Available capacity for the criticalcomputer resources. (L3-51, A8, 4)

Available computer resources. (L3-50, A8,3)

Available historical data. (L3-49, A7, 1)

Changes proposed by the software project(to the project’s defined software process).(L3-43, A2, 1.2)

Critical dependencies of the project'ssoftware schedule. (L3-51, A9)

Critical paths of the project's softwareschedule. (L3-51, A9)

Data for similar software projects. (L3-46,A5, 1)

Historical data from the organization'ssoftware process database. (L3-47, A6, 1)

Historical experience, simulations,prototyping, or analysis. (L3-50, A8, 1)

Lessons learned (management) frommonitoring the activities of other projectsin the organization. (L3-45, A4, 6)

Lessons learned (technical) frommonitoring the activities of other projectsin the organization. (L3-45, A4, 6)

Lessons learned from monitoring thesoftware activities of the organization’sprojects. (L3-43, A2, 1.1)

Organization's library of software process-related documentation. (L3-45, A4, 5)

Organization's software process database.(L3-39, C1, 4)

Organization's standard software process.(L3-38, C1)



ISM Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the integrated softwaremanagement process, continued from the previous page.


Organization's standards. (L3-41, A1, 1.3)

Organization's tailoring guidelines andcriteria (for the organization’s standardsoftware process). (L3-41, A1, 1.2)

Planned computer resources. (L3-50, A8,2)

Process and work product measurementdata. (L3-43, A2, 1.3)

Project's contractual and operationalconstraints. (L3-41, A1, 1.1)

Project's critical computer resourcerequirements. (L3-50, A8, 2)

Project's critical computer resources. (L3-50, A8)

Project's defined software process. (L3-39,C1, 3)


Project's software risks. (L3-52, A10)

Related process assets. (L3-38, C1)

Risk priorities. (L3-55, A10, 6.1)

Software design. (L3-50, A8, 2)

Software effort, cost, and staffing profilemodels. (L3-49, A7, 1)

Software requirements. (L3-50, A8, 2)

Software risk management plan. (L3-53,A10, 1)

Software schedule. (L3-51, A9, 1.1)

Specific needs of the software project.(L3-45, A4, 8)

System requirements allocated to software.(L3-50, A8, 2)


ISM Process - Act iv i t ies

Activities The table below lists the required activities for the integrated softwaremanagement process.


The project's defined software process is developed bytailoring the organization's standard software processaccording to a documented procedure. (L3-41, A1)


Each project's defined software process is revised accordingto a documented procedure. (L3-43, A2)


The project's software development plan, which describesthe use of the project's defined software process, isdeveloped and revised according to a documentedprocedure. (L3-44, A3)

The software project is managed in accordance with theproject's defined software process. (L3-44, A4)

[Refer to Level 3 Standards for additional informationregarding the project's defined software process.]

The organization's software process database is used forsoftware planning and estimating. (L3-46, A5)

q The database is used as a source of data to estimate,plan, track, and replan a software project; data forsimilar software projects are used when possible.

q Parameter values used to derive estimates for softwaresize, effort, cost, schedule, and use of critical computerresources are compared to those of other softwareprojects to assess their validity.

q Similarities and differences to the other projects interms of application domain and design approachare assessed and recorded.

q Rationales for similarities and differences betweenthe parameter values are recorded.

q The reasoning used to judge the credibility of theproject's estimates is recorded.

q The software project provides appropriate softwareplanning data, replanning data, and actual measureddata for storage in the organization's software processdatabase.


ISM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the integrated softwaremanagement process, continued from the previous page.


The size of the software work products (or size of changesto the software work products) is managed according to adocumented procedure. (L3-47, A6)


The project's software effort and costs are managedaccording to a documented procedure. (L3-48, A7)


The project's critical computer resources are managedaccording to a documented procedure. (L3-50, A8)


The critical dependencies and critical paths of the project'ssoftware schedule are managed according to a documentedprocedure. (L3-51, A9)


The project's software risks are identified, assessed,documented, and managed according to a documentedprocedure. (L3-52, A10)


Reviews of the software project are periodically performedto determine the actions needed to bring the softwareproject's performance and results in line with the current andprojected needs of the business, customer, and end users, asappropriate. (L3-55, A11)

Measurements are made and used to determine theeffectiveness of the integrated software managementactivities. (L3-56, M1)

The activities for managing the software project arereviewed with senior management on a periodic basis.(L3-56, V1)



ISM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the integrated softwaremanagement process, continued from the previous page.


The activities for managing the software project arereviewed with the project manager on both a periodic andevent-driven basis. (L3-57, V2)

The software quality assurance group reviews and/oraudits the activities and work products for managing thesoftware project and reports the results. (L3-57, V3)

[Refer to ISM Process Reviews and Audits for additionalinformation.]


ISM Process - Outputs

Outputs The table below lists the outputs produced by the integrated software managementprocess.


Actions needed to bring the softwareproject's performance and results in linewith the current and projected needs of thebusiness, customer, and end users. (L3-55,A11)

Actual expenditures over time and againstwork completed. (L3-49, A7, 4)

Actual measured data (from the softwareproject). (L3-47, A5, 3)

Alternatives for each software risk. (L3-54, A10, 3)

Changes to the project's defined softwareprocess derived from changes proposed bythe software project. (L3-43, A2, 1.2)

Changes to the project's defined softwareprocess derived from lessons learned frommonitoring the software activities of theorganization's projects. (L3-43, A2, 1.1)

Changes to the project's defined softwareprocess derived from process and workproduct measurement data. (L3-43, A2,1.3)

Changes to the project's defined softwareprocess. (L3-43, A2, 2)


Completion criteria (for key tasks). (L3-44, A4, 3)

Contingency factor applied to the sizeestimate (of the software work product) foreach software element identified as asoftware risk. (L3-48, A6, 2)

Costs. (L3-51, A9, 1)

Criteria for selecting among thealternatives for each software risk. (L3-54,A10, 3)

Critical dependencies (of the project’ssoftware schedule). (L3-51, A9, 2)


Description of the project's definedsoftware process. (L3-41, A1, 2)



ISM Process - Outputs , Continued

Outputs,continued

The table below lists the outputs produced by the integrated software managementprocess, continued from the previous page.


Documented criteria to indicate when toreplan the software project. (L3-45, A4, 4)

Effort and cost threshold for eachindividually managed software task orstage. (L3-50, A7, 5)

Effort to modify and incorporate reusablecomponents. (L3-48, A6, 3.2)

Estimates for the project's criticalcomputer resources. (L3-50, A8, 1)

Factors which could significantly affectthe size of the software work products.(L3-48, A6, 4)

Information obtained from monitoring the(software) risks. (L3-55, A10, 6.2)

Initial release of the software riskmanagement plan. (L3-54, A10, 4)

Lessons learned (management). (L3-45,A4, 5)

Lessons learned (technical). (L3-45, A4,5)

Lessons learned from monitoring thesoftware activities of the organization’sprojects. (L3-43, A2, 1.1)

Major revisions to the software riskmanagement plan. (L3-54, A10, 4)

Measurement data needed to manage thesoftware project. (L3-44, A4, 1)

Measurements (to determine theeffectiveness of the integrated softwaremanagement activities). (L3-56, M1)

Milestones. (L3-51, A9, 1)

Organization's software process database.(L3-46, A5)

Overall software effort and cost. (L3-49,A7, 3)


Parameter values of the models used inestimating software effort and costs. (L3-50, A7, 4.1)




Outputs,continued



Parameter values used to derive estimatesfor software size, effort, cost, schedule,and use of critical computer resources.(L3-46, A5, 2)

Productivity and cost data. (L3-49, A7, 2)

Project measurement data. (L3-39, C1, 4)


Project's deviations from the organization'sstandard software process. (L3-39, C1, 2)

Project's software costs. (L3-48, A7)


Project's software effort. (L3-48, A7)

Project's software risks. (L3-52, A10)

Rationale for the contingency (for eachsoftware element identified as a softwarerisk). (L3-48, A6, 2.1)

Rationales for similarities and differencesbetween the parameter values (used toderive estimates for software size, effort,cost, schedule, and use of criticalcomputer resources). (L3-46, A5, 2.2)

Readiness criteria (for key tasks). (L3-44,A4, 3)

Reasoning used to judge the credibility ofthe estimates for the project’s criticalcomputer resources. (L3-50, A8, 1.3)

Reasoning used to judge the credibility ofthe project's estimates (for software size,effort, cost, schedule, and use of criticalcomputer resources). (L3-47, A5, 2.3)

Replanning data (from the softwareproject). (L3-47, A5, 3)

Results of software quality assurancereviews and/or audits of software projectactivities and work products. (L3-57, V3)


Reuse measurements. (L3-48, A6, 3.1)




Outputs,continued



Risks associated with reducing oreliminating the contingency (for eachsoftware element identified as a softwarerisk). (L3-48, A6, 2.2)

Schedule critical paths. (L3-52, A9, 3)

Similarities and differences between theproject and the sources for historical datain terms of application domain and designapproach. (L3-50, A8, 1.2)

Similarities and differences to the otherprojects in terms of application domainand design approach. (L3-46, A5, 2.1)

Size estimates. (L3-48, A6, 1.1)

Size of changes to the software workproducts. (L3-47, A6)

Size of the software work products. (L3-47, A6)

Size threshold for each managed softwareelement. (L3-48, A6, 5)

Software effort and cost status. (L3-49,A7, 4)

Software life cycle. (L3-41, A1, 1)

Software planning data (from the softwareproject). (L3-47, A5, 3)

Software plans followed in interacting withother groups. (L3-45, A4, 9)

Software risk management plan. (L3-53,A10, 1)

Software schedule. (L3-51, A9, 1.1)

Sources and rationale for estimates (for theproject's critical computer resources). (L3-50, A8, 1.1)

Staffing plan. (L3-45, A4, 7)

Staffing. (L3-51, A9, 1)

Threshold criteria for each critical path.(L3-52, A9, 5)


Threshold for each critical computerresource. (L3-51, A8, 5)




Outputs,continued



Training needs. (L3-45, A4, 8)

Waivers for deviations from contractualsoftware process requirements. (L3-42,A1, 4)

Waivers for deviations from theorganization's standard software process.(L3-42, A1, 3.1)

Work products of the project's definedsoftware process. (L3-44, A4, 2)


ISM Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the integrated software management process.


Actions needed tobring the softwareproject's performanceand results in linewith the current andprojected needs ofthe business,customer, and endusers

are determined by periodic reviewsof the software project. (L3-55, A11)

Actual measureddata (from thesoftware project)

are provided for storage in theorganization's software processdatabase (L3-47, A5, 3)

Alternatives for eachsoftware risk

are defined. (L3-54, A10, 3)

Changes to theproject's definedsoftware process


q are approved before they areincorporated. (L3-43, A2, 2)

Changes to theproject's definedsoftware processderived from changesproposed by thesoftware project

q are documented. (L3-43, A2,1.2)

q are systematically reviewed.(L3-43, A2, 1.2)

Changes to theproject's definedsoftware processderived from lessonslearned frommonitoring thesoftware activities ofthe organization'sprojects



Changes to theproject's definedsoftware processderived from processand work productmeasurement data



Commitments are allocated in the scheduleconsistent with the project's definedsoftware process. (L3-51, A9, 1)


ISM Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the integrated software management process, continued from the previouspage.


Completion criteria q are established. (L3-44, A4, 3)


q are used to determinecompletion of key tasks. (L3-44,A4, 3)

Contingency factorapplied to the sizeestimate

is applied to the size estimate foreach software element identified asa software risk. (L3-48, A6, 2)

Costs are allocated in the scheduleconsistent with the project's definedsoftware process. (L3-51, A9, 1)

Criteria for selectingamong thealternatives for eachsoftware risk


Criticaldependencies (of theproject’s softwareschedule)

q are managed according to adocumented procedure. (L3-51,A9)

q are allocated in the scheduleconsistent with the project'sdefined software process. (L3-51, A9, 1)

q are defined. (L3-51, A9, 2)

q are negotiated. (L3-51, A9, 2)

q are reflected in the softwareschedule. (L3-51, A9, 2)

Description of theproject's definedsoftware process



Documented criteriato indicate when toreplan the softwareproject








Effort and costthreshold for eachindividually managedsoftware task or stage

q is established. (L3-50, A7, 5)

q requires action when projected tobe exceeded. (L3-50, A7, 5)

Effort to modify andincorporate reusablecomponents

is factored into the size estimates.(L3-48, A6, 3.2)

Estimates for theproject's criticalcomputer resources

are derived based on historicalexperience, simulations, prototyping,or analysis, as appropriate. (L3-50,A8, 1)

Factors which couldsignificantly affectthe size of thesoftware workproducts


q are monitored closely. (L3-48,A6, 4)

Information obtainedfrom monitoring the(software) risks

is used to refine the risk assessmentsand software risk management plans.(L3-55, A10, 6.2)

Initial release of thesoftware riskmanagement plan

undergoes peer review. (L3-54, A10,4)

Lessons learned(management)


q are stored in the organization'slibrary of software process-related documentation. (L3-45,A4, 5)

Lessons learned(technical)


q are stored in the organization'slibrary of software process-related documentation. (L3-45,A4, 5)

Major revisions tothe software riskmanagement plan

undergo peer review. (L3-54, A10,4)


Measurement dataneeded to managethe software project

q are gathered. (L3-44, A4, 1)


q are reported. (L3-44, A4, 1)







Measurements (todetermine theeffectiveness of theintegrated softwaremanagementactivities)



Milestones are allocated in the scheduleconsistent with the project's definedsoftware process. (L3-51, A9, 1)

Organization'ssoftware processdatabase

q is used for software planning.(L3-46, A5)

q is used for software estimating.(L3-46, A5)

Overall softwareeffort and cost

is allocated to individually managedtasks or stages as needed to managethe effort and cost effectively. (L3-49, A7, 3)

Parameter values ofthe models used inestimating softwareeffort and costs

are updated whenever major changesare made to the softwarerequirements. (L3-50, A7, 4.1)

Parameter valuesused to deriveestimates forsoftware size, effort,cost, schedule, anduse of criticalcomputer resources

are compared to those of othersoftware projects to assess theirvalidity. (L3-46, A5, 2)

Productivity and costdata

are adjusted to incorporate projectvariables. (L3-49, A7, 2)

Project measurementdata

q are collected by each project.(L3-39, C1, 4)

q are stored by each project in theorganization's software processdatabase. (L3-39, C1, 4)







Project's definedsoftware process

q is documented by each projectby tailoring the organization'sstandard software process. (L3-39, C1, 1)

q is developed by tailoring theorganization's standard softwareprocess according to adocumented procedure. (L3-41,A1)


Project's deviationsfrom theorganization'sstandard softwareprocess


q are approved. (L3-39, C1, 2)

Project's softwarecosts

are managed according to adocumented procedure. (L3-48, A7)




Project's softwareeffort

is managed according to adocumented procedure. (L3-48, A7)







Project's softwarerisks or software risks

q are identified according to adocumented procedure. (L3-52,A10)

q are assessed according to adocumented procedure. (L3-52,A10)

q are documented according to adocumented procedure. (L3-52,A10)

q are managed according to adocumented procedure. (L3-52,A10)

q are tracked. (L3-55, A10, 6)

q are reassessed at selectedproject milestones, at designatedrisk checkpoints, and during theplanning of significant changesthat affect the software project.(L3-55, A10, 6)

q are replanned at selected projectmilestones, at designated riskcheckpoints, and during theplanning of significant changesthat affect the software project.(L3-55, A10, 6)

Rationale for thecontingency (foreach softwareelement identified asa software risk)

is documented. (L3-48, A6, 2.1)

Rationales forsimilarities anddifferences betweenthe parameter values(used to deriveestimates forsoftware size, effort,cost, schedule, anduse of criticalcomputer resources)

are recorded. (L3-46, A5, 2.2)






Readiness criteria q are established. (L3-44, A4, 3)


q are used to authorize initiation ofkey tasks. (L3-44, A4, 3)

Reasoning used tojudge the credibilityof the estimates forthe project’s criticalcomputer resources

is recorded. (L3-50, A8, 1.3)

Reasoning used tojudge the credibilityof the project'sestimates (forsoftware size, effort,cost, schedule, anduse of criticalcomputer resources)

is recorded. (L3-47, A5, 2.3)

Replanning data(from the softwareproject)

are provided for storage in theorganization's software processdatabase. (L3-47, A5, 3)

Reuse measurements account for the reuse ofrequirements, design, code, testplan, and test procedures, etc. (L3-48, A6, 3.1)

Risks associated withreducing oreliminating thecontingency (foreach softwareelement identified asa software risk)

q are assessed. (L3-48, A6, 2.2)


Schedule criticalpaths


q are reflected in the softwareschedule. (L3-52, A9, 3)







Similarities anddifferences betweenthe project and thesources for historicaldata in terms ofapplication domainand design approach


q are recorded. (L3-50, A8, 1.2)

Similarities anddifferences to theother projects interms of applicationdomain and designapproach


q are recorded. (L3-46, A5, 2.1)

Size estimates are prepared using appropriateprocedures and data. (L3-48, A6,1.1)

Size of changes tothe software workproducts


Size of the softwarework products


Size threshold foreach managedsoftware element



Software life cycle q is selected from among thoseapproved by the organization, tosatisfy the project's contractualand operational constraints. (L3-41, A1, 1.1)

q is modified, if necessary, inways permitted by theorganization's tailoringguidelines and criteria. (L3-41,A1, 1.2)

q is documented according to theorganization's standards. (L3-41,A1, 1.3)


Software planningdata (from thesoftware project)

are provided for storage in theorganization's software processdatabase. (L3-47, A5, 3)







Software plansfollowed ininteracting with othergroups

are adjusted to account fordisparities with these groups and forother potential problems. (L3-45,A4, 9)

Software riskmanagement plan


q is used to identify and managethe software risks. (L3-53, A10,1)


q is reviewed at reassessmentcheckpoints (i.e., at selectedproject milestones, at designatedrisk checkpoints, and during theplanning of significant changesthat affect the software project).(L3-55, A10, 6.1)

q is revised at reassessmentcheckpoints (i.e., at selectedproject milestones, at designatedrisk checkpoints, and during theplanning of significant changesthat affect the software project).(L3-55, A10, 6.1)

Software schedule identifies specific tasks andmilestones whose completion can beobjectively determined (i.e., a binaryor yes/no determination). (L3-51,A9, 1.1)

Sources and rationalefor estimates (for theproject's criticalcomputer resources)

are documented. (L3-50, A8, 1.1)

Staffing is allocated in the scheduleconsistent with the project's definedsoftware process. (L3-51, A9, 1)


Staffing plan addresses the software project'sneeds for individuals with specialskills and application domainknowledge. (L3-45, A4, 7)







Threshold criteria foreach critical path


q are established. (L3-52, A9, 5)

q require action when projected tobe exceeded. (L3-52, A9, 5)

Threshold for eachcritical computerresource



Training needs q are identified. (L3-45, A4, 8)

q are documented to fit thespecific needs of the softwareproject. (L3-45, A4, 8)

Waivers fordeviations fromcontractual softwareprocess requirements


q are reviewed by seniormanagement and the softwareproject's customer, asappropriate. (L3-42, A1, 4)

q are approved by seniormanagement and the softwareproject's customer, asappropriate. (L3-42, A1, 4)

Waivers fordeviations from theorganization'sstandard softwareprocess


q are reviewed by seniormanagement. (L3-42, A1, 3.1)

q are approved by seniormanagement. (L3-42, A1, 3.1)

Work products of theproject's definedsoftware process

are tied to the software estimating,planning, and tracking activities.(L3-44, A4, 2)

The CMM recommends that the conditions described in the table below besatisfied to exit the integrated software management process.

General ExitCriteria



Each project performs its software activities in accordancewith the project's defined software process. (L3-39, C1, 3)





The table below describes the conditions that must be satisfied in order to exit theintegrated software management process, continued from the previous page.



Tailoring of the organization's standard software process forthe project is reviewed by the group responsible forcoordinating the organization's software processactivities (e.g., software engineering process group) andapproved by senior management. (L3-42, A1, 3)

The software project is managed in accordance with theproject's defined software process. (L3-44, A4)

Technical and management lessons learned from monitoringthe activities of other projects in the organization aresystematically reviewed and used to estimate, plan, track,and replan the software project. (L3-45, A4, 6)

The organization's software process database is used as asource of data to estimate, plan, track, and replan asoftware project; data for similar software projects are usedwhen possible. (L3-46, A5, 1)

When the software effort and cost status is reviewed and theestimates are revised, actual expenditures over time andagainst work completed are compared to the softwaredevelopment plan and used to refine the effort and costestimates for remaining work. (L3-49, A7, 4)

Actual data on project productivity and other new softwarecosts are used where appropriate. (L3-50, A7, 4.2)


The planned computer resources, the system requirementsallocated to software, the software requirements, and/or thesoftware design are adjusted to achieve the project's criticalcomputer resource requirements. (L3-50, A8, 2)

The available computer resources are allocated to thesoftware components. (L3-50, A8, 3)


The software project's critical dependencies and schedulecritical paths are tracked on a regular basis. (L3-52, A9, 4)


Contingency planning is based on the project's definedsoftware process and is performed throughout the project'ssoftware life cycle. (L3-54, A10, 2)





The table below describes the conditions that must be satisfied in order to exit theintegrated software management process, continued from the previous page.


The software engineering group and other affectedgroups and individuals are included in thecommunications on the software risks, the software riskmanagement plans, and the results of risk mitigation. (L3-55, A10, 7)

Reviews of the software project are periodically performedto determine the actions needed to bring the softwareproject's performance and results in line with the current andprojected needs of the business, customer, and end users, asappropriate. (L3-55, A11)

The activities for managing the software project arereviewed with senior management on a periodic basis.(L3-56, V1)

The activities for managing the software project arereviewed with the project manager on both a periodic andevent-driven basis. (L3-57, V2)

The software quality assurance group reviews and/oraudits the activities and work products for managing thesoftware project and reports the results. (L3-57, V3)


ISM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the integratedsoftware management process.


References

Tailoring of the organization's standardsoftware process for the project is reviewedby the group responsible forcoordinating the organization's softwareprocess activities (e.g., softwareengineering process group) andapproved by senior management. (L3-42,A1, 3)

Groupresponsibleforcoordinatingtheorganization'ssoftwareprocessactivities

Seniormanagement

Waivers for deviations from theorganization's standard software processare documented and are reviewed andapproved by senior management. (L3-42,A1, 3.1)

Seniormanagement

Waivers for deviations from contractualsoftware process requirements aredocumented and are reviewed andapproved by senior management and thesoftware project's customer, asappropriate. (L3-42, A1, 4)

Seniormanagement

Customer

Changes derived from the following aredocumented and systematically reviewed:(L3-43, A2, 1)

q Lessons learned from monitoring thesoftware activities of the organization'sprojects.

q Changes proposed by the softwareproject.

q Process and work product measurementdata.


Changes to the project's defined softwareprocess are reviewed and approved beforethey are incorporated. (L3-43, A2, 2)



Technical and management lessonslearned from monitoring the activities ofother projects in the organization aresystematically reviewed and used toestimate, plan, track, and replan thesoftware project. (L3-45, A4, 6)




ISM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the integratedsoftware management process, continued from the previous page.


References

A group that is independent of thesoftware engineering group reviews theprocedures for estimating the size of thesoftware work products, and providesguidance in using historical data from theorganization's software process database toestablish credible estimates. (L3-47, A6,1)

Group that isindependentof the softwareengineeringgroup

When the validity of a size estimate isquestioned, a team of peers and expertsreviews the estimate. (L3-48, A6, 1.2)

Team of peersand experts

When the software effort and cost status isreviewed and the estimates are revised,actual expenditures over time and againstwork completed are compared to thesoftware development plan and used torefine the effort and cost estimates forremaining work. (L3-49, A7, 4)


The initial release and major revisions tothe software risk management planundergo peer review. (L3-54, A10, 4)


Risk priorities and software riskmanagement plans are reviewed andrevised at these reassessment points (i.e.,at selected project milestones, atdesignated risk checkpoints, and during theplanning of significant changes that affectthe software project). (L3-55, A10, 6.1)


Reviews of the software project areperiodically performed to determine theactions needed to bring the softwareproject's performance and results in linewith the current and projected needs of thebusiness, customer, and end users, asappropriate. (L3-55, A11)


The activities for managing the softwareproject are reviewed with seniormanagement on a periodic basis. (L3-56,V1)

Seniormanagement


The activities for managing the softwareproject are reviewed with the projectmanager on both a periodic and event-driven basis. (L3-57, V2)

Projectmanager



ISM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the integratedsoftware management process, continued from the previous page.


References

The software quality assurance groupreviews and/or audits the activities andwork products for managing the softwareproject and reports the results. (L3-57, V3)


q The process for developing andrevising the project's defined softwareprocess.

q The process for preparing the project'ssoftware development plan andsoftware risk management plan.

q The processes for managing the projectin accordance with the project'sdefined software process.

q The processes for collecting andproviding appropriate data to theorganization's software processdatabase.

q The process for using the organization'ssoftware process database to supportthe software project's planning,estimating, and tracking activities.

SQA group


ISM Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the integrated software management process.


Description of the project's defined software process. (L3-42, A1, 5)

Software risk management plan. (L3-54, A10, 5)


ISM Process - Measurements

Measurements The table below lists the recommended measurements for the integrated softwaremanagement process.


Project measurement data. (L3-39, C1, 4)

Process and work product measurement data. (L3-43, A2,1.3)

Measurement data needed to manage the software project.(L3-44, A4, 1)

Software planning data, replanning data, and actualmeasured data. (L3-47, A5, 3)

Reuse measurements (reuse of requirements, design, code,test plan, and test procedures, etc.). (L3-48, A6, 3.1)

Measurements to determine the effectiveness of theintegrated software management activities. (L3-56, M1)


q Effort expended over time to manage the softwareproject, compared to the plan.

q Frequency, causes, and magnitude of replanning effort.

q For each identified software risk, the realized adverseimpact compared to the estimated loss.

q The number and magnitude of unanticipated majoradverse impacts to the software project, tracked overtime.


ISM Process - Documented Procedures


The table below lists the activities for the integrated software managementprocess recommended to be performed according to a documented procedure.


















ISM Process - T ra in ing

Training The table below lists the training recommended for the integrated softwaremanagement process.

Training References

The individuals responsible for developing the project'sdefined software process receive required training in how totailor the organization's standard software process and usethe related process assets. (L3-39, Ab2)

The software managers receive required training inmanaging the technical, administrative, and personnelaspects of the software project based on the project'sdefined software process. (L3-40, Ab3)


ISM Process - Too ls

Tools The table below lists the tools recommended for the integrated softwaremanagement process.

Tools References

Organization's software process database. (L3-39, C1, 4)


Sof tware Product Engineer ing (SPE) Process

SPE Process - Overv iew

The purpose of Software Product Engineering is to consistently perform a well-defined engineering process that integrates all the software engineering activitiesto produce correct, consistent software products effectively and efficiently. (L3-59)

SPE processpurpose

Software Product Engineering involves performing the engineering tasks to buildand maintain the software using the project's defined software process (which isdescribed in the Integrated Software Management key process area) andappropriate methods and tools.

The software engineering tasks include analyzing the system requirementsallocated to software (these system requirements are described in theRequirements Management key process area), developing the softwarerequirements, developing the software architecture, designing the software,implementing the software in the code, integrating the software components, andtesting the software to verify that it satisfies the specified requirements (i.e., thesystem requirements allocated to software and the software requirements).

Documentation needed to perform the software engineering tasks (e.g., softwarerequirements document, software design document, test plan, and test procedures)is developed and reviewed to ensure that each task addresses the results ofpredecessor tasks and the results produced are appropriate for the subsequent tasks(including the tasks of operating and maintaining the software). When changesare approved, affected software work products, plans, commitments, processes,and activities are revised to reflect the approved changes. (L3-59)

SPE processdescription



S P E P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L3-Process-105



L3-Process-112


L3-Process-114


L3-Process-123


L3-Process-126

Reviews andAudits




L3-Process-144




L3-Process-146




SPE Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware product engineering process.


Affectedgroups

Changes (to the software work products,plans, process descriptions, and activities)are negotiated with and communicated tothe affected groups. (L3-79, A10, 4.4)

Customer q The software requirements document isreviewed with the customer and endusers, as appropriate. (L3-68, A2, 10)

q Testing criteria are developed andreviewed with the customer and theend users, as appropriate. (L3-72, A5,1)

q System and acceptance testing aredocumented in a test plan, which isreviewed with, and approved by, thecustomer and end users, asappropriate. (L3-75, A7, 2)

q The test cases are documented and arereviewed with, and approved by, thecustomer and end users, asappropriate, before the testing begins.(L3-76, A7, 4)

q Preliminary versions of thedocumentation are developed andmade available early in the softwarelife cycle for the customer, end users,and software maintainers, asappropriate, to review and providefeedback. (L3-77, A8, 3)

q The final documentation is reviewedand approved by the customer, endusers, and software maintainers, asappropriate. (L3-77, A8, 7)

Documenta-tion specialist

Documentation specialists activelyparticipate in planning, developing, andmaintaining documentation. (L3-77, A8,2)



SPE Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware product engineering process, continued from the previous page.


End users q The software requirements document isreviewed with the customer and endusers, as appropriate. (L3-68, A2, 10)

q Testing criteria are developed andreviewed with the customer and theend users, as appropriate. (L3-72, A5,1)

q System and acceptance testing aredocumented in a test plan, which isreviewed with, and approved by, thecustomer and end users, asappropriate. (L3-75, A7, 2)

q The test cases are documented and arereviewed with, and approved by, thecustomer and end users, asappropriate, before the testing begins.(L3-76, A7, 4)



Groupresponsiblefor the systemrequirements

Problems with the software requirementsare identified and reviewed with the groupresponsible for the systemrequirements; appropriate changes aremade to the allocated requirements and tothe software requirements. (L3-67, A2,4.1)

Groupresponsiblefor systemandacceptancetesting

The group responsible for system andacceptance testing of the softwareanalyzes each software requirement toverify it can be tested. (L3-67, A2, 6)



Roles,continued



Individuals Skilled individuals are available toperform the different software engineeringtasks, including: (L3-61, Ab1, 1)

q software requirements analysis,

q software design,

q coding,

q testing, and

q software maintenance.

Individualsinvolved incoding

The individuals involved in codingreview the software requirements andsoftware design to ensure that issuesaffecting the coding are identified andresolved. (L3-71, A4, 1)

Individualsinvolved indevelopingthe softwarerequirements

The individuals involved in developingthe software requirements review theallocated requirements to ensure thatissues affecting the software requirementsanalysis are identified and resolved. (L3-66, A2, 1)

Individualsinvolved insoftwaredesign

The individuals involved in the softwaredesign review the software requirements toensure that issues affecting the softwaredesign are identified and resolved. (L3-69,A3, 2)

Individualsresponsiblefor systemandacceptancetesting

The integration test cases and testprocedures are reviewed with theindividuals responsible for the softwarerequirements, software design, and systemand acceptance testing. (L3-75, A6, 2)

Individualsresponsiblefor thesoftwaredesign

The integration test cases and testprocedures are reviewed with theindividuals responsible for the softwarerequirements, software design, and systemand acceptance testing. (L3-75, A6, 2)


Individualsresponsiblefor thesoftwarerequirements

The integration test cases and testprocedures are reviewed with theindividuals responsible for the softwarerequirements, software design, andsystem and acceptance testing. (L3-75,A6, 2)




Roles,continued



Projectmanager

q The project manager and all softwaremanagers receive orientation in thetechnical aspects of the softwareproject. (L3-64, Ab4)

q The activities for software productengineering are reviewed with theproject manager on both a periodicand event-driven basis. (L3-80, V2)

Seniormanagement

The activities for software productengineering are reviewed with seniormanagement on a periodic basis. (L3-80,V1)

Softwareengineeringtechnical staff

q Members of the software engineeringtechnical staff receive requiredtraining to perform their technicalassignments. (L3-63, Ab2)

q Members of the software engineeringtechnical staff receive orientation inrelated software engineeringdisciplines. (L3-64, Ab3)

Softwaremaintainer



Softwaremanager

The project manager and all softwaremanagers receive orientation in thetechnical aspects of the software project.(L3-64, Ab4)




Roles,continued




The software quality assurance groupreviews and/or audits the activities andwork products for software productengineering and reports the results. (L3-81,V3)

Test group The test cases and test procedures areplanned and prepared by a test group thatis independent of the software developers.(L3-76, A7, 3)


SPE Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the software product engineering process.



q are approved. (L3-79, A10, 4.2)

q are incorporated before anysoftware work products oractivities are changed. (L3-79,A10, 4.2)

Changes to softwareprocess descriptions

are proposed. (L3-78, A10, 4)

Changes to softwareactivities


Changes to softwareplans


Changes to softwarework products


Test plan is documented. (L3-81, V3, 5)

The CMM recommends that the conditions described in the table below besatisfied before entering the software product engineering process.



The project follows a written organizational policy forperforming the software engineering activities. (L3-60, C1)

Adequate resources and funding are provided for performingthe software engineering tasks. (L3-61, Ab1)

Skilled individuals are available to perform the differentsoftware engineering tasks, including: (L3-61, Ab1, 1)

q software requirements analysis,

q software design,

q coding,

q testing, and

q software maintenance.

Tools to support the software engineering tasks are madeavailable. (L3-61, Ab1, 2)



SPE Process - Entry Cr i ter ia , Continued


The CMM recommends that the conditions described in the table below besatisfied before entering the software product engineering process, continued fromthe previous page.


Members of the software engineering technical staffreceive required training to perform their technicalassignments. (L3-63, Ab2)

Members of the software engineering technical staffreceive orientation in related software engineeringdisciplines. (L3-64, Ab3)

The project manager and all software managers receiveorientation in the technical aspects of the software project.(L3-64, Ab4)


SPE Process - Inputs

Inputs The table below lists the recommended inputs to the software product engineeringprocess.


Allocated requirements. (L3-66, A2, 1)

Application standards. (L3-70, A3, 3)

Baselined documentation of the allocatedrequirements. (L3-76, A7, 5)

Baselined software. (L3-76, A7, 5)

Changes to allocated requirements. (L3-69, A2, 12)

Changes to code being tested. (L3-74, A5,8)

Changes to process descriptions. (L3-78,A10, 4)

Changes to software activities. (L3-78,A10, 4)

Changes to software design. (L3-72, A4,6)

Changes to software plans. (L3-78, A10,4)

Changes to software products. (L3-79,A10, 4.3)

Changes to software requirements. (L3-71,A3, 11)

Changes to software work products. (L3-78, A10, 4)

Completion criteria for each softwareengineering task. (L3-81, V3, 2)

Methods for programming. (L3-71, A4, 2)

Methods for requirements analysis. (L3-67, A2, 2)

Methods for software design. (L3-70, A3,4)

Methods for software engineering. (L3-65,A1)

Methods for software test. (L3-72, A5, 2)

Needs of the customer. (L3-72, A4, 3)

Needs of the end users. (L3-72, A4, 3)


SPE Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the software product engineeringprocess, continued from the previous page.

Input Org. Inputs References

Plan (that accounts for factors such ascriticality, difficulty, integration and testissues, and needs of the customer and endusers, as appropriate). (L3-72, A4, 3)

Process descriptions. (L3-78, A10)

Project’s defined software process. (L3-60,C1)

Readiness criteria for each softwareengineering task. (L3-81, V3, 2)

Software baseline. (L3-82, V3, 10)

Software baselined for softwareacceptance testing. (L3-77, A8, 4)

Software code. (L3-78, A10)

Software design document. (L3-75, A6, 3)

Software design. (L3-71, A4)

Software development plan. (L3-75, A6,1)

Software engineering tools. (L3-65, A1)

Software plans. (L3-78, A10)

Software requirements document. (L3-75,A6, 3)

Software requirements. (L3-66, A2)

Software standards. (L3-81, V3, 3)

Software work products. (L3-78, A10)

System requirements allocated to software.(L3-60, C1, 3)

Test cases. (L3-78, A10, 2)

Test plans. (L3-78, A10)

Test procedures. (L3-78, A10)


SPE Process - Act iv i t ies

Activities The table below lists the recommended activities for the software productengineering process.


Appropriate software engineering methods and tools areintegrated into the project's defined software process. (L3-65, A1)

q The software engineering tasks are integrated accordingto the project's defined software process.

q Methods and tools appropriate for use on the softwareproject are selected.

q The rationale for selecting a particular tool ormethod is documented.

q Configuration management models appropriate to thesoftware project are selected and used.

q The tools used to develop and maintain the softwareproducts are placed under configuration management.



SPE Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software productengineering process, continued from the previous page.


The software requirements are developed, maintained,documented, and verified by systematically analyzing theallocated requirements according to the project's definedsoftware process. (L3-66, A2)

q The individuals involved in developing the softwarerequirements review the allocated requirements toensure that issues affecting the software requirementsanalysis are identified and resolved.

q Effective methods for requirements analysis are used toidentify and derive the software requirements.

q The results of the requirements analysis and therationale for the selected alternative are documented.

q The software requirements are analyzed to ensure theyare feasible and appropriate to implement in software,clearly stated, consistent with each other, testable, andcomplete (when considered as a set).

q Problems with the software requirements areidentified and reviewed with the group responsiblefor the system requirements; appropriate changesare made to the allocated requirements and to thesoftware requirements.

q The software requirements are documented.

q The group responsible for system and acceptancetesting of the software analyzes each softwarerequirement to verify it can be tested.

q The methods for verifying and validating that eachsoftware requirement is satisfied are identified anddocumented.

q The software requirements document undergoes peerreview before it is considered complete.

q The software requirements document is reviewed andapproved.

q The software requirements document is reviewed withthe customer and end users, as appropriate.

q The software requirements document is placed underconfiguration management.

q The software requirements are appropriately changedwhenever the allocated requirements change.






The software design is developed, maintained, documented,and verified, according to the project's defined softwareprocess, to accommodate the software requirements and toform the framework for coding. (L3-69, A3)

q Design criteria are developed and reviewed.

q The individuals involved in the software designreview the software requirements to ensure that issuesaffecting the software design are identified and resolved.

q Application standards are used where appropriate.

q Effective methods are used to design the software.

q The software architecture is developed early, within theconstraints of the software life cycle and technologybeing used.

q The software architecture is reviewed to ensure thatarchitecture issues affecting the software detaileddesign are identified and resolved.

q The software detailed design is developed based on thesoftware architecture.

q The software design (i.e., the software architecture anddetailed design) is documented.

q The documentation of the software design covers thesoftware components; the internal interfacesbetween software components; and the softwareinterfaces to other software systems, to hardware,and to other system components (e.g., humans).

q The software design document undergoes peer reviewbefore the design is considered complete.

q The software design document is placed underconfiguration management.

q The software design document is appropriately changedwhenever the software requirements change.







The software code is developed, maintained, documented,and verified, according to the project's defined softwareprocess, to implement the software requirements andsoftware design. (L3-71, A4)

q The individuals involved in coding review thesoftware requirements and software design to ensure thatissues affecting the coding are identified and resolved.

q Effective programming methods are used to code thesoftware.

q The sequence in which code units are developed isbased on a plan that accounts for factors such ascriticality, difficulty, integration and test issues, andneeds of the customer and end users, as appropriate.

q Each code unit undergoes peer review and is unit testedbefore the unit is considered complete.

q The code is placed under configuration management.

q The code is appropriately changed whenever thesoftware requirements or software design changes.







Software testing is performed according to the project'sdefined software process. (L3-72, A5)

q Testing criteria are developed and reviewed with thecustomer and the end users, as appropriate.

q Effective methods are used to test the software.

q The adequacy of testing is determined based on:

q the level of testing performed,

q the test strategy selected, and

q the test coverage to be achieved.

q For each level of software testing, test readiness criteriaare established and used.

q Regression testing is performed, as appropriate, at eachtest level whenever the software being tested or itsenvironment changes.

q The test plan, test procedures, and test cases undergopeer review before they are considered ready for use.

q The test plans, test procedures, and test cases aremanaged and controlled.

q Test plans, test procedures, and test cases areappropriately changed whenever the allocatedrequirements, software requirements, software design, orcode being tested changes.

Integration testing of the software is planned and performedaccording to the project's defined software process. (L3-74,A6)

q The plans for integration testing are documented andbased on the software development plan.

q The integration test cases and test procedures arereviewed with the individuals responsible for thesoftware requirements, software design, and systemand acceptance testing.

q Integration testing of the software is performed againstthe designated version of the software requirementsdocument and the software design document.







System and acceptance testing of the software are plannedand performed to demonstrate that the software satisfies itsrequirements. (L3-75, A7)

q Resources for testing the software are assigned earlyenough to provide for adequate test preparation.

q System and acceptance testing are documented in a testplan, which is reviewed with, and approved by, thecustomer and end users, as appropriate.

q The test cases and test procedures are planned andprepared by a test group that is independent of thesoftware developers.

q The test cases are documented and are reviewed with,and approved by, the customer and end users, asappropriate, before the testing begins.

q Testing of the software is performed against baselinedsoftware and the baselined documentation of theallocated requirements and the software requirements.

q Problems identified during testing are documented andtracked to closure.

q Test results are documented and used as the basis fordetermining whether the software satisfies itsrequirements.

q The test results are managed and controlled.







The documentation that will be used to operate andmaintain the software is developed and maintainedaccording to the project's defined software process. (L3-76,A8)

q Appropriate methods and tools are used to develop thedocumentation.

q Documentation specialists actively participate inplanning, developing, and maintaining documentation.

q Preliminary versions of the documentation aredeveloped and made available early in the software lifecycle for the customer, end users, and softwaremaintainers, as appropriate, to review and providefeedback.

q Final versions of the documentation are verified againstthe software baselined for software acceptance testing.

q The documentation undergoes peer review.

q The documentation is managed and controlled.

q The final documentation is reviewed and approved bythe customer, end users, and software maintainers,as appropriate.

Data on defects identified in peer reviews and testing arecollected and analyzed according to the project's definedsoftware process. (L3-78, A9)







Consistency is maintained across software work products,including the software plans, process descriptions, allocatedrequirements, software requirements, software design, code,test plans, and test procedures. (L3-78, A10)

q Software work products are documented, and thedocumentation is readily available.

q The software requirements, design, code, and test casesare traced to the source from which they were derivedand to the products of the subsequent softwareengineering activities.

q The documentation tracing the allocated requirementsthrough the software requirements, design, code, andtest cases is managed and controlled.

q As understanding of the software improves, changes tothe software work products, plans, process descriptions,and activities are proposed, analyzed, and incorporatedas appropriate.

q The project determines the impact of the changebefore the change is made.

q Where changes to the allocated requirements areneeded, they are approved and incorporated beforeany software work products or activities arechanged.

q Changes to all software products, plans, processdescriptions, and activities are coordinated.

q Changes are negotiated with and communicated tothe affected groups.

q Changes are tracked to completion.

Measurements are made and used to determine thefunctionality and quality of the software products. (L3-79,M1)

Measurements are made and used to determine the status ofthe software product engineering activities. (L3-80, M2)

The activities for software product engineering are reviewedwith senior management on a periodic basis. (L3-80, V1)







The activities for software product engineering are reviewedwith the project manager on both a periodic and event-driven basis. (L3-80, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software productengineering and reports the results. (L3-81, V3)

[Refer to SPE Process Reviews and Audits for additionalinformation.]


SPE Process - Outputs

Outputs The table below lists the recommended outputs produced by the software productengineering process.


Architecture issues (affecting the softwaredetailed design). (L3-70, A3, 6)

Changes to allocated requirements. (L3-67, A2, 4.1)

Changes to process descriptions. (L3-79,A10, 4.3)

Changes to software activities. (L3-79,A10, 4.3)

Changes to software plans. (L3-79, A10,4.3)

Changes to the software requirements.(L3-67, A2, 4.1)

Changes to software work products. (L3-79, A10, 4.3)

Code unit. (L3-72, A4, 3)

Configuration management models. (L3-66, A1, 3)

Data on defects identified in peer reviews.(L3-78, A9)

Data on defects identified in testing. (L3-78, A9)

Defects detected in SQA group reviewsand/or audits. (L3-82, V3, 8)

Design criteria. (L3-69, A3, 1)

Documentation that will be used to operateand maintain the software. (L3-76, A8)

Documentation tracing the allocatedrequirements through the softwarerequirements, design, code, and test cases.(L3-78, A10, 3)

Integration test cases. (L3-75, A6, 2)

Integration test procedures. (L3-75, A6, 2)

Issues affecting the coding. (L3-71, A4, 1)

Issues affecting the software design. (L3-69, A3, 2)


SPE Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the software productengineering process, continued from the previous page.


Issues affecting the software requirementsanalysis. (L3-66, A2, 1)

Measurements (to determine thefunctionality and quality of the softwareproducts). (L3-79, M1)

Methods for validating that each softwarerequirement is satisfied. (L3-68, A2, 7)

Methods for verifying that each softwarerequirement is satisfied. (L3-68, A2, 7)

Plans for integration testing. (L3-75, A6,1)

Problems detected in SQA group reviewsand/or audits. (L3-82, V3, 8)

Problems identified during testing. (L3-76,A7, 6)

Problems with the software requirements.(L3-67, A2, 4.1)

Rationale for selecting a particular(software engineering) method. (L3-66,A1, 2.1)

Rationale for selecting a particular(software engineering) tool. (L3-66, A1,2.1)

Rationale for the selected alternative.(L3-67, A2, 3)

Results of SQA group reviews and/oraudits. (L3-81, V3)

Results of the requirements analysis. (L3-67, A2, 3)

Software architecture. (L3-70, A3, 5)

Software code. (L3-71, A4)

Software design document. (L3-71, A3,8.1)

Software design. (L3-69, A3)

Software detailed design. (L3-70, A3, 7)

Software plans. (L3-60, C1, 3)


Software products. (L3-60, C1, 2)



SPE Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the software productengineering process, continued from the previous page.


Software requirements document. (L3-68,A2, 8)

Software requirements. (L3-66, A2)

Software work products. (L3-78, A10, 1)

Test cases. (L3-74, A5, 6)

Test plan. (L3-74, A5, 6)

Test procedures. (L3-74, A5, 6)

Test readiness criteria. (L3-73, A5, 4)

Test results. (L3-76, A7, 7)

Testing criteria. (L3-72, A5, 1)


SPE Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software product engineering process.


Architecture issues(affecting thesoftware detaileddesign)


q are resolved. (L3-70, A3, 6)


are made. (L3-67, A2, 4.1)

Changes to processdescriptions


q are incorporated as appropriate.(L3-78, A10, 4)

q have their impact determined bythe project before the changesare made. (L3-79, A10, 4.1)

q are coordinated. (L3-79, A10,4.3)

q are negotiated with the affectedgroups. (L3-79, A10, 4.4)

q are communicated to theaffected groups. (L3-79, A10,4.4)

q are tracked to completion. (L3-79, A10, 4.5)

Changes to softwareactivities









Changes to softwarerequirements

are made (based on problemsidentified with the softwarerequirements). (L3-67, A2, 4.1)



SPE Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software product engineering process, continued from the previouspage.


Changes to softwareplans








Changes to softwarework products














Code unit q development sequence is basedon a plan that accounts forfactors such as:

q criticality,

q difficulty,

q integration and test issues,and

q needs of the customer andend users, as appropriate.(L3-72, A4, 3)

q undergoes peer review. (L3-72,A4, 4)

q is unit tested before the unit isconsidered complete. (L3-72,A4, 4)

Configurationmanagement models

q are appropriate to the softwareproject. (L3-66, A1, 3)

q are selected. (L3-66, A1, 3)

q are used. (L3-66, A1, 3)

Data on defectsidentified in peerreviews

q are collected according to theproject's defined softwareprocess. (L3-78, A9)

q are analyzed according to theproject's defined softwareprocess. (L3-78, A9)

Data on defectsidentified in testing

q are collected according to theproject's defined softwareprocess. (L3-78, A9)

q are analyzed according to theproject's defined softwareprocess. (L3-78, A9)

Design criteria q are developed. (L3-69, A3, 1)




Documentation (thatwill be used tooperate and maintainthe software)

q is developed according to theproject's defined softwareprocess. (L3-76, A8)

q is maintained according to theproject's defined softwareprocess. (L3-76, A8)

q is developed by usingappropriate methods and tools.(L3-76, A8, 1)

q (preliminary versions) aredeveloped. (L3-77, A8, 3)

q (preliminary versions) are madeavailable early in the softwarelife cycle for the customer, endusers, and softwaremaintainers, as appropriate, toreview and to provide feedback.(L3-77, A8, 3)

q (final versions) are verifiedagainst the software baselinedfor software acceptance testing.(L3-77, A8, 4)



q (final version) is reviewed by thecustomer, end users, andsoftware maintainers, asappropriate. (L3-77, A8, 7)

q (final version) is approved by thecustomer, end users, andsoftware maintainers, asappropriate. (L3-77, A8, 7)

q is verified against the softwarebaseline and any applicableallocated requirements beforethe software product is releasedto the customer or end users.(L3-82, V3, 10)







Documentation(tracing the allocatedrequirements throughthe softwarerequirements, design,code, and test cases)

is managed and controlled. (L3-78,A10, 3)

Integration test cases are reviewed with the individualsresponsible for the softwarerequirements, software design,and system and acceptance testing.(L3-75, A6, 2)

Issues affecting thecoding



Issues affecting thesoftware design



Issues affecting thesoftwarerequirements analysis



Measurements (todetermine thefunctionality andquality of thesoftware products)



Measurements (todetermine the statusof the softwareproduct engineeringactivities)



Methods forvalidating that eachsoftware requirementis satisfied



Methods for verifyingthat each softwarerequirement issatisfied









Plans for integrationtesting


q are based on the softwaredevelopment plan. (L3-75, A6,1)

Problems identifiedduring testing



Problems with thesoftwarerequirements

q are identified. (L3-67, A2, 4.1)

q are reviewed with the groupresponsible for the systemrequirements. (L3-67, A2, 4.1)

Rationale forselecting a particularmethod


Rationale forselecting a particulartool


Rationale for theselected alternative

is documented. (L3-67, A2, 3)

Results of SQAgroup reviews and/oraudits


Results of therequirements analysis


Software architecture q is developed early, within theconstraints of the software lifecycle and technology being used.(L3-70, A3, 5)

q is reviewed to ensure thatarchitecture issues affecting thesoftware detailed design areidentified and resolved. (L3-70,A3, 6)








Software code q is, (according to the project'sdefined software process, ) (L3-71, A4)

q developed,

q maintained,

q documented, and

q verified.

q implements the softwarerequirements and softwaredesign. (L3-71, A4)


q is appropriately changedwhenever the softwarerequirements or software designchanges. (L3-72, A4, 6)

Software designdocument

q undergoes peer review before thedesign is considered complete.(L3-71, A3, 9)


q is appropriately changedwhenever the softwarerequirements change. (L3-71,A3, 11)


Software design q is, according to the project'sdefined software process, (L3-69, A3)

q developed,

q maintained,

q documented, and

q verified.

q accommodates the softwarerequirements. (L3-69, A3)

q forms the framework for coding.(L3-69, A3)








Software detaileddesign

q is developed based on thesoftware architecture. (L3-70,A3, 7)


Software plans are traceable to the systemrequirements allocated to software.(L3-60, C1, 3)

Software products q are built using appropriatemethods and tools. (L3-60, C1,2)

q are maintained using appropriatemethods and tools. (L3-60, C1,2)

q are traceable to the systemrequirements allocated tosoftware. (L3-60, C1, 3)

q comply with the standards andrequirements specified for them.(L3-81, V3, 3)

Softwarerequirementsdocument

q undergoes peer review before itis considered complete. (L3-68,A2, 8)


q is approved. (L3-68, A2, 9)

q is reviewed with the customerand end users, as appropriate.(L3-68, A2, 10)








Softwarerequirements

q are: (L3-66, A2)

q developed,

q maintained,

q documented, and

q verified by systematicallyanalyzing the allocatedrequirements according tothe project's defined softwareprocess.

q are identified using effectivemethods for requirementsanalysis. (L3-67, A2, 2)

q are derived using effectivemethods for requirementsanalysis. (L3-67, A2, 2)

q are analyzed to ensure they are:(L3-67, A2, 4)


q clearly stated,

q consistent with each other,

q testable, and

q complete (when consideredas a set).


q (each) is analyzed by the groupresponsible for system andacceptance testing to verify itcan be tested. (L3-67, A2, 6)

q are appropriately changedwhenever the allocatedrequirements change. (L3-69,A2, 12)


are documented, and thedocumentation is readily available.(L3-78, A10, 1)






Test cases q undergo peer review before theyare considered ready for use.(L3-74, A5, 6)


q are appropriately changedwhenever the allocatedrequirements, softwarerequirements, software design, orcode being tested changes. (L3-74, A5, 8)

q are planned and prepared by atest group that is independent ofthe software developers. (L3-76,A7, 3)


q are reviewed with the customerand end users, as appropriate,before the testing begins. (L3-76, A7, 4)

q are approved by the customerand end users, as appropriate,before the testing begins. (L3-76, A7, 4)







Test plan q undergoes peer review before itis considered ready for use. (L3-74, A5, 6)


q is appropriately changedwhenever the allocatedrequirements, softwarerequirements, software design, orcode being tested changes. (L3-74, A5, 8)

q is reviewed with the customerand end users, as appropriate.(L3-75, A7, 2)

q is approved by the customer andend users, as appropriate. (L3-75, A7, 2)

Test procedures q undergo peer review before theyare considered ready for use.(L3-74, A5, 6)


q are appropriately changedwhenever the allocatedrequirements, softwarerequirements, software design, orcode being tested changes. (L3-74, A5, 8)

q are planned and prepared by atest group that is independent ofthe software developers. (L3-76,A7, 3)

Test readinesscriteria


q are used. (L3-73, A5, 4)







Test results q are documented. (L3-76, A7, 7)

q are used as the basis fordetermining whether the softwaresatisfies its requirements. (L3-76, A7, 7)


Testing criteria q are developed. (L3-72, A5, 1)

q are reviewed with the customerand the end users, asappropriate. (L3-72, A5, 1)

The CMM recommends that the conditions described in the table below besatisfied to exit the software product engineering process.



The software engineering tasks are performed in accordancewith the project's defined software process. (L3-60, C1, 1)

Appropriate software engineering methods and tools areintegrated into the project's defined software process. (L3-65, A1)

The software engineering tasks are integrated according tothe project's defined software process. (L3-65, A1, 1)

Methods and tools appropriate for use on the softwareproject are selected. (L3-65, A1, 2)

Effective methods for requirements analysis are used toidentify and derive the software requirements. (L3-67, A2,2)

Problems with the software requirements are identified andreviewed with the group responsible for the systemrequirements; appropriate changes are made to theallocated requirements and to the software requirements.(L3-67, A2, 4.1)

The individuals involved in the software design reviewthe software requirements to ensure that issues affecting thesoftware design are identified and resolved. (L3-69, A3, 2)


Application standards are used where appropriate. (L3-70,A3, 3)





The CMM recommends that the conditions described in the table below besatisfied to exit the software product engineering process, continued from theprevious page.


Effective methods are used to design the software. (L3-70,A3, 4)

The individuals involved in coding review the softwarerequirements and software design to ensure that issuesaffecting the coding are identified and resolved. (L3-71,A4, 1)

Effective programming methods are used to code thesoftware. (L3-71, A4, 2)

Software testing is performed according to the project'sdefined software process. (L3-72, A5)

Effective methods are used to test the software. (L3-72, A5,2)

The adequacy of testing is determined based on: (L3-72,A5, 3)

q the level of testing performed,

q the test strategy selected, and

q the test coverage to be achieved.

Regression testing is performed, as appropriate, at each testlevel whenever the software being tested or its environmentchanges. (L3-74, A5, 5)

Integration testing of the software is planned and performedaccording to the project's defined software process. (L3-74,A6)

Integration testing of the software is performed against thedesignated version of the software requirements documentand the software design document. (L3-75, A6, 3)

System and acceptance testing of the software are plannedand performed to demonstrate that the software satisfies itsrequirements. (L3-75, A7)

Resources for testing the software are assigned early enoughto provide for adequate test preparation. (L3-75, A7, 1)

Testing of the software is performed against baselinedsoftware and the baselined documentation of the allocatedrequirements and the software requirements. (L3-76, A7, 5)





The CMM recommends that the conditions described in the table below besatisfied to exit the software product engineering process, continued from theprevious page.


Documentation specialists actively participate in planning,developing, and maintaining documentation. (L3-77, A8, 2)

Consistency is maintained across software work products,including the software plans, process descriptions, allocatedrequirements, software requirements, software design, code,test plans, and test procedures. (L3-78, A10)

q The software requirements, design, code, and test casesare traced to the source from which they were derivedand to the products of the subsequent softwareengineering activities. (L3-78, A10, 2)

The activities for software product engineering are reviewedwith senior management on a periodic basis. (L3-80, V1)

The activities for software product engineering are reviewedwith the project manager on both a periodic and event-driven basis. (L3-80, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software productengineering and reports the results. (L3-81, V3)

Readiness and completion criteria for each softwareengineering task are satisfied. (L3-81, V3, 2)

Required testing is performed. (L3-81, V3, 4)

System and acceptance testing of the software areperformed according to documented plans and procedures.(L3-81, V3, 5)

Tests satisfy their acceptance criteria, as documented in thesoftware test plan. (L3-81, V3, 6)

Tests are satisfactorily completed and recorded. (L3-81,V3, 7)

Problems and defects detected are documented, tracked,and addressed. (L3-82, V3, 8)

Tracing of the allocated requirements through the softwarerequirements, design, code, and test cases is performed.(L3-82, V3, 9)

The documentation used to operate and maintain thesoftware is verified against the software baseline and anyapplicable allocated requirements before the softwareproduct is released to the customer or end users. (L3-82,V3, 10)


SPE Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the softwareproduct engineering process.


References

The individuals involved in developingthe software requirements review theallocated requirements to ensure thatissues affecting the software requirementsanalysis are identified and resolved. (L3-66, A2, 1)

Individualsinvolved indeveloping thesoftwarerequirements

Problems with the software requirementsare identified and reviewed with the groupresponsible for the systemrequirements; appropriate changes aremade to the allocated requirements and tothe software requirements. (L3-67, A2,4.1)

Groupresponsiblefor the systemrequirements

The software requirements documentundergoes peer review before it isconsidered complete. (L3-68, A2, 8)


The software requirements document isreviewed and approved. (L3-68, A2, 9)


The software requirements document isreviewed with the customer and endusers, as appropriate. (L3-68, A2, 10)

Customer

End Users

Design criteria are developed andreviewed. (L3-69, A3, 1)


The individuals involved in the softwaredesign review the software requirements toensure that issues affecting the softwaredesign are identified and resolved. (L3-69,A3, 2)

Individualsinvolved inthe softwaredesign

The software architecture is reviewed toensure that architecture issues affectingthe software detailed design are identifiedand resolved. (L3-70, A3, 6)


The software design document undergoespeer review before the design is consideredcomplete. (L3-71, A3, 9)



The individuals involved in codingreview the software requirements andsoftware design to ensure that issuesaffecting the coding are identified andresolved. (L3-71, A4, 1)




SPE Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the softwareproduct engineering process, continued from the previous page.


References

Each code unit undergoes peer review andis unit tested before the unit is consideredcomplete. (L3-72, A4, 4)


Testing criteria are developed andreviewed with the customer and the endusers, as appropriate. (L3-72, A5, 1)

Customer

End users

The test plan, test procedures, and testcases undergo peer review before they areconsidered ready for use. (L3-74, A5, 6)


The integration test cases and testprocedures are reviewed with theindividuals responsible for the softwarerequirements, software design, andsystem and acceptance testing. (L3-75,A6, 2)

Individualsresponsiblefor thesoftwarerequirements,softwaredesign, andsystem andacceptancetesting

System and acceptance testing aredocumented in a test plan, which isreviewed with, and approved by, thecustomer and end users, as appropriate.(L3-75, A7, 2)

Customer

End users

The test cases are documented and arereviewed with, and approved by, thecustomer and end users, as appropriate,before the testing begins. (L3-76, A7, 4)

Customer

End users

Preliminary versions of the documentation(that will be used to operate and maintainthe software) are developed and madeavailable early in the software life cyclefor the customer, end users, andsoftware maintainers, as appropriate, toreview and provide feedback. (L3-77, A8,3)

Customer

End users

Softwaremaintainers

The documentation (that will be used tooperate and maintain the software)undergoes peer review. (L3-77, A8, 5)





The table below lists the recommended reviews and audits for the softwareproduct engineering process, continued from the previous page.


References

The final documentation (that will be usedto operate and maintain the software) isreviewed and approved by the customer,end users, and software maintainers, asappropriate. (L3-77, A8, 7)

Customer

End users

Softwaremaintainers

The activities for software productengineering are reviewed with seniormanagement on a periodic basis. (L3-80,V1)

Seniormanagement

The activities for software productengineering are reviewed with the projectmanager on both a periodic and event-driven basis. (L3-80, V2)

Projectmanager

The software quality assurance groupreviews and/or audits the activities andwork products for software productengineering and reports the results. (L3-81, V3)


q The software requirements arereviewed to ensure that they are:

q complete,

q correct,

q consistent,

q feasible, and

q testable.

q Readiness and completion criteria foreach software engineering task aresatisfied.

q Software products comply with thestandards and requirements specifiedfor them.

q Required testing is performed.

q System and acceptance testing of thesoftware are performed according todocumented plans and procedures.

SQA group


This review continued on next page





The table below lists the required reviews and audits for the software productengineering process, continued from the previous page.


References

This review continued from previous page

q Tests satisfy their acceptance criteria,as documented in the software testplan.

q Tests are satisfactorily completed andrecorded.

q Problems and defects detected aredocumented, tracked, and addressed.

q Tracing of the allocated requirementsthrough the software requirements,design, code, and test cases isperformed.

q The documentation used to operate andmaintain the software is verifiedagainst the software baseline and anyapplicable allocated requirementsbefore the software product is releasedto the customer or end users.

SQA group


SPE Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the software product engineering process.


Tools used to develop and maintain the software products.*

(L3-66, A1, 4)

Software requirements document.* (L3-69, A2, 11)

Software design document.* (L3-71, A3, 10)

Code.* (L3-72, A4, 5)

Test plans, test procedures, and test cases. (L3-74, A5, 7)

Test results. (L3-76, A7, 8)

Documentation (that will be used to operate and maintainthe software). (L3-77, A8, 6)

Documentation tracing the allocated requirements throughthe software requirements, design, code, and test cases.(L3-78, A10, 3)

*Indicates that the CMM recommends that this item be placed under configurationmanagement


SPE Process - Measurements

Measurements The table below lists the measurements recommended for the software productengineering process.


Data on defects identified in peer reviews. (L3-78, A9)

Data on defects identified in testing. (L3-78, A9)

Measurements to determine the functionality and quality ofthe software products. (L3-79, M1)


q Numbers, types, and severity of defects identified in thesoftware products tracked cumulatively and by stage.

q Allocated requirements summarized by category (e.g.,security, system configuration, performance, andreliability), and traced to the software requirements andsystem test cases.

Measurements to determine the status of the softwareproduct engineering activities. (L3-80, M2)


q Status of each allocated requirement throughout the lifeof the project.

q Problem reports by severity and length of time they areopen.

q Change activity for the allocated requirements.

q Effort to analyze proposed changes for each proposedchange and cumulative totals.

q Number of changes incorporated into the softwarebaseline by category (e.g., interface, security, systemconfiguration, performance, and usability).

q Size and cost to implement and test incorporatedchanges, including initial estimate and actual size andcost.


SPE Process - Documented Procedures


There are no activities that are recommended to be performed according to adocumented procedure in the software product engineering process.


SPE Process - T ra in ing

Training The table below lists the training recommended for the software productengineering process.

Training References

Members of the software engineering technical staffreceive required training to perform their technicalassignments. (L3-63, Ab2)

Members of the software engineering technical staffreceive orientation in related software engineeringdisciplines. (L3-64, Ab3)

The project manager and all software managers receiveorientation in the technical aspects of the software project.(L3-64, Ab4)


SPE Process - Too ls

Tools The table below lists the tools recommended for the software product engineeringprocess.

Tools References

Tools to build and maintain the software products. (L3-60,C1, 2)

Tools to support the software engineering tasks. (L3-61,Ab1, 2)


q workstations,

q database management systems,

q on-line help aids,

q graphics tools,

q interactive documentation tools, and

q word processing systems.

Software engineering tools. (L3-65, A1)

Tools to develop the documentation. (L3-76, A8, 1)


In tergroup Coordinat ion ( IC) Process

IC Process - Overv iew

The purpose of Intergroup Coordination is to establish a means for the softwareengineering group to participate actively with the other engineering groups so theproject is better able to satisfy the customer's needs effectively and efficiently.(L3-83)

IC processpurpose

Intergroup Coordination involves the software engineering group's participationwith other project engineering groups to address system-level requirements,objectives, and issues. Representatives of the project's engineering groupsparticipate in establishing the system-level requirements, objectives, and plans byworking with the customer and end users, as appropriate. These requirements,objectives, and plans become the basis for all engineering activities.

The technical working interfaces and interactions between groups are planned andmanaged to ensure the quality and integrity of the entire system. Technicalreviews and interchanges are regularly conducted with representatives of theproject's engineering groups to ensure that all engineering groups are aware of thestatus and plans of all the groups, and that system and intergroup issues receiveappropriate attention.

The software-specific practices related to these engineering tasks are described inthe Requirements Management and Software Product Engineering key processareas. (L3-83)

IC processdescription



IC Process - Overv iew, Continued

Sectionoverview




L3-Process-151



L3-Process-159


L3-Process-160


L3-Process-162


L3-Process-164

Reviews andAudits




L3-Process-174




L3-Process-176




IC Process - Roles

Roles The table below lists the roles and the activities in which they participate in theintergroup coordination process.


Affectedgroups

The system requirements and project-levelobjectives for the project are defined andreviewed by all affected groups. (L3-84,C1, 1)

Customers The software engineering group and theother engineering groups participate withthe customer and end users, asappropriate, to establish the systemrequirements. (L3-86, A1)

End users The software engineering group and theother engineering groups participate withthe customer and end users, asappropriate, to establish the systemrequirements. (L3-86, A1)



IC Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theintergroup coordination process, continued from the previous page.


Engineeringgroups

q The engineering groups coordinatetheir plans and activities. (L3-84, C1,2)

q The members of the engineeringgroups receive orientation in workingas a team. (L3-86, Ab5)

q The software engineering group and theother engineering groups participatewith the customer and end users, asappropriate, to establish the systemrequirements. (L3-86, A1)

Specifically, these groups:

q Define the critical characteristicsof the customer's and end users'requirements, as appropriate.

q Negotiate critical dependencies.

q Document the acceptance criteriafor each product delivered to thecustomer or end user, asappropriate.

q The plan used to communicateintergroup commitments and track thework performed is reviewed and agreedto by all engineering groups and theproject manager. (L3-89, A3, 6)

q Critical dependencies are negotiatedbetween the software engineering groupand other engineering groups in theproject and organization. (L3-89, A4,2)

Groupresponsiblefor providingthe criticaldependencyitem

The agreement for each criticaldependency is documented, reviewed, andapproved by both the receiving group andthe group responsible for providing thecritical dependency item. (L3-89, A4, 4)




Roles,continued



Manager q Managers are responsible forestablishing and maintaining anenvironment to facilitate interaction,coordination, support, and teamworkbetween the project's engineeringgroups, between the project and thecustomer or end users, as appropriate,and throughout the organization. (L3-85, C1, 3)

q All managers in the organizationreceive required training in teamwork.(L3-85, Ab3)

q Actual and potential problems arereported to the appropriate managers.(L3-89, A4, 5.3)

Projectmanager

q The documented plan that is used tocommunicate intergroup commitmentsand to coordinate and track the workperformed is reviewed and agreed to byall engineering groups and the projectmanager. (L3-89, A3, 6)

q The activities for intergroupcoordination are reviewed with theproject manager on both a periodicand event-driven basis. (L3-92, V2)

Receivinggroup of acriticaldependencyitem





Roles,continued



Representa-tive’s of theproject’ssoftwareengineeringgroup

q Representatives of the project'ssoftware engineering group workwith representatives of the otherengineering groups to monitor andcoordinate technical activities andresolve technical issues. (L3-87, A2)

q The representatives of these groupsmonitor and coordinate technicalactivities by: (L3-87, A2, 1)

q coordinating the specification andproviding the technical review andapproval of the systemrequirements and system design;

q providing the project-leveltechnical review and analysisneeded to manage and controlchanges to the system requirementsand project-level objectivesthroughout the project's life cycle;

q tracking and reviewing the designand development activities forhardware, software, and othersystem components; and

q assessing, developingrecommendations for, and trackingtechnical risks that involve morethan one engineering group.

q The representatives of the groupshandle technical issues by: (L3-88,A2, 2)

q resolving project-level conflictsand clarifying system requirementsand design issues;

q developing joint recommendationsto resolve problems; and

q addressing process issues that spanthe engineering groups of theproject.




Roles,continued



Representa-tives of theotherengineeringgroups

q Representatives of the project'ssoftware engineering group work withrepresentatives of the otherengineering groups to monitor andcoordinate technical activities andresolve technical issues. (L3-87, A2)

q The representatives of these groupsmonitor and coordinate technicalactivities by: (L3-87, A2, 1)

q coordinating the specification andproviding the technical review andapproval of the systemrequirements and system design;

q providing the project-leveltechnical review and analysisneeded to manage and controlchanges to the system requirementsand project-level objectivesthroughout the project's life cycle;

q tracking and reviewing the designand development activities forhardware, software, and othersystem components; and

q assessing, developingrecommendations for, and trackingtechnical risks that involve morethan one engineering group.

q The representatives of the groupshandle technical issues by: (L3-88,A2, 2)

q resolving project-level conflictsand clarifying system requirementsand design issues;

q developing joint recommendationsto resolve problems; and

q addressing process issues that spanthe engineering groups of theproject.




Roles,continued



Representa-tives of theprojectengineeringgroups

q Intergroup issues not resolvable by theindividual representatives of theproject engineering groups arehandled according to a documentedprocedure. (L3-90, A6)

q Representatives of the projectengineering groups conduct periodictechnical reviews and interchanges.(L3-90, A7)

Representa-tives of thereceivinggroup of acriticaldependencyitem

Work products produced as input to otherengineering groups are reviewed byrepresentatives of the receiving groupsto ensure that the work products meet theirneeds. (L3-90, A5)

Seniormanagement

The activities for intergroup coordinationare reviewed with senior management ona periodic basis. (L3-91, V1)


q The software engineering group andthe other engineering groups participatewith the customer and end users, asappropriate, to establish the systemrequirements. (L3-86, A1)


q define the critical characteristics ofthe customer's and end users'requirements, as appropriate;

q negotiate critical dependencies;and

q document the acceptance criteriafor each product delivered to thecustomer or end user, asappropriate.

q Critical dependencies are negotiatedbetween the software engineeringgroup and other engineering groups inthe project and organization. (L3-89,A4, 2)



Roles,continued




The software quality assurance groupreviews and/or audits the activities andwork products for intergroup coordinationand reports the results. (L3-92, V3)

Task leaders All task leaders in each engineering groupreceive orientation in the processes,methods, and standards used by the otherengineering groups. (L3-86, Ab4)


IC Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the intergroup coordination process.


Plan used tocommunicateintergroupcommitments and tocoordinate and trackthe work performed

is documented. (L3-88, A3)

The CMM recommends that the conditions described in the table below besatisfied before entering the intergroup coordination process.



The project follows a written organizational policy forestablishing interdisciplinary engineering teams. (L3-84,C1)

Adequate resources and funding are provided forcoordinating the software engineering activities with otherengineering groups. (L3-85, Ab1)

The support tools used by the different engineering groupsare compatible to enable effective communication andcoordination. (L3-85, Ab2)

All managers in the organization receive required trainingin teamwork. (L3-85, Ab3)

All task leaders in each engineering group receiveorientation in the processes, methods, and standards used bythe other engineering groups. (L3-86, Ab4)

The members of the engineering groups receiveorientation in working as a team. (L3-86, Ab5)


IC Process - Inputs

Inputs The table below lists the recommended inputs to the intergroup coordinationprocess.


Actual completion (of criticaldependencies). (L3-89, A4, 5.1)

Changes to intergroup commitments. (L3-88, A3, 4)

Changes to the plan (used to communicateintergroup commitments and to coordinateand track the work performed). (L3-88,A3, 5)

Changes to the project-level objectives.(L3-87, A2, 1.2)

Changes to the system requirements. (L3-87, A2, 1.2)


Customer’s requirements. (L3-87, A1, 1)

End users’ requirements. (L3-87, A1, 1)

Intergroup commitments. (L3-88, A3)

Plan (used to communicate intergroupcommitments and to coordinate and trackthe work performed). (L3-88, A3)

Project schedule. (L3-89, A4, 3)

Projected completion (of criticaldependencies). (L3-89, A4, 5.1)

Software schedule. (L3-89, A4, 3)

Status (of critical dependencies). (L3-89,A4, 5.1)

System requirements. (L3-90, A7, 3)

Technical issues. (L3-90, A7, 5)

Technical requirements. (L3-90, A7, 3)

Technical risks. (L3-88, A2, 1.4)


IC Process - Act iv i t ies

Activities The table below lists the recommended activities for the intergroup coordinationprocess.


The software engineering group and the otherengineering groups participate with the customer andend users, as appropriate, to establish the systemrequirements. (L3-86, A1)


q Define the critical characteristics of the customer's andend users' requirements, as appropriate.

q Negotiate critical dependencies.

q Document the acceptance criteria for each productdelivered to the customer or end user, as appropriate.

Representatives of the project's software engineeringgroup work with representatives of the other engineeringgroups to monitor and coordinate technical activities andresolve technical issues. (L3-87, A2)

q The representatives of these groups monitor andcoordinate technical activities by:

q coordinating the specification and providing thetechnical review and approval of the systemrequirements and system design;

q providing the project-level technical review andanalysis needed to manage and control changes tothe system requirements and project-level objectivesthroughout the project's life cycle;

q tracking and reviewing the design and developmentactivities for hardware, software, and other systemcomponents; and

q assessing, developing recommendations for, andtracking technical risks that involve more than oneengineering group.

q The representatives of the groups handle technicalissues by:

q resolving project-level conflicts and clarifyingsystem requirements and design issues;

q developing joint recommendations to resolveproblems; and

q addressing process issues that span the engineeringgroups of the project.


IC Process - Act iv i t ies , Continued


The table below describes the activities associated with the intergroupcoordination process, continued from the previous page.


A documented plan is used to communicate intergroupcommitments and to coordinate and track the workperformed. (L3-88, A3)

Critical dependencies between engineering groups areidentified, negotiated, and tracked according to adocumented procedure. (L3-89, A4)


Work products produced as input to other engineering groupsare reviewed by representatives of the receiving groupsto ensure that the work products meet their needs. (L3-90,A5)

Intergroup issues not resolvable by the individualrepresentatives of the project engineering groups arehandled according to a documented procedure. (L3-90, A6)

Representatives of the project engineering groupsconduct periodic technical reviews and interchanges. (L3-90, A7)

[Refer to IC Process Reviews and Audits for additionalinformation.]

Measurements are made and used to determine the status ofthe intergroup coordination activities. (L3-91, M1)

The activities for intergroup coordination are reviewed withsenior management on a periodic basis. (L3-91, V1)

The activities for intergroup coordination are reviewed withthe project manager on both a periodic and event-drivenbasis. (L3-92, V2)

The software quality assurance group reviews and/oraudits the activities and work products for intergroupcoordination and reports the results. (L3-92, V3)

[Refer to IC Process Reviews and Audits for additionalinformation.]


IC Process - Outputs

Outputs The table below lists the outputs produced by the intergroup coordination process.


Acceptance criteria for each productdelivered to the customer. (L3-87, A1, 3)

Acceptance criteria for each productdelivered to the end user. (L3-87, A1, 3)

Agreement for each critical dependency.(L3-89, A4, 4)

Availability dates of critical dependencyitems. (L3-89, A4, 3)


Critical characteristics of the customer'srequirements. (L3-87, A1, 1)

Critical characteristics of the end users'requirements. (L3-87, A1, 1)

Critical dependencies. (L3-87, A1, 2)

Intergroup issues not resolvable by theindividual representatives of the projectengineering groups. (L3-90, A6)

Intergroup issues. (L3-92, V3, 2)

Joint recommendations to resolveproblems. (L3-88, A2, 2.2)

Measurements to determine the status ofthe intergroup coordination activities. (L3-91, M1)

Need dates of critical dependency items.(L3-89, A4, 3)

Plan used to communicate intergroupcommitments and to coordinate and trackthe work performed. (L3-88, A3)

Problems (actual and potential). (L3-89,A4, 5.3)

Process issues. (L3-88, A2, 2.3)

(Project engineering) groups' interpretationand implementation of the technicalrequirements. (L3-90, A7, 3)

Project-level conflicts. (L3-88, A2, 2.1)

Project-level objectives. (L3-84, C1, 1)


IC Process - Outputs, Continued

Outputs,continued

The table below lists the outputs produced by the intergroup coordination process,continued from the previous page.


Recommendations for technical risks (thatinvolve more than one engineering group).(L3-88, A2, 1.4)

Results of software quality assurancegroup reviews and/or audits. (L3-92, V3)

Specification of the system design. (L3-87, A2, 1.1)

Specification of the system requirements.(L3-87, A2, 1.1)

System design. (L3-87, A2, 1.1)

System design issues. (L3-88, A2, 2.1)

System requirements issues. (L3-88, A2,2.1)

System requirements. (L3-84, C1, 1)

Technical issues. (L3-87, A2)

Work products produced as input to otherengineering groups. (L3-90, A5)


IC Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the intergroup coordination process.


Acceptance criteriafor each productdelivered to thecustomer


Acceptance criteriafor each productdelivered to the enduser


Agreement for eachcritical dependency



q is approved by both thereceiving group and the groupresponsible for providing thecritical dependency item. (L3-89, A4, 4)

Availability dates ofcritical dependencyitems

q are tied to the project schedule.(L3-89, A4, 3)

q are tied to the software schedule.(L3-89, A4, 3)

Criticalcharacteristics of thecustomer'srequirements


Criticalcharacteristics of theend users'requirements




IC Process - Exi t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the intergroup coordination process, continued from the previous page.


Criticaldependencies

q are negotiated (between thesoftware engineering group, otherengineering groups, customers,and end users). (L3-87, A1, 2)

q (between engineering groups)are: (L3-89, A4)

q identified,

q negotiated, and

q tracked according to adocumented procedure.

q are explicitly defined, including:(L3-89, A4, 1)

q the item to be provided,

q who will provide it,

q when it will be provided, and

q the criteria for acceptance.

q are negotiated between thesoftware engineering groupand other engineering groupsin the project and organization.(L3-89, A4, 2)

q are tracked on a regular basisand corrective actions are takenwhen appropriate. (L3-89, A4,5)

Intergroup issues notresolvable by theindividualrepresentatives ofthe projectengineering groups

are handled according to adocumented procedure. (L3-90, A6)

Jointrecommendations toresolve problems

are developed by therepresentatives of the (softwareengineering and otherengineering) groups to handletechnical issues. (L3-88, A2, 2.2)







Measurements (todetermine the statusof the intergroupcoordinationactivities)



Need dates of criticaldependency items

q are tied to the project schedule.(L3-89, A4, 3)

q are tied to the software schedule.(L3-89, A4, 3)

Plan used tocommunicateintergroupcommitments and tocoordinate and trackthe work performed

q is the baseline for: (L3-88, A3,1)

q the project schedule,

q the contractual and technicalaspects of the project, and

q the assignment ofresponsibilities to theengineering groups.

q is used to coordinate activitiesbetween the differentengineering groups. (L3-88, A3,2)

q is readily available to themembers of all engineeringgroups. (L3-88, A3, 3)

q is updated to incorporate allintergroup commitments andchanges to these commitments.(L3-88, A3, 4)

q is updated as the work progressesto reflect progress and planchanges at the project level,particularly when major projectmilestones are completed andwhen plans change significantly.(L3-88, A3, 5)

Output continued on next page







Output continued from previous page

Plan used tocommunicateintergroupcommitments and tocoordinate and trackthe work performed,continued

q is reviewed by all engineeringgroups and the projectmanager. (L3-89, A3, 6)

q is agreed to by all engineeringgroups and the projectmanager. (L3-89, A3, 6)

Problems (actual andpotential)

are reported to the appropriatemanagers. (L3-89, A4, 5.3)

Process issues are addressed by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-88,A2, 2.3)

(Project engineering)groups' interpretationand implementationof the technicalrequirements

conform to the system requirements.(L3-90, A7, 3)

Project-levelconflicts

are resolved by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-88,A2, 2.1)

Project-levelobjectives

q are defined. (L3-84, C1, 1)

q are reviewed by all affectedgroups. (L3-84, C1, 1)

Recommendationsfor technical risksthat involve morethan one engineeringgroup

are developed. (L3-88, A2, 1.4)

Results of softwarequality assurancegroup reviews and/oraudits








Specification of thesystem design

is coordinated by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-87,A2, 1.1)

Specification of thesystem requirements

is coordinated by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-87,A2, 1.1)

System design q is technically reviewed byrepresentatives of the project'ssoftware engineering groupand representatives of theother engineering groups.(L3-87, A2, 1.1)

q is approved by representativesof the project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-87,A2, 1.1)

q is tracked by representatives ofthe project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-88,A2, 1.3)

System design issues are clarified by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-88,A2, 2.1)







System requirements q are defined. (L3-84, C1, 1)

q are reviewed by all affectedgroups. (L3-84, C1, 1)

q are established by the softwareengineering group and theother engineering groups, byparticipating with the customerand end users, as appropriate.(L3-86, A1)

q are technically reviewed byrepresentatives of the project'ssoftware engineering groupand representatives of theother engineering groups.(L3-87, A2, 1.1)

q are approved by representativesof the project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-87,A2, 1.1)

q are clarified by representativesof the project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-88,A2, 2.1)

System requirementsissues

are clarified by representatives ofthe project's software engineeringgroup and representatives of theother engineering groups. (L3-88,A2, 2.1)







Technical issues q are resolved by representativesof the project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-87,A2)

q are handled by representativesof the project's softwareengineering group andrepresentatives of the otherengineering groups. (L3-88,A2, 2)

q are reviewed by representativesof the project engineeringgroups. (L3-90, A7, 5)

Work products q are reviewed by representativesof the receiving groups toensure that the work productsmeet their needs. (L3-90, A5)

q are reviewed and/or audited bythe software quality assurancegroup. (L3-92, V3)

The CMM recommends that the conditions described in the table below besatisfied to exit the intergroup coordination process.



The engineering groups coordinate their plans andactivities. (L3-84, C1, 2)

The software engineering group and the otherengineering groups participate with the customer andend users, as appropriate, to establish the systemrequirements. (L3-86, A1)





The CMM recommends that the conditions described in the table below besatisfied to exit the intergroup coordination process, continued from the previouspage.


Representatives of the project's software engineeringgroup work with representatives of the other engineeringgroups to monitor and coordinate technical activities andresolve technical issues. (L3-87, A2)

The representatives of these groups monitor andcoordinate technical activities by: (L3-87, A2, 1)

q coordinating the specification and providing thetechnical review and approval of the systemrequirements and system design;

q providing the project-level technical review andanalysis needed to manage and control changes to thesystem requirements and project-level objectivesthroughout the project's life cycle;

q tracking and reviewing the design and developmentactivities for hardware, software, and other systemcomponents; and

q assessing, developing recommendations for, andtracking technical risks that involve more than oneengineering group.

A documented plan is used to communicate intergroupcommitments and to coordinate and track the workperformed. (L3-88, A3)

Representatives of the project engineering groupsconduct periodic technical reviews and interchanges. (L3-90, A7)

The activities for intergroup coordination are reviewed withsenior management on a periodic basis. (L3-91, V1)

The activities for intergroup coordination are reviewed withthe project manager on both a periodic and event-drivenbasis. (L3-92, V2)

The software quality assurance group reviews and/oraudits the activities and work products for intergroupcoordination and reports the results. (L3-92, V3)


IC Process - Reviews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the intergroupcoordination process.


References

The system requirements and project-levelobjectives for the project are defined andreviewed by all affected groups. (L3-84,C1, 1)

Affectedgroups

Representatives of the project's softwareengineering group work withrepresentatives of the other engineeringgroups to: (L3-87, A2)

q Provide the technical review andapproval of the system requirementsand system design. (L3-87, A2, 1.1)

q Provide the project-level technicalreview and analysis needed to manageand control changes to the systemrequirements and project-levelobjectives throughout the project's lifecycle. (L3-87, A2, 1.2)

q Track and review the design anddevelopment activities for hardware,software, and other systemcomponents. (L3-88, A2, 1.3)

Representa-tives of theproject'ssoftwareengineeringgroup


The documented plan used tocommunicate intergroup commitments andto coordinate and track the work performedis reviewed and agreed to by allengineering groups and the projectmanager. (L3-89, A3, 6)

Engineeringgroups

Projectmanager


Receivinggroup


Work products produced as input to otherengineering groups are reviewed byrepresentatives of the receiving groupsto ensure that the work products meet theirneeds. (L3-90, A5)

Representa-tives of thereceivinggroups


IC Process - Reviews and Audi ts , Continued


The table below lists the recommended reviews and audits for the intergroupcoordination process, continued from the previous page.


References

Representatives of the projectengineering groups conduct periodictechnical reviews and interchanges. (L3-90, A7)

In these meetings, the participants:

q Provide visibility of the needs anddesires of the customer and end users,as appropriate.

q Monitor the technical activities of theproject.

q Ensure that the groups' interpretationand implementation of the technicalrequirements conform to the systemrequirements.

q Review the commitments to determinewhether they are being met.

q Review the technical risks and othertechnical issues.


The activities for intergroup coordinationare reviewed with senior management ona periodic basis. (L3-91, V1)

Seniormanagement

The activities for intergroup coordinationare reviewed with the project manager onboth a periodic and event-driven basis.(L3-92, V2)

Projectmanager

The software quality assurance groupreviews and/or audits the activities andwork products for intergroup coordinationand reports the results. (L3-92, V3)


q The procedure for identifying,negotiating, and tracking criticaldependencies between the projectengineering groups.

q The handling of intergroup issues.



IC Process - Work Products Managed andContro l led


There are no work products that are recommended to be managed and controlledin the intergroup coordination process.


IC Process - Measurements

Measurements The table below lists the measurements recommended for the intergroupcoordination process.


Measurements to determine the status of the intergroupcoordination activities. (L3-91, M1)


q Actual effort and other resources expended by thesoftware engineering group for support to otherengineering groups.

q Actual effort and other resources expended by the otherengineering groups in support of the softwareengineering group.

q Actual completion of specific tasks and milestones bythe software engineering group to support the activitiesof other engineering groups.

q Actual completion of specific tasks and milestones bythe other engineering groups to support the activities ofthe software engineering group.


IC Process - Documented Procedures


The table below lists the activities for the intergroup coordination processrecommended to be performed according to a documented procedure.






IC Process - Tra in ing

Training The table below lists the training recommended for the intergroup coordinationprocess.

Training References

All managers in the organization receive required trainingin teamwork. (L3-85, Ab3)

All task leaders in each engineering group receiveorientation in the processes, methods, and standards used bythe other engineering groups. (L3-86, Ab4)

The members of the engineering groups receiveorientation in working as a team. (L3-86, Ab5)


IC Process - Tools

Tools The table below lists the tools recommended for the intergroup coordinationprocess.

Tools References

Support tools used by the different engineering groups. (L3-85, Ab2)


q word processing systems,

q database systems,

q graphics tools,


q problem tracking packages, and

q library management tools.


P e e r R e v i e w s ( P R ) P r o c e s s

PR Process - Overv iew

The purpose of Peer Reviews is to remove defects from the software work productsearly and efficiently. An important corollary effect is to develop a betterunderstanding of the software work products and of defects that might beprevented. (L3-93)

PR processpurpose

Peer Reviews involve a methodical examination of software work products by theproducers' peers to identify defects and areas where changes are needed. Thespecific products that will undergo a peer review are identified in the project'sdefined software process and scheduled as part of the software project planningactivities, as described in Integrated Software Management.

This key process area covers the practices for performing peer reviews. Thepractices identifying the specific software work products that undergo peer revieware contained in the key process areas that describe the development andmaintenance of each software work product. (L3-93)

PR processdescription


Sectionoverview



L3-Process-180



L3-Process-183


L3-Process-184


L3-Process-185


L3-Process-186

Reviews andAudits




L3-Process-189




L3-Process-191


PR Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thepeer reviews process.


Checklistdevelopers’peers

The checklists are reviewed by thechecklist developers' peers and potentialusers. (L3-98, A2, 5.2)

Checklistpotentialusers

The checklists are reviewed by thechecklist developers' peers and potentialusers. (L3-98, A2, 5.2)

Management Results of the peer reviews are not used bymanagement to evaluate the performanceof individuals. (L3-94, C1, 5)

Manager Issues in satisfying these (readiness andcompletion) criteria (for the peer reviews)are reported to the appropriate managers.(L3-98, A2, 4.1)

Peer reviewleader

q Peer reviews are led by trained peerreview leaders. (L3-94, C1, 3)

q Peer review leaders receive requiredtraining in how to lead peer reviews.(L3-95, Ab2)

q Peer reviews are planned and led bytrained peer review leaders. (L3-97,A2, 1)

q The peer review leaders areadequately trained for their roles. (L3-100, V1, 2)



PR Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thepeer reviews process, continued from the previous page.


Reviewer q Reviewers who participate in peerreviews receive required training in theobjectives, principles, and methods ofpeer reviews. (L3-96, Ab3)

q Review materials are distributed to thereviewers in advance so they canadequately prepare for the peer review.(L3-97, A2, 2)

q Reviewers have assigned roles in peerreviews. (L3-98, A2, 3)

q The reviewers are properly trained orexperienced in their roles. (L3-100,V1, 3)


The software quality assurance groupreviews and/or audits the activities andwork products for peer reviews and reportsthe results. (L3-100, V1)


PR Process - Entry Cr i ter ia


There are no input-based entry criteria in the peer reviews process.


The CMM recommends that the conditions described in the table below besatisfied before entering the peer reviews process.


The project follows a written organizational policy forperforming peer reviews. (L3-94, C1)

[Refer to Level 3 Policies for additional informationregarding PR policy.]

Adequate resources and funding are provided for performingpeer reviews on each software work product to be reviewed.(L3-95, Ab1)

Resources and funding are provided to:

q Prepare and distribute the peer review materials.

q Lead the peer review.

q Review the materials.

q Participate in the peer review and any follow-up reviewsrequired based on the defects identified in the peerreview.

q Monitor the rework of the software work product basedon the defects identified in the peer review.

q Collect and report the data resulting from the peerreviews.

Peer review leaders receive required training in how tolead peer reviews. (L3-95, Ab2)

Reviewers who participate in peer reviews receive requiredtraining in the objectives, principles, and methods of peerreviews. (L3-96, Ab3)


PR Process - Inputs

Inputs The table below lists the recommended inputs to the peer reviews process.


Checklists. (L3-98, A2, 5)

Peer review materials or review materials.(L3-95, Ab1, 1)

Software work product(s). (L3-94, C1, 4)

Standard set of software work products(identified in the organization’s standardsoftware process) that will undergo peerreview. (L3-94, C1, 1)


PR Process - Act iv i t ies

Activities The table below lists the recommended activities for the peer reviews process.


Peer reviews are planned, and the plans are documented.(L3-97, A1)

Peer reviews are performed according to a documentedprocedure. (L3-97, A2)


Data on the conduct and results of the peer reviews arerecorded. (L3-99, A3)

Measurements are made and used to determine the status ofthe peer review activities. (L3-99, M1)

The software quality assurance group reviews and/oraudits the activities and work products for peer reviews andreports the results. (L3-100, V1)

[Refer to PR Process Reviews and Audits for additionalinformation.]


PR Process - Outputs

Outputs The table below lists the recommended outputs produced by the peer reviewsprocess.


Actions identified in the peer reviews.(L3-98, A2, 6)

Checklists. (L3-98, A2, 5.1)

Completion criteria for the peer reviews.(L3-98, A2, 4)

Criteria for the review of the software workproducts. (L3-98, A2, 5)

Data on the conduct of the peer reviews.(L3-99, A3)

Data resulting from the peer reviews. (L3-95, Ab1, 6)

Defects identified in the peer review. (L3-95, Ab1, 4)

Issues in satisfying (readiness andcompletion) criteria for the peer reviews.(L3-98, A2, 4.1)

Measurements (to determine the status ofthe peer review activities). (L3-99, M1)

Plans for peer reviews. (L3-97, A1)

Readiness criteria for the peer reviews.(L3-98, A2, 4)

Results of peer reviews. (L3-94, C1, 5)

Results of SQA group reviews and/oraudits of the activities and work productsfor peer reviews. (L3-100, V1)

Schedule of peer reviews. (L3-97, A1, 2)

Software work products that will undergopeer review. (L3-94, C1, 2)


PR Process - Exi t Cr i ter ia

Output-basedentry criteria

The CMM recommends that outputs satisfy the states described in the table belowto exit the peer reviews process.


Actions identified inthe peer reviews

are tracked until they are resolved.(L3-98, A2, 6)

Checklists q are used to identify criteria forthe review of the software workproducts in a consistent manner.(L3-98, A2, 5)

q are tailored to the specifictype of work product andpeer review. (L3-98, A2,5.1)

q are reviewed by thechecklist developers' peersand potential users. (L3-98,A2, 5.2)

Completion criteriafor the peer reviews

q are specified. (L3-98, A2, 4)

q are enforced. (L3-98, A2, 4)

Data on the conductof the peer reviews

are recorded. (L3-99, A3)

Data resulting fromthe peer reviews

q are collected. (L3-95, Ab1, 6)

q are reported. (L3-95, Ab1, 6)


Issues in satisfying(readiness andcompletion) criteriafor the peer reviews

are reported to the appropriatemanagers. (L3-98, A2, 4.1)

Measurements (todetermine the statusof the peer reviewactivities)



Plans for peerreviews


q identify the software workproducts that will undergo peerreview. (L3-97, A1, 1)

q specify the schedule of peerreviews. (L3-97, A1, 2)

Readiness criteria forthe peer reviews

q are specified. (L3-98, A2, 4)

q are enforced. (L3-98, A2, 4)


PR Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the peer reviews process, continued from the previous page.


Results of the peerreviews

are not used by management toevaluate the performance ofindividuals. (L3-94, C1, 5)

Results of SQAgroup reviews and/oraudits of theactivities and workproducts for peerreviews


Schedule of peerreviews

are specified in the plans for peerreviews. (L3-97, A1, 2)

Software workproducts that willundergo peer review

q are identified by each project.(L3-94, C1, 2)

q include the set identified in theorganization’s standard softwareprocess. (L3-97, A1, 1.1)

The CMM recommends that the conditions described in the table below besatisfied to exit the peer reviews process.



Peer reviews are planned, and the plans are documented.(L3-97, A1)


Data on the conduct and results of the peer reviews arerecorded. (L3-99, A3)

The software quality assurance group reviews and/oraudits the activities and work products for peer reviews andreports the results. (L3-100, V1)


PR Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the peer reviewsprocess.


References

The checklists are reviewed by thechecklist developers' peers andpotential users. (L3-98, A2, 5.2)

Checklistdevelopers'peers

Checklistpotential users

The software quality assurance groupreviews and/or audits the activities andwork products for peer reviews and reportsthe results. (L3-100, V1)


q The planned peer reviews areconducted.

q The peer review leaders areadequately trained for their roles.

q The reviewers are properly trained orexperienced in their roles.

q The process for preparing for the peerreviews, conducting the peer reviews,and performing the follow-up actionsare followed.

q Reporting of peer review data iscomplete, accurate, and timely.



PR Process - Work Products Managed andContro l led


There are no work products recommended to be managed and controlled in thepeer reviews process.


PR Process - Measurements

Measurements The table below lists the measurements recommended for the peer reviewsprocess.


Data on the conduct and results of the peer reviews. (L3-99,A3)

Measurements to determine the status of the peer reviewactivities. (L3-99, M1)


q Number of peer reviews performed compared to theplan.

q Overall effort expended on peer reviews compared tothe plan.

q Number of work products reviewed compared to theplan.


PR Process - Documented Procedures


The table below lists the activities for the peer reviews process recommended tobe performed according to a documented procedure.





PR Process - T ra in ing

Training The table below lists the training recommended for the peer reviews process.

Training References

Peer review leaders receive required training in how tolead peer reviews. (L3-95, Ab2)

Reviewers who participate in peer reviews receive requiredtraining in the objectives, principles, and methods of peerreviews. (L3-96, Ab3)


PR Process - Too ls

Tools There are no tools recommended in the peer reviews process.



O v e r v i e w

This section describes all the explicit documented procedures in the CapabilityMaturity Model for maturity level 3.

Introduction







Organization process focus procedures L3-Procedures-2

Organization process definition procedure L3-Procedures-3

Training program procedure L3-Procedures-4

Integrated software management procedures L3-Procedures-5

Software product engineering procedures L3-Procedures-12

Intergroup coordination procedures L3-Procedures-13

Peer reviews procedure L3-Procedures-14

Note: The CMM does not recommend that any activities be performed accordingto a documented procedure for the organization process focus and softwareproduct engineering processes.


Organizat ion Process Focus (OPF) Procedures


The CMM does not recommend that any activities be performed according to adocumented procedure for the organization process focus process.


Organizat ion Process Def in i t ion (OPD) Procedure

Documentedprocedure

The table below lists the recommended documented procedure for theorganization process definition process.

Documented Procedure References



q The organization's standard software process satisfiesthe software policies, process standards, and productstandards imposed on the organization, as appropriate.

q The organization's standard software process satisfiesthe software process and product standards that arecommonly imposed on the organization's projects bytheir customers, as appropriate.

q State-of-the-practice software engineering tools andmethods are incorporated into the organization'sstandard software process, as appropriate.

q The internal process interfaces between the softwaredisciplines are described.

q The external process interfaces between the softwareprocess and the processes of other affected groups aredescribed.

q Changes proposed for the organization's standardsoftware process are documented, reviewed, andapproved by the group responsible for theorganization's software process activities (e.g.,software engineering process group) before they areincorporated.

q Plans for introducing changes to the software process ofongoing projects are defined as appropriate.

q The description of the organization's standard softwareprocess undergoes peer review when initially developedand whenever significant changes or additions are made.

q The description of the organization's standard softwareprocess is placed under configuration management.


Tra in ing Program (TP) P rocedure

Documentedprocedure

The table below lists the recommended documented procedure for the trainingprogram process.




q The plan uses the software projects' training needsidentified in their training plans.

q The specific training to be provided is identified basedon the skills needed by the organization and when thoseskills are needed.

q The organization's training plan is revised, asappropriate, to incorporate changes.

q The organization's training plan is reviewed by theaffected individuals when it is initially released andwhenever major revisions are made.

q The organization's training plan is managed andcontrolled.

q The organization's training plan is readily available tothe affected groups and individuals.


In tegra ted Sof tware Management ( ISM)Procedures


The table below lists the recommended documented procedures for the integratedsoftware management process.




q A software life cycle is:

q selected from among those approved by theorganization, to satisfy the project's contractual andoperational constraints;

q modified, if necessary, in ways permitted by theorganization's tailoring guidelines and criteria; and

q documented according to the organization'sstandards.

q The description of the project's defined software processis documented.

q Tailoring of the organization's standard software processfor the project is reviewed by the group responsiblefor coordinating the organization's software processactivities (e.g., software engineering process group)and approved by senior management.

q Waivers for deviations from the organization'sstandard software process are documented and arereviewed and approved by senior management.

q Waivers for deviations from contractual softwareprocess requirements are documented and are reviewedand approved by senior management and the softwareproject's customer, as appropriate.

q The description of the project's defined software processis managed and controlled.



In tegra ted Sof tware Management ( ISM)Procedures , Continued


The table below lists the recommended documented procedures for the integratedsoftware management process, continued from the previous page.




q Changes derived from the following are documented andsystematically reviewed:

q lessons learned from monitoring the softwareactivities of the organization's projects,

q changes proposed by the software project, and

q process and work product measurement data.

q Changes to the project's defined software process arereviewed and approved before they are incorporated.










q A group that is independent of the softwareengineering group reviews the procedures forestimating the size of the software work products, andprovides guidance in using historical data from theorganization's software process database to establishcredible estimates.

q The individuals who prepare the size estimatesensure that the procedures and data used in theestimates are appropriate.

q When the validity of a size estimate is questioned,a team of peers and experts reviews the estimate.

q A contingency factor is applied to the size estimate foreach software element identified as a software risk.

q The rationale for the contingency is documented.

q The risks associated with reducing or eliminatingthe contingency are assessed and documented.

q Off-the-shelf or reusable software components areidentified.

q Reuse measurements account for the reuse ofrequirements, design, code, test plan, and testprocedures, etc.

q The effort to modify and incorporate reusablecomponents is factored into the size estimates.

q Factors which could significantly affect the size of thesoftware work products are identified and monitoredclosely.

q A size threshold is established for each managedsoftware element which, when projected to beexceeded, requires action.









q Software effort, cost, and staffing profile models, ifused, are adapted to the project and use availablehistorical data where appropriate.

q Referenced productivity and cost data are adjusted toincorporate project variables.

q The overall software effort and cost is allocated toindividually managed tasks or stages as needed tomanage the effort and cost effectively.

q When the software effort and cost status is reviewed andthe estimates are revised, actual expenditures over timeand against work completed are compared to thesoftware development plan and used to refine the effortand cost estimates for remaining work.

q Parameter values of the models used in estimatingsoftware effort and costs are updated whenevermajor changes are made to the softwarerequirements.

q Actual data on project productivity and other newsoftware costs are used where appropriate.

q An effort and cost threshold is established for eachindividually managed software task or stage which,when projected to be exceeded, requires action.







The project's critical computer resources are managedaccording to a documented procedure. (L3-50, A8)This procedure typically specifies that:q Estimates for the project's critical computer resources

are derived based on historical experience, simulations,prototyping, or analysis, as appropriate.

q Sources and rationale for estimates are documented.

q Similarities and differences between the project andthe sources for historical data in terms of applicationdomain and design approach are assessed andrecorded.

q The reasoning used to judge the credibility of theestimates is recorded.

q The planned computer resources, the systemrequirements allocated to software, the softwarerequirements, and/or the software design are adjusted toachieve the project's critical computer resourcerequirements.

q The available computer resources are allocated to thesoftware components.

q The available capacity for the critical computerresources provides for a specified reserve capacity whenthe initial estimates are made.

q A threshold is established for each critical computerresource which, when projected to be exceeded,requires action.









q Milestones, tasks, commitments, critical dependencies,staffing, costs, and reviews are allocated in theschedule consistent with the project's defined softwareprocess.

q The software schedule identifies specific tasks andmilestones whose completion can be objectivelydetermined (i.e., a binary or yes/no determination).

q Critical dependencies are defined, negotiated, andreflected in the software schedule.

q Schedule critical paths are defined and reflected in thesoftware schedule.

q The software project's critical dependencies andschedule critical paths are tracked on a regular basis.

q Specific documented threshold criteria are establishedfor each critical path which, when projected to beexceeded, require action.









q A software risk management plan is documented andused to identify and manage the software risks.

q Contingency planning is based on the project's definedsoftware process and is performed throughout theproject's software life cycle.

q Alternatives for each software risk are defined, wherepossible, along with criteria for selecting among thealternatives.

q The initial release and major revisions to the softwarerisk management plan undergo peer review.

q The software risk management plan is managed andcontrolled.

q Software risks are tracked, reassessed, and replanned atselected project milestones, at designated riskcheckpoints, and during the planning of significantchanges that affect the software project.

q Risk priorities and software risk management plansare reviewed and revised at these reassessmentpoints.

q Information obtained from monitoring the risks isused to refine the risk assessments and software riskmanagement plans.

q The software engineering group and other affectedgroups and individuals are included in thecommunications on the software risks, the software riskmanagement plans, and the results of risk mitigation.


Sof tware Product Engineer ing (SPE) Procedures


The CMM does not recommend that any activities be performed according to adocumented procedure for the software product engineering process.


In tergroup Coord inat ion ( IC) Procedures


The table below lists the recommended documented procedures for the intergroupcoordination process.




q Each critical dependency is explicitly defined,including:

q the item to be provided,

q who will provide it,

q when it will be provided, and

q the criteria for acceptance.

q Critical dependencies are negotiated between thesoftware engineering group and other engineeringgroups in the project and organization.

q Need dates and availability dates of critical dependencyitems are tied to the project schedule and the softwareschedule.

q The agreement for each critical dependency isdocumented, reviewed, and approved by both thereceiving group and the group responsible forproviding the critical dependency item.

q Critical dependencies are tracked on a regular basis andcorrective actions are taken when appropriate.

q Status and actual or projected completion arecompared to the plan used to coordinate intergroupcommitments.

q Effects of late and early completions are evaluatedfor impacts on future activities and milestones.

q Actual and potential problems are reported to theappropriate managers.



P e e r R e v i e w s ( P R ) P r o c e d u r e

Documentedprocedure

The table below lists the recommended documented procedure for the peerreviews process.




q Peer reviews are planned and led by trained peerreview leaders.

q Review materials are distributed to the reviewers inadvance so they can adequately prepare for the peerreview.

q Reviewers have assigned roles in peer reviews.

q Readiness and completion criteria for the peer reviewsare specified and enforced.

q Issues in satisfying these criteria are reported to theappropriate managers.

q Checklists are used to identify criteria for the review ofthe software work products in a consistent manner.

q The checklists are tailored to the specific type ofwork product and peer review.

q The checklists are reviewed by the checklistdevelopers' peers and potential users.

q Actions identified in the peer reviews are tracked untilthey are resolved.

q The successful completion of peer reviews, includingthe rework to address the items identified in the peerreviews, is used as a completion criterion for theassociated task.


Level 3 Summary

Overview

The purpose of this section is to provide checklists that provide a summary of thedefined level (level 3). This section contains three perspectives of a CMM level.

Section purpose





Topic Page














Level 3 KPApurposes



OPF The purpose of Organization Process Focus is to establish theorganizational responsibility for software process activities thatimprove the organization's overall software process capability. (L3-1)

OPD The purpose of Organization Process Definition is to develop andmaintain a usable set of software process assets that improve processperformance across the projects and provide a basis for cumulative,long-term benefits to the organization. (L3-11)

TP The purpose of the Training Program key process area is to develop theskills and knowledge of individuals so they can perform their roleseffectively and efficiently. (L3-25)

ISM The purpose of Integrated Software Management is to integrate thesoftware engineering and management activities into a coherent,defined software process that is tailored from the organization'sstandard software process and related process assets, which aredescribed in Organization Process Definition. (L3-37)

SPE The purpose of Software Product Engineering is to consistentlyperform a well-defined engineering process that integrates all thesoftware engineering activities to produce correct, consistent softwareproducts effectively and efficiently. (L3-59)

IC The purpose of Intergroup Coordination is to establish a means for thesoftware engineering group to participate actively with the otherengineering groups so the project is better able to satisfy the customer'sneeds effectively and efficiently. (L3-83)

PR The purpose of Peer Reviews is to remove defects from the softwarework products early and efficiently. An important corollary effect is todevelop a better understanding of the software work products and ofdefects that might be prevented. (L3-93)


Level 3 - KPA Goals

Level 3 KPAgoals



OPF Software process development and improvementactivities are coordinated across the organization. (L3-1, G1)

OPF The strengths and weaknesses of the softwareprocesses used are identified relative to the processstandard. (L3-2, G2)

OPF Organization-level process development andimprovement activities are planned. (L3-2, G3)

OPD A standard software process for the organization isdeveloped and maintained. (L3-12, G1)

OPD Information related to the use of the organization’sstandard software process by the software projects iscollected, reviewed, and made available. (L3-12, G2)

TP Training activities are planned. (L3-25, G1)

TP Training for developing the skills and knowledgeneeded to perform software management and technicalroles is provided. (L3-25, G2)

TP Individuals in the software engineering group andsoftware-related groups receive the trainingnecessary to perform their roles. (L3-26, G3)

ISM The project's defined software process is a tailoredversion of the organization's standard software process.(L3-38, G1)

ISM The project is planned and managed according to theproject's defined software process. (L3-38, G2)

SPE The software engineering tasks are defined, integrated,and consistently performed to produce the software.(L3-60, G1)

SPE Software work products are kept consistent with eachother. (L3-60, G2)

IC The customer's requirements are agreed to by allaffected groups. (L3-84, G1)

IC The commitments between the engineering groupsare agreed to by the affected groups. (L3-84, G2)

IC The engineering groups identify, track, and resolveintergroup issues. (L3-84, G3)

PR Peer reviews are planned. (L3-93, G1)


PR Defects in the software work products are identifiedand removed. (L3-93, G2)


Level 3 - Policies



OPF Written organizational policy for coordinating softwareprocess development and improvement activitiesacross the organization. (L3-2, C1)

OPD Written policy for developing and maintaining astandard software process and related process assets.(L3-12, C1)

TP Written policy for meeting the organization’s trainingneeds. (L3-26, C1)

ISM Written organizational policy requiring that thesoftware project be planned and managed using theorganization's standard software process and relatedprocess assets. (L3-38, C1)

SPE Written organizational policy for performing thesoftware engineering activities. (L3-60, C1)

IC Written organizational policy for establishinginterdisciplinary engineering teams. (L3-84, C1)

PR Written organizational policy for performing peerreviews. (L3-94, C1)


Level 3 - Standards

Level 3standards



OPF Action plan. (L3-6, A1)

OPF Software development and improvement plan. (L3-7,A2)

OPD Organization’s standard software process. (L3-17, A2)

OPD Software process element. (L3-17, A2, 2)

OPD Tailoring guidelines and criteria (for projects’ tailoringof the organization’s standard software process). (L3-19, A4, 1)

TP Software project’s training plan. (L3-29, A1)

TP Organization’s training plan. (L3-32, A3)

TP Organizational standards for training courses. (L3-33,A4)

ISM Project’s defined software process. (L3-44, A4)

SPE Software design documentation. (L3-71, A3, 8.1)

SPE Test plan. (L3-75, A7, 2)

IC Documented plan for intergroup commitments. (L3-88, A3)

PR Plans for peer reviews. (L3-97, A1)


Reference



OPF processdescription

Organization Process Focus involves developing and maintaining an understanding ofthe organization's and projects' software processes and coordinating the activities toassess, develop, maintain, and improve these processes.

The organization provides the long-term commitments and resources to coordinate thedevelopment and maintenance of the software processes across current and futuresoftware projects via a group such as a software engineering process group. Thisgroup is responsible for the organization's software process activities. It is specificallyresponsible for the development and maintenance of the organization's standardsoftware process and related process assets (as described in the Organization ProcessDefinition key process area), and it coordinates the process activities with the softwareprojects. (L3-1)

OPD processdescription

Organization Process Definition involves developing and maintaining theorganization's standard software process, along with related process assets, such asdescriptions of software life cycles, process tailoring guidelines and criteria, theorganization's software process database, and a library of software process-relateddocumentation.

These assets may be collected in many ways, depending on the organization'simplementation of Organization Process Definition. For example, the descriptions ofthe software life cycles may be an integral part of the organization's standard softwareprocess or parts of the library of software process-related documentation may bestored in the organization's software process database.

The organization's software process assets are available for use in developing,implementing, and maintaining the projects' defined software processes. (Thepractices related to the development and maintenance of the project's defined softwareprocess are described in the Integrated Software Management key process area.) (L3-11)




TP processdescription

Training Program involves first identifying the training needed by the organization,projects, and individuals, then developing or procuring training to address theidentified needs.

Each software project evaluates its current and future skill needs and determines howthese skills will be obtained. Some skills are effectively and efficiently impartedthrough informal vehicles (e.g., on-the-job training and informal mentoring), whereasother skills need more formal training vehicles (e.g., classroom training and guidedself-study) to be effectively and efficiently imparted. The appropriate vehicles areselected and used.

This key process area covers the practices for the group performing the trainingfunction. The practices identifying the specific training topics (i.e., knowledge or skillneeded) are contained in the Ability to Perform common feature of the individual keyprocess areas. (L3-25)

ISM processdescription

Integrated Software Management involves developing the project's defined softwareprocess and managing the software project using this defined software process. Theproject's defined software process is tailored from the organization's standard softwareprocess to address the specific characteristics of the project.

The software development plan is based on the project's defined software process anddescribes how the activities of the project's defined software process will beimplemented and managed. The management of the software project's size, effort,cost, schedule, staffing, and other resources is tied to the tasks of the project's definedsoftware process.

Since the projects' defined software processes are all tailored from the organization'sstandard software process, the software projects can share process data and lessonslearned.

The basic practices for estimating, planning, and tracking a software project aredescribed in the Software Project Planning and Software Project Tracking andOversight key process areas. They focus on recognizing problems when they occurand adjusting the plans and/or performance to address the problems. The practices ofthis key process area build on, and are in addition to, the practices of those two keyprocess areas. The emphasis of Integrated Software Management shifts to anticipatingproblems and acting to prevent or minimize the effects of these problems. (L3-37)




SPE processdescription

Software Product Engineering involves performing the engineering tasks to build andmaintain the software using the project's defined software process (which is describedin the Integrated Software Management key process area) and appropriate methodsand tools.

The software engineering tasks include analyzing the system requirements allocated tosoftware (these system requirements are described in the Requirements Managementkey process area), developing the software requirements, developing the softwarearchitecture, designing the software, implementing the software in the code,integrating the software components, and testing the software to verify that it satisfiesthe specified requirements (i.e., the system requirements allocated to software and thesoftware requirements).

Documentation needed to perform the software engineering tasks (e.g., softwarerequirements document, software design document, test plan, and test procedures) isdeveloped and reviewed to ensure that each task addresses the results of predecessortasks and the results produced are appropriate for the subsequent tasks (including thetasks of operating and maintaining the software). When changes are approved,affected software work products, plans, commitments, processes, and activities arerevised to reflect the approved changes. (L3-59)

IC processdescription

Intergroup Coordination involves the software engineering group's participation withother project engineering groups to address system-level requirements, objectives, andissues. Representatives of the project's engineering groups participate in establishingthe system-level requirements, objectives, and plans by working with the customer andend users, as appropriate. These requirements, objectives, and plans become the basisfor all engineering activities.

The technical working interfaces and interactions between groups are planned andmanaged to ensure the quality and integrity of the entire system. Technical reviewsand interchanges are regularly conducted with representatives of the project'sengineering groups to ensure that all engineering groups are aware of the status andplans of all the groups, and that system and intergroup issues receive appropriateattention.

The software-specific practices related to these engineering tasks are described in theRequirements Management and Software Product Engineering key process areas.(L3-83)


PR processdescription

Peer Reviews involve a methodical examination of software work products by theproducers' peers to identify defects and areas where changes are needed. The specificproducts that will undergo a peer review are identified in the project's defined softwareprocess and scheduled as part of the software project planning activities, as describedin Integrated Software Management.

This key process area covers the practices for performing peer reviews. The practicesidentifying the specific software work products that undergo peer review are containedin the key process areas that describe the development and maintenance of eachsoftware work product. (L3-93)



Level 3procedures

The table below lists the activities that are recommended to be performed according toa documented procedure in the CMM at level 3. Refer to the Level 3 ProcedureChecklists for additional information regarding the content of each documentedprocedure.


OPF There are no activities that are recommended to beperformed according to a documented procedure in theorganizational process focus process.

OPD The organization's standard software process isdeveloped and maintained according to a documentedprocedure. (L3-15, A1)

TP The organization's training plan is developed andrevised according to a documented procedure. (L3-30,A2)

ISM The project's defined software process is developed bytailoring the organization's standard software processaccording to a documented procedure. (L3-41, A1)

ISM Each project's defined software process is revisedaccording to a documented procedure. (L3-43, A2)

ISM The project's software development plan, whichdescribes the use of the project's defined softwareprocess, is developed and revised according to adocumented procedure. (L3-44, A3)

ISM The size of the software work products (or size ofchanges to the software work products) is managedaccording to a documented procedure. (L3-47, A6)

ISM The project's software effort and costs are managedaccording to a documented procedure. (L3-48, A7)

ISM The project's critical computer resources are managedaccording to a documented procedure. (L3-50, A8)

ISM The critical dependencies and critical paths of theproject's software schedule are managed according to adocumented procedure. (L3-51, A9)

ISM The project's software risks are identified, assessed,documented, and managed according to a documentedprocedure. (L3-52, A10)

SPE There are no activities that are recommended to beperformed according to a documented procedure in thesoftware product engineering process.







IC Critical dependencies between engineering groups areidentified, negotiated, and tracked according to adocumented procedure. (L3-89, A4)

IC Intergroup issues not resolvable by the individualrepresentatives of the project engineering groupsare handled according to a documented procedure.(L3-90, A6)

PR Peer reviews are performed according to a documentedprocedure. (L3-97, A2)


Level 3 - Training



OPF Members of the group responsible for theorganization’s software process activities receiverequired training to perform these activities. (L3-5,Ab3)

OPF Members of the software engineering group andother software-related groups receive orientation onthe organization’s software process activities and theirroles in those activities. (L3-6, Ab4)

OPF Training for the organization’s and projects’ softwareprocesses is coordinated across the organization. (L3-8, A6)

OPD The individuals who develop and maintain theorganization's standard software process andrelated process assets receive required training toperform these activities. (L3-14, Ab2)

TP Training is provided to build the skill base of theorganization, to fill the specific needs of the projects,and to develop the skills of individuals. (L3-26, C1, 3)

TP Software managers receive orientation on the trainingprogram. (L3-29, Ab4)

ISM The individuals responsible for developing theproject's defined software process receive requiredtraining in how to tailor the organization's standardsoftware process and use the related process assets.(L3-39, Ab2)

ISM The software managers receive required training inmanaging the technical, administrative, and personnelaspects of the software project based on the project'sdefined software process. (L3-40, Ab3)

SPE Members of the software engineering technical staffreceive required training to perform their technicalassignments. (L3-63, Ab2)

SPE Members of the software engineering technical staffreceive orientation in related software engineeringdisciplines. (L3-64, Ab3)

SPE The project manager and all software managersreceive orientation in the technical aspects of thesoftware project. (L3-64, Ab4)

IC All managers in the organization receive requiredtraining in teamwork. (L3-85, Ab3)


Level 3 - Training, Continued

Level 3training,continued

The table below lists the training recommended in the CMM at level 3, continued fromthe previous page.


IC All task leaders in each engineering group receiveorientation in the processes, methods, and standardsused by the other engineering groups. (L3-86, Ab4)

IC The members of the engineering groups receiveorientation in working as a team. (L3-86, Ab5)

PR Peer review leaders receive required training in howto lead peer reviews. (L3-95, Ab2)

PR Reviewers who participate in peer reviews receiverequired training in the objectives, principles, andmethods of peer reviews. (L3-96, Ab3)


Level 3 - Tools



OPF Tools to support the organization’s software processactivities. (L3-5, Ab2, 2)

OPD Tools to support process development andmaintenance. (L3-14, Ab1, 2)

OPD State-of-the-practice software engineering tools. (L3-15, A1, 3)

OPD Organization’s software process database. (L3-20, A5)

TP Tools to support the training program activities. (L3-28, Ab2, 2)

ISM Organization's software process database. (L3-39, C1,4)

SPE Tools to build and maintain the software products.(L3-60, C1, 2)

SPE Tools to support the software engineering tasks. (L3-61, Ab1, 2)

SPE Software engineering tools. (L3-65, A1)

SPE Tools to develop the documentation. (L3-76, A8, 1)

IC Support tools used by the different engineering groups.(L3-85, Ab2)

PR There are no tools specified in the peer reviewsprocess.






References

OPF The plan for organizational softwareprocess development andimprovement activities undergoes peerreview when initially released andwhenever major revisions are made.(L3-7, A2, 5)


OPF The plan for organizational softwareprocess development andimprovement activities is reviewedand agreed to by the organization'ssoftware managers and seniormanagers. (L3-7, A2, 6)

Softwaremanagers

Seniormanagers

OPF The activities for software processdevelopment and improvement arereviewed with senior management ona periodic basis. (L3-10, V1)

Seniormanagement

OPF Progress and status of the activities todevelop and improve the softwareprocess are reviewed against the plan.(L3-10, V1, 1)


OPD Changes proposed for theorganization's standard softwareprocess are documented, reviewed,and approved by the groupresponsible for the organization'ssoftware process activities (e.g.,software engineering process group)before they are incorporated. (L3-16,A1, 6)

Groupresponsiblefor theorganiza-tion'ssoftwareprocessactivities

OPD The description of the organization'sstandard software process undergoespeer review when initially developedand whenever significant changes oradditions are made. (L3-16, A1, 8)


OPD Changes proposed for the descriptionsof software life cycles aredocumented, reviewed, and approvedby the group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) before they areincorporated. (L3-18, A3, 2)







References

OPD The descriptions of the software lifecycles undergo peer review wheninitially documented and wheneversignificant changes or additions aremade. (L3-19, A3, 3)


OPD Changes proposed for the tailoringguidelines and criteria aredocumented, reviewed, and approvedby the group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) before they areincorporated. (L3-20, A4, 2)


OPD The data entered into the(organization's software process)database are reviewed to ensure theintegrity of the database contents.(L3-21, A5, 2)


OPD Candidate (software process-related)documentation items are reviewed andappropriate items that may be useful inthe future are included in the library.(L3-21, A6, 1)


OPD Revisions made to (software process-related) documentation items currentlyin the library are reviewed, and thelibrary contents are updated asappropriate. (L3-22, A6, 3)


OPD The use of each (software process-related) documentation item isreviewed periodically, and the resultsare used to maintain the librarycontents. (L3-22, A6, 5)








References

OPD The software quality assurancegroup reviews and/or audits theorganization's activities and workproducts for developing andmaintaining the organization'sstandard software process and relatedprocess assets and reports the results.(L3-23, V1)


TP The organization's training plan isreviewed by the affected individualswhen it is initially released andwhenever major revisions are made.(L3-31, A2, 4)

Affectedindividuals

TP The materials for the training courseare reviewed. (L3-33, A4, 2)


TP The training program activities arereviewed with senior management ona periodic basis. (L3-35, V1)

Seniormanagement

TP The training program is independentlyevaluated on a periodic basis forconsistency with, and relevance to, theorganization's needs. (L3-36, V2)


TP The training program activities andwork products are reviewed and/oraudited and the results are reported.(L3-36, V3)


ISM Tailoring of the organization'sstandard software process for theproject is reviewed by the groupresponsible for coordinating theorganization's software processactivities (e.g., software engineeringprocess group) and approved bysenior management. (L3-42, A1, 3)


Seniormanagement


ISM Waivers for deviations from theorganization's standard softwareprocess are documented and arereviewed and approved by seniormanagement. (L3-42, A1, 3.1)

Seniormanagement







References

ISM Waivers for deviations fromcontractual software processrequirements are documented and arereviewed and approved by seniormanagement and the softwareproject's customer, as appropriate.(L3-42, A1, 4)

Seniormanagement

Customer

ISM Changes derived from the followingare documented and systematicallyreviewed: (L3-43, A2, 1)

q lessons learned from monitoringthe software activities of theorganization's projects,

q changes proposed by the softwareproject, and

q process and work productmeasurement data.


ISM Changes to the project's definedsoftware process are reviewed andapproved before they are incorporated.(L3-43, A2, 2)


ISM Technical and management lessonslearned from monitoring the activitiesof other projects in the organizationare systematically reviewed and usedto estimate, plan, track, and replan thesoftware project. (L3-45, A4, 6)


ISM A group that is independent of thesoftware engineering group reviewsthe procedures for estimating the sizeof the software work products, andprovides guidance in using historicaldata from the organization's softwareprocess database to establish credibleestimates. (L3-47, A6, 1)

Group that isindependentof thesoftwareengineeringgroup

ISM When the validity of a size estimate isquestioned, a team of peers andexperts reviews the estimate. (L3-48,A6, 1.2)

Team ofpeers andexperts






References

ISM When the software effort and coststatus is reviewed and the estimatesare revised, actual expenditures overtime and against work completed arecompared to the software developmentplan and used to refine the effort andcost estimates for remaining work.(L3-49, A7, 4)


ISM The initial release and major revisionsto the software risk management planundergo peer review. (L3-54, A10, 4)


ISM Risk priorities and software riskmanagement plans are reviewed andrevised at these reassessment points (atselected project milestones, atdesignated risk checkpoints, andduring the planning of significantchanges that affect the softwareproject). (L3-55, A10, 6.1)


ISM Reviews of the software project areperiodically performed to determinethe actions needed to bring thesoftware project's performance andresults in line with the current andprojected needs of the business,customer, and end users, asappropriate. (L3-55, A11)


ISM The activities for managing thesoftware project are reviewed withsenior management on a periodicbasis. (L3-56, V1)

Seniormanagement

ISM The activities for managing thesoftware project are reviewed with theproject manager on both a periodicand event-driven basis. (L3-57, V2)

Projectmanager

ISM The software quality assurancegroup reviews and/or audits theactivities and work products formanaging the software project andreports the results. (L3-57, V3)







References

SPE The individuals involved indeveloping the softwarerequirements review the allocatedrequirements to ensure that issuesaffecting the software requirementsanalysis are identified and resolved.(L3-66, A2, 1)

Individualsinvolved indevelopingthe softwarerequirements

SPE Problems with the softwarerequirements are identified andreviewed with the group responsiblefor the system requirements;appropriate changes are made to theallocated requirements and to thesoftware requirements. (L3-67, A2,4.1)

Groupresponsiblefor thesystemrequirements

SPE The software requirements documentundergoes peer review before it isconsidered complete. (L3-68, A2, 8)


SPE The software requirements documentis reviewed and approved. (L3-68,A2, 9)


SPE The software requirements documentis reviewed with the customer andend users, as appropriate. (L3-68, A2,10)

Customer

End users

SPE Design criteria are developed andreviewed. (L3-69, A3, 1)


SPE The individuals involved in thesoftware design review the softwarerequirements to ensure that issuesaffecting the software design areidentified and resolved. (L3-69, A3,2)

Individualsinvolved inthe softwaredesign

SPE The software architecture is reviewedto ensure that architecture issuesaffecting the software detailed designare identified and resolved. (L3-70,A3, 6)








References

SPE The software design documentundergoes peer review before thedesign is considered complete. (L3-71, A3, 9)


SPE The individuals involved in codingreview the software requirements andsoftware design to ensure that issuesaffecting the coding are identified andresolved. (L3-71, A4, 1)


SPE Each code unit undergoes peer reviewand is unit tested before the unit isconsidered complete. (L3-72, A4, 4)


SPE Testing criteria are developed andreviewed with the customer and theend users, as appropriate. (L3-72, A5,1)

Customer

End users

SPE The test plan, test procedures, and testcases undergo peer review before theyare considered ready for use. (L3-74,A5, 6)


SPE The integration test cases and testprocedures are reviewed with theindividuals responsible for thesoftware requirements, softwaredesign, and system and acceptancetesting. (L3-75, A6, 2)

Individualsresponsiblefor thesoftwarerequire-ments,softwaredesign, andsystem andacceptancetesting

SPE System and acceptance testing aredocumented in a test plan, which isreviewed with, and approved by, thecustomer and end users, asappropriate. (L3-75, A7, 2)

Customer

End users







References

SPE The test cases are documented and arereviewed with, and approved by, thecustomer and end users, asappropriate, before the testing begins.(L3-76, A7, 4)

Customer

End users

SPE Preliminary versions of thedocumentation (that will be used tooperate and maintain the software) aredeveloped and made available early inthe software life cycle for thecustomer, end users, and softwaremaintainers, as appropriate, to reviewand provide feedback. (L3-77, A8, 3)

Customer

End users

Softwaremaintainers

SPE The documentation (that will be usedto operate and maintain the software)undergoes peer review. (L3-77, A8, 5)


SPE The final documentation (that will beused to operate and maintain thesoftware) is reviewed and approved bythe customer, end users, andsoftware maintainers, as appropriate.(L3-77, A8, 7)

Customer

End users

Softwaremaintainers

SPE The activities for software productengineering are reviewed with seniormanagement on a periodic basis.(L3-80, V1)

Seniormanagement

SPE The activities for software productengineering are reviewed with theproject manager on both a periodicand event-driven basis. (L3-80, V2)

Projectmanager

SPE The software quality assurancegroup reviews and/or audits theactivities and work products forsoftware product engineering andreports the results. (L3-81, V3)


IC The system requirements and project-level objectives for the project aredefined and reviewed by all affectedgroups. (L3-84, C1, 1)

Affectedgroups






References

IC Representatives of the project'ssoftware engineering group andrepresentatives of the otherengineering groups provide thetechnical review and approval of thesystem requirements and systemdesign. (L3-87, A2, 1.1)



IC Representatives of the project'ssoftware engineering group andrepresentatives of the otherengineering groups provide theproject-level technical review andanalysis needed to manage and controlchanges to the system requirementsand project-level objectivesthroughout the project's life cycle.(L3-87, A2, 1.2)



IC Representatives of the project'ssoftware engineering group andrepresentatives of the otherengineering groups track and reviewthe design and development activitiesfor hardware, software, and othersystem components. (L3-88, A2, 1.3)



IC The documented plan used tocommunicate intergroup commitmentsand to coordinate and track the workperformed is reviewed and agreed toby all engineering groups and theproject manager. (L3-89, A3, 6)

Engineeringgroups

Projectmanager






References

IC The agreement for each criticaldependency is documented, reviewed,and approved by both the receivinggroup and the group responsible forproviding the critical dependencyitem. (L3-89, A4, 4)

Receivinggroup (of thecriticaldependencyitem)


IC Work products produced as input toother engineering groups are reviewedby representatives of the receivinggroups to ensure that the workproducts meet their needs. (L3-90,A5)

Representa-tives of thereceivinggroups

IC Representatives of the projectengineering groups conduct periodictechnical reviews and interchanges.(L3-90, A7)


IC The activities for intergroupcoordination are reviewed with seniormanagement on a periodic basis.(L3-91, V1)

Seniormanagement

IC The activities for intergroupcoordination are reviewed with theproject manager on both a periodicand event-driven basis. (L3-92, V2)

Projectmanager

IC The software quality assurancegroup reviews and/or audits theactivities and work products forintergroup coordination and reports theresults. (L3-92, V3)








References

PR The checklists are reviewed by thechecklist developers' peers andpotential users. (L3-98, A2, 5.2)

Checklistdevelopers'peers

Checklistpotentialusers

PR The software quality assurancegroup reviews and/or audits theactivities and work products for peerreviews and reports the results. (L3-100, V1)







OPF There are no work products recommended to bemanaged and controlled in the organizational processfocus process.

OPD Description of the organization's standard softwareprocess.* (L3-17, A1, 9)

OPD Descriptions of the software life cycles. (L3-19, A3,4)

OPD Tailoring guidelines and criteria (for the project’stailoring of the organization’s standard softwareprocess. (L3-20, A4, 3)

OPD Organization's software process database. (L3-21, A5,3)

OPD Library of software process-related documentation.(L3-21, A6, 6)

TP The organization's training plan. (L3-31, A2, 5)

TP The materials for the training courses. (L3-34, A4, 3)

ISM Description of the project's defined software process.(L3-42, A1, 5)

ISM Software risk management plan. (L3-54, A10, 5)

SPE Tools used to develop and maintain the softwareproducts.* (L3-66, A1, 4)

SPE Software requirements document.* (L3-69, A2, 11)

SPE Software design document.* (L3-71, A3, 10)

SPE Code.* (L3-72, A4, 5)

SPE Test plans, test procedures, and test cases. (L3-74, A5,7)

SPE Test results. (L3-76, A7, 8)

SPE Documentation (that will be used to operate andmaintain the software). (L3-77, A8, 6)

SPE Documentation tracing the allocated requirementsthrough the software requirements, design, code, andtest cases. (L3-78, A10, 3)

*Indicates that the CMM recommends that this item must be placed underconfiguration management


Level 3 - Work Products Managed and Controlled, Continued

Level 3 workproductsmanaged andcontrolled,continued

The table below lists the work products that are recommended to be managed andcontrolled in the CMM at level 3, continued from the previous page.


IC There are no work products recommended to bemanaged and controlled in the intergroup coordinationprocess.

PR There are no work products recommended to bemanaged and controlled in the peer reviews process.



Level 3measurements



OPF Measurements to determine the status of theorganization’s process development and improvementactivities. (L3-9, M1)

OPD Data on the resulting work products (from the softwareprocesses). (L3-20, A5, 1)

OPD Data on the software processes. (L3-20, A5, 1)

OPD Measurements to determine the status of theorganization's process definition activities. (L3-22,M1)

TP Measurements to determine the status of the trainingprogram activities. (L3-34, M1)

TP Measurements to determine the quality of the trainingprogram. (L3-35, M2)

ISM Project measurement data. (L3-39, C1, 4)

ISM Process and work product measurement data. (L3-43,A2, 1.3)

ISM Measurement data needed to manage the softwareproject. (L3-44, A4, 1)

ISM Software planning data, replanning data, and actualmeasured data. (L3-47, A5, 3)

ISM Reuse measurements (reuse of requirements, design,code, test plan, and test procedures, etc.). (L3-48, A6,3.1)

ISM Measurements to determine the effectiveness of theintegrated software management activities. (L3-56,M1)

SPE Data on defects identified in peer reviews. (L3-78,A9)

SPE Data on defects identified in testing. (L3-78, A9)

SPE Measurements to determine the functionality andquality of the software products. (L3-79, M1)

SPE Measurements to determine the status of the softwareproduct engineering activities. (L3-80, M2)

IC Measurements to determine the status of the intergroupcoordination activities. (L3-91, M1)

PR Data on the conduct and results of the peer reviews.(L3-99, A3)


PR Measurements to determine the status of the peerreview activities. (L3-99, M1)


C h a p t e r 6 . M a n a g e d L e v e l ( L e v e l 4 )

O v e r v i e w

This chapter contains the checklists for level 4 of the CMM.Introduction


Section Title Page








O v e r v i e w












Policies See Page

Quantitative process management policies L4-Policy-2

Software quality management policy L4-Policy-3


Quant i ta t ive Process Management (QPM) Pol ic ies

QPM policy 1checklist

The project follows a written organizational policy for measuring andquantitatively controlling the performance of the project's defined software process(L4-2, C1). This policy typically specifies that:


Each project implements a documented plan to bring theproject's defined software process under quantitative control.(L4-2, C1, 1)

Sensitive data relating to individuals' performance areprotected, and access to these data is appropriatelycontrolled. (L4-3, C1, 2)

The organization follows a written policy for analyzing the process capability ofthe organization's standard software process (L4-3, C2). This policy typicallyspecifies that:

QPM policy 2checklist


The projects' measurements of process performance areanalyzed to establish and maintain a process capabilitybaseline for the organization's standard software process.(L4-3, C2, 1)

The process capability baseline for the organization'sstandard software process is used by the software projects inestablishing their process performance goals. (L4-4, C2, 2)

Implementation of effective quantitative process management policies has thefollowing results:

QPM policygoals

Results of Effectively Implementing QPM Policies References

The quantitative process management activities areplanned. (L4-2, G1)

The process performance of the project's defined softwareprocess is controlled quantitatively. (L4-2, G2)

The process capability of the organization's standardsoftware process is known in quantitative terms. (L4-2, G3)


Sof tware Qual i ty Management (SQM) Pol icy

The project follows a written organizational policy for managing software quality(L4-20, C1). This policy typically specifies that:

SQM policychecklist


The project's software quality management activitiessupport the organization's commitment to improve thequality of the software products. (L4-20, C1, 1)

The project defines and collects the measurements used forsoftware quality management based on the project's definedsoftware process. (L4-20, C1, 2)

The project defines the quality goals for the softwareproducts and monitors its progress towards them. (L4-20,C1, 3)

Responsibilities for software quality management aredefined and assigned to the software engineering groupand other software-related groups. (L4-21, C1, 4)

Criteria are established to enable the groups (softwareengineering group and other software-related groups) todetermine their success in achieving the quality goals forthe software products. (L4-21, C1, 4.1)

Implementation of an effective software quality management policy has thefollowing results:

SQM policygoals

Results of Effectively Implementing SQM Policy References

The project's software quality management activities areplanned. (L4-20, G1)

Measurable goals for software product quality and theirpriorities are defined. (L4-20, G2)

Actual progress toward achieving the quality goals for thesoftware products is quantified and managed. (L4-20, G3)



O v e r v i e w


A standards checklist describes the content of a work product as recommended bythe CMM.

Definition









Project's quantitative process management plan QPM L4-Standards-2

Project's software quality plan SQM L4-Standards-3


Project 's Quant i tat ive Process Management Plan

The following table contains what the CMM describes as the recommendedcontent of a project's quantitative process management plan:

Standardchecklist

Recommended Content

The goals and objectives of the quantitative process management activities.(L4-7, A2, 1)

The software tasks or other software activities that will be measured andanalyzed. (L4-8, A2, 2)

The instrumentation of the project's defined software process. (L4-8, A2, 3)

The quantitative process management activities to be performed and theschedule for these activities. (L4-8, A2, 4)

The groups and individuals responsible for the quantitative processmanagement activities. (L4-8, A2, 5)

The resources required to perform the quantitative process managementactivities, including staff and tools. (L4-8, A2, 6)

The procedures to be followed in performing the quantitative processmanagement activities. (L4-8, A2, 7)


Project 's Software Qual i ty Plan

The following table contains what the CMM describes as the recommendedcontent of a project's software quality plan:

Standardchecklist

Recommended Content

The points in the process where software quality is measured. (L4-26, A2,1)

The high-leverage quality goals for the software products. (L4-26, A2, 2)

The actions that the software project will implement to improve on pastquality performance. (L4-26, A2, 3)

The activities to measure software product quality. (L4-26, A2, 4)

Quality goals for software work products, as appropriate. (L4-26, A2, 5)

The actions that will be taken when the software product quality isprojected not to meet the quality goals. (L4-26, A2, 6)



O v e r v i e w







Quantitative Process Management L4-Process-3

Software Quality Management L4-Process-31


Quant i ta t ive Process Management (QPM) Process

Q P M P r o c e s s - O v e r v i e w

The purpose of Quantitative Process Management is to control the processperformance of the software project quantitatively. Software process performancerepresents the actual results achieved from following a software process. (L4-1)

QPM processpurpose

Quantitative Process Management involves establishing goals for the performanceof the project's defined software process, which is described in the IntegratedSoftware Management key process area, taking measurements of the processperformance, analyzing these measurements, and making adjustments to maintainprocess performance within acceptable limits. When the process performance isstabilized within acceptable limits, the project's defined software process, theassociated measurements, and the acceptable limits for the measurements areestablished as a baseline and used to control process performance quantitatively.

The organization collects process performance data from the software projects anduses these data to characterize the process capability (i.e., the processperformance a new project can expect to attain) of the organization's standardsoftware process, which is described in the Organization Process Definition keyprocess area. Process capability describes the range of expected results fromfollowing a software process (i.e., the most likely outcomes that are expected fromthe next software project the organization undertakes). These process capabilitydata are, in turn, used by the software projects to establish and revise their processperformance goals and to analyze the performance of the projects' definedsoftware processes. (L4-1)

QPM processdescription



Q P M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L4-Process-5



L4-Process-11


L4-Process-13


L4-Process-15


L4-Process-17

Reviews andAudits




L4-Process-25




L4-Process-27




QPM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thequantitative process management process.



q The (group that is responsible forcoordinating the quantitative processmanagement activities for theorganization) is either part of thegroup responsible for theorganization's software processactivities (e.g., software engineeringprocess group) or its activities areclosely coordinated with that group.(L4-4, Ab1, 1)

q The project’s quantitative processmanagement plan is reviewed by thegroup responsible for theorganization's software processactivities (e.g., the softwareengineering process group). (L4-7,A1, 3)

Groupresponsiblefor coordinat-ing the quan-titativeprocessmanagementactivities fortheorganization

The group that is responsible forcoordinating the quantitative processmanagement activities for theorganization is either part of the groupresponsible for the organization's softwareprocess activities (e.g., softwareengineering process group) or its activitiesare closely coordinated with that group.(L4-4, Ab1, 1)

Individualsimplementingor supportingquantitativeprocessmanagement

The individuals implementing orsupporting quantitative processmanagement receive required training toperform these activities. (L4-6, Ab4)

Managers ofsoftware-relatedgroups

The managers and task leaders of thesoftware engineering groups and othersoftware-related groups perform theproject's quantitative process managementactivities. (L4-4, Ab2, 1)


Managers ofthe softwareengineeringgroups




QPM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thequantitative process management process, continued from the previous page.


Projectmanager

The project manager, senior managers,software managers, and software taskleaders receive specialized reports(documenting the results of the softwareproject’s quantitative process managementactivities) on request. (L4-12, A6, 4)

The software project's activities forquantitative process management arereviewed with the project manager onboth a periodic and event-driven basis.(L4-16, V2)

Seniormanagement

q The software managers, software taskleaders, and senior managementreceive regular reports (documentingthe results of the software project’squantitative process managementactivities) appropriate for their needs.(L4-12, A6, 2)

q The activities for quantitative processmanagement are reviewed with seniormanagement on a periodic basis. (L4-15, V1)

Seniormanager

The project manager, senior managers,software managers, and software taskleaders receive specialized reports(documenting the results of the softwareproject’s quantitative process managementactivities) on request. (L4-12, A6, 4)


or

Members ofthe softwareengineeringgroup

The members of the softwareengineering group and other software-related groups receive orientation on thegoals and value of quantitative processmanagement. (L4-6, Ab5)




Roles,continued



Softwaremanager


q The project manager, senior managers,software managers, and software taskleaders receive specialized reports(documenting the results of thesoftware project’s quantitative processmanagement activities) on request.(L4-12, A6, 4)


or

Members ofsoftware-relatedgroups

The members of the software engineeringgroup and other software-related groupsreceive orientation on the goals and valueof quantitative process management. (L4-6, Ab5)


q The software quality assurancegroup receives regular reports(documenting the results of thesoftware project’s quantitative processmanagement activities) appropriate toits needs. (L4-12, A6, 3)

q The software quality assurancegroup reviews and/or audits theactivities and work products forquantitative process management andreports the results. (L4-16, V3)




Roles,continued





q The project manager, senior managers,software managers, and software taskleaders receive specialized reports(documenting the results of thesoftware project’s quantitative processmanagement activities) on request.(L4-12, A6, 4)

Task leadersof othersoftware-relatedgroups


Task leadersof the softwareengineeringgroups



QPM Process - Entry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the quantitative process management process.


Project’s quantitativeprocess managementplan

is documented. (L4-2, C1, 1)

Sensitive datarelating toindividuals'performance

q are protected. (L4-3, C1, 2)

q (access to) is appropriatelycontrolled. (L4-3, C1, 2)

The CMM recommends that the conditions described in the table below besatisfied before entering the quantitative process management process.



The project follows a written organizational policy formeasuring and quantitatively controlling the performance ofthe project's defined software process. (L4-2, C1)

[Refer to Level 4 Policies for additional informationregarding QPM policy.]

The organization follows a written policy for analyzing theprocess capability of the organization's standard softwareprocess. (L4-3, C2)

[Refer to Level 4 Policies for additional informationregarding QPM policy.]

A group that is responsible for coordinating thequantitative process management activities for theorganization exists. (L4-4, Ab1)

q The group that is responsible for coordinating thequantitative process management activities for theorganization is either part of the group responsiblefor the organization's software process activities(e.g., software engineering process group) or itsactivities are closely coordinated with that group. (L4-4, Ab1, 1)

Adequate resources and funding are provided for thequantitative process management activities. (L4-4, Ab2)

An organization-wide measurement program exists. (L4-5,Ab2, 2)

Tools to support quantitative process management are madeavailable. (L4-5, Ab2, 3)


Support exists for collecting, recording, and analyzing datafor selected process and product measurements. (L4-5,Ab3)



QPM Process - Ent ry Cr i ter ia , Continued


The CMM recommends that the conditions described in the table below besatisfied before entering the quantitative process management process, continuedfrom the previous page.


The individuals implementing or supportingquantitative process management receive requiredtraining to perform these activities. (L4-6, Ab4)

The members of the software engineering group andother software-related groups receive orientation on thegoals and value of quantitative process management. (L4-6,Ab5)


QPM Process - Inputs

Inputs The table below lists the recommended inputs to the quantitative processmanagement process.


Actual process performance. (L4-12, A5,7)

Defined acceptable limits for eachmeasurement. (L4-12, A5, 7)

Description of the project's definedsoftware process. (L4-7, A1, 1.6)

Expected mean values for eachmeasurement. (L4-11, A5, 6)

Expected variance values for eachmeasurement. (L4-11, A5, 6)

Goals of the organization's measurementprogram. (L4-17, V3, 3.4)

Goals of the quantitative processmanagement activities. (L4-7, A2, 1)

Measured performance of other projects'defined software processes. (L4-7, A1,1.5)

Objectives of the organization'smeasurement program. (L4-17, V3, 3.4)

Objectives of the quantitative processmanagement activities. (L4-7, A2, 1)

Organization's measurement goals. (L4-9,A4, 1)

Organization's measurement objectives.(L4-9, A4, 1)

Organization's standard software process.(L4-7, A1, 1.3)

Organization's strategic goals for productdevelopment cycle time. (L4-6, A1, 1.1)

Organization's strategic goals for productquality. (L4-6, A1, 1.1)

Organization's strategic goals forproductivity. (L4-6, A1, 1.1)

Process capability baseline of theorganization's standard software process.(L4-3, C2, 1)


QPM Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the quantitative processmanagement process, continued from the previous page.


Process capability trends for theorganization's standard software process.(L4-13, A7, 4)

Project's defined software process. (L4-2,C1)

Project’s goals for product developmentcycle time. (L4-7, A1, 1.4)

Project’s goals for software product’squality. (L4-7, A1, 1.4)

Project’s goals for productivity. (L4-7, A1,1.4)

Project’s measurement of processperformance. (L4-3, C2, 1)

Project’s quantitative process managementplan. (L4-2, C1, 1)

Schedule for quantitative processmanagement activities to be performed.(L4-8, A2, 4)

Sensitive data relating to individuals'performance. (L4-3, C1, 2)

Software project's measurement goals.(L4-9, A4, 1)

Software project's measurement objectives.(L4-9, A4, 1)


QPM Process - Act iv i t ies

Activities The table below lists the recommended activities for the quantitative processmanagement process.


The software project's plan for quantitative processmanagement is developed according to a documentedprocedure. (L4-6, A1)


The software project's quantitative process managementactivities are performed in accordance with the project'squantitative process management plan. (L4-7, A2)

The strategy for the data collection and the quantitativeanalyses to be performed are determined based on theproject's defined software process. (L4-8, A3)

The measurement data used to control the project's definedsoftware process quantitatively are collected according to adocumented procedure. (L4-9, A4)


The project's defined software process is analyzed andbrought under quantitative control according to adocumented procedure. (L4-10, A5)


Reports documenting the results of the software project'squantitative process management activities are preparedand distributed. (L4-12, A6)

The process capability baseline for the organization'sstandard software process is established and maintainedaccording to a documented procedure. (L4-13, A7)


Measurements are made and used to determine the status ofthe activities for quantitative process management. (L4-15,M1)

The activities for quantitative process management arereviewed with senior management on a periodic basis.(L4-15, V1)



QPM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the quantitative processmanagement process, continued from the previous page.


The software project's activities for quantitative processmanagement are reviewed with the project manager onboth a periodic and event-driven basis. (L4-16, V2)

The software quality assurance group reviews and/oraudits the activities and work products for quantitativeprocess management and reports the results. (L4-16, V3)

[Refer to QPM Process Reviews and Audits for additionalinformation.]


QPM Process - Outputs

Outputs The table below lists the recommended outputs produced by the quantitativeprocess management process.


Acceptable limits for each measurement.(L4-11, A5, 5)

Actual measurement data. (L4-12, A5,8.2)

Actual values of each measurement. (L4-11, A5, 6)

Changes to the organization's standardsoftware process. (L4-15, A7, 7)

Data collection points. (L4-9, A3, 3)

Data for selected process measurements ormeasurement data on the process activitiesthroughout the project’s defined softwareprocess. (L4-5, Ab3)

Data for selected product measurements.(L4-5, Ab3)

Definitions of measurement data (used tocontrol the project’s defined softwareprocess quantitatively). (L4-9, A4, 2)

Expected values for mean (for eachmeasurement). (L4-11, A5, 4)

Expected values for variance (for eachmeasurement). (L4-11, A5, 4)

Goals of the quantitative processmanagement activities. (L4-7, A2, 1)

Intended use and analysis of eachmeasurement. (L4-9, A4, 2)

Measurement data used to control theproject's defined software processquantitatively. (L4-9, A4)

Measurements (to determine the status ofthe quantitative process managementactivities). (L4-15, M1)

Objectives of the quantitative processmanagement activities. (L4-7, A2, 1)

Process capability baseline of theorganization's standard software process.(L4-3, C2, 1)


QPM Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the quantitativeprocess management process, continued from the previous page.


Process control points at which (eachmeasurement that is used to control theproject’s defined software processquantitatively) will be collected. (L4-9,A4, 2)

Projects' measurements of processperformance. (L4-3, C2, 1)

Project’s process performance baseline.(L4-11, A5, 5)

Project’s process performance goals. (L4-4, C2, 2)

Project's software process data. (L4-13,A7, 1)

Project’s quantitative process managementplan. (L4-6, A1)

Quantitative process management data.(L4-16, V3, 3)

Reports documenting the results of thesoftware project's quantitative processmanagement activities. (L4-12, A6)

Results of software quality assurance groupreviews and/or audits of the activities andwork products for quantitative processmanagement. (L4-16, V3)

Results of the data analysis. (L4-12, A6,1)

Schedule for quantitative processmanagement activities to be performed.(L4-8, A2, 4)

Strategy for the data collection and thequantitative analyses to be performed.(L4-8, A3)


QPM Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the quantitative process management process.


Acceptable limits foreach measurement


q have baselines established whenthe project’s defined softwareprocess is controlledquantitatively. (L4-12, A5, 8.3)

Actual measurementdata

have baselines established when theproject’s defined software process iscontrolled quantitatively. (L4-12,A5, 8.2)

Actual values ofeach measurement

are compared to the expected valuesof the mean and variance. (L4-11,A5, 6)

Changes to theorganization'sstandard softwareprocess

q are tracked. (L4-15, A7, 7)

q are analyzed to assess theireffects on the process capabilitybaseline. (L4-15, A7, 7)

Data for selectedprocessmeasurements

or

Measurement data onthe process activitiesthroughout theproject’s definedsoftware process


q are collected. (L4-11, A5, 2)


q appropriately characterize theprocess they represent. (L4-11,A5, 3)

Definitions ofmeasurement data(used to control theproject’s definedsoftware processquantitatively)


q have baselines established whenthe project’s defined softwareprocess is controlledquantitatively. (L4-12, A5, 8.1)

Expected values (formean for eachmeasurement)

are specified for each measurement.(L4-11, A5, 4)

Expected values (forvariance for eachmeasurement)

are specified for each measurement.(L4-11, A5, 4)


Intended use andanalysis of eachmeasurement

is defined. (L4-9, A4, 2)



QPM Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the quantitative process management process, continued from the previouspage.


Measurement dataused to control theproject's definedsoftware processquantitatively

q are collected according to adocumented procedure. (L4-9,A4)

q support the organization's andthe software project'smeasurement goals andobjectives. (L4-9, A4, 1)


q are chosen from the entiresoftware life cycle (e.g., both thedevelopment and post-development stages). (L4-9, A4,3)

q cover the properties of the keysoftware process activities andmajor software work products.(L4-10, A4, 4)

q are uniformly collected acrossthe software projects when thedata relate to the organization'sstandard software process. (L4-10, A4, 5)

q are a natural result of thesoftware activities wherepossible. (L4-10, A4, 6)

q are selected to supportpredefined analysis activities.(L4-10, A4, 7)

q are independently assessed forvalidity. (L4-10, A4, 8)

q are stored in the organization'ssoftware process database asappropriate. (L4-10, A4, 9)

Measurements (todetermine the statusof the activities forquantitative processmanagement)








Process capabilitybaseline of theorganization'sstandard softwareprocess

q is established according to adocumented procedure. (L4-13,A7)




Process controlpoints at which (eachmeasurement that isused to control theproject’s definedsoftware processquantitatively) willbe collected


Projects'measurements ofprocess performance

are analyzed to establish andmaintain a process capabilitybaseline for the organization'sstandard software process. (L4-3,C2, 1)

Project’s processperformance baseline



q is incorporated, as appropriate,into the process capabilitybaseline for the organization'sstandard software process. (L4-13, A7, 2)

q (new) is established for asoftware project substantiallydifferent from past projects aspart of tailoring theorganization's standard softwareprocess. (L4-14, A7, 6)

Project’s processperformance goals

are established. (L4-4, C2, 2)






Project's softwareprocess data

as summarized in its processperformance baseline, are recordedin the organization's software processdatabase. (L4-13, A7, 1)

Project’s quantitativeprocess managementplan


q is based on: (L4-6, A1, 1)

q the organization's strategicgoals for product quality,productivity, and productdevelopment cycle time;

q the organization'smeasurement program;

q the organization's standardsoftware process;

q the project's goals for thesoftware product's quality,productivity, and productdevelopment cycle time;

q the measured performance ofother projects' definedsoftware processes; and

q the description of theproject's defined softwareprocess.


q is reviewed by the groupresponsible for theorganization's software processactivities (e.g., the softwareengineering process group).(L4-7, A1, 3)








Reports documentingthe results of thesoftware project'squantitative processmanagementactivities

q are prepared. (L4-12, A6)

q are distributed. (L4-12, A6)

Results of softwarequality assurancegroup reviews and/oraudits of theactivities and workproducts forquantitative processmanagement


Results of the dataanalysis

are reviewed with those affected bythe data before they are reported toanyone else. (L4-12, A6, 1)

Strategy for the datacollection and thequantitative analysesto be performed

are determined based on the project'sdefined software process. (L4-8, A3)

The CMM recommends that the conditions described in the table below besatisfied to exit the quantitative process management process.

General ExitCriteria


Each project implements a documented plan to bring theproject's defined software process under quantitative control.(L4-2, C1, 1)

The process capability baseline for the organization'sstandard software process is used by the software projects inestablishing their process performance goals. (L4-4, C2, 2)

The software project's quantitative process managementactivities are performed in accordance with the project'squantitative process management plan. (L4-7, A2)





The CMM recommends that the conditions described in the table below besatisfied to exit the quantitative process management process, continued from theprevious page.


The strategy for the data collection and the quantitativeanalyses to be performed are determined based on theproject's defined software process. (L4-8, A3)

The attributes of the project's defined software process thatare considered include:

q The tasks, the activities, and their relationships to eachother.

q The software work products and their relationships toeach other and to the project's defined software process.

q The process control points and data collection points.


The software managers, software task leaders, and seniormanagement receive regular reports appropriate for theirneeds. (L4-12, A6, 2)

The software quality assurance group receives regularreports (documenting the results of the software project’squantitative process management activities) appropriate toits needs. (L4-12, A6, 3)

The project manager, senior managers, softwaremanagers, and software task leaders receive specializedreports (documenting the results of the software project’squantitative process management activities) on request.(L4-12, A6, 4)

Process capability trends for the organization's standardsoftware process are examined to predict likely problems oropportunities for improvements. (L4-13, A7, 4)

The activities for quantitative process management arereviewed with senior management on a periodic basis.(L4-15, V1)

The software project's activities for quantitative processmanagement are reviewed with the project manager onboth a periodic and event-driven basis. (L4-16, V2)

The software quality assurance group reviews and/oraudits the activities and work products for quantitativeprocess management and reports the results. (L4-16, V3)


QPM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the quantitativeprocess management process.


References

The project’s quantitative processmanagement plan undergoes peer review.(L4-7, A1, 2)


The project’s quantitative processmanagement plan is reviewed by thegroup responsible for the organization'ssoftware process activities (e.g., thesoftware engineering process group).(L4-7, A1, 3)

Groupresponsiblefor theorganization'ssoftwareprocessactivities (e.g.,the softwareengineeringprocessgroup)

The results of the data analysis arereviewed with those affected by the databefore they are reported to anyone else.(L4-12, A6, 1)


The activities for quantitative processmanagement are reviewed with seniormanagement on a periodic basis. (L4-15,V1)

Seniormanagement

The software project's activities forquantitative process management arereviewed with the project manager onboth a periodic and event-driven basis.(L4-16, V2)

Projectmanager



QPM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the quantitativeprocess management process, continued from the previous page.


References

The software quality assurance groupreviews and/or audits the activities andwork products for quantitative processmanagement and reports the results. (L4-16, V3)


q The plans for the quantitative processmanagement activities are followed.

q The procedures for quantitative processmanagement are followed.

q The collection and analysis ofquantitative process management dataare performed as required, includingverification that:

q the needed data exist,

q the needed data are collected,

q the data collected are needed,

q the data collected support thegoals and objectives of theorganization's measurementprogram,

q the cost of collecting the data isjustified by the usefulness of thedata,

q the data are collected at thecorrect point in the software lifecycle,

q the data are accurate and correct,

q the data are timely, and

q the confidentiality of the data isproperly protected.



QPM Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the quantitative process management process.


Project’s quantitative process management plan. (L4-7, A1,4)

Process performance baseline for the software project. (L4-12, A5, 9)

Process capability baseline for the organization's standardsoftware process. (L4-14, A7, 5)


QPM Process - Measurements

Measurements The table below lists the measurements recommended for the quantitative processmanagement process.


Measurements to determine the status of the activities forquantitative process management. (L4-15, M1)


q The cost over time for the quantitative processmanagement activities, compared to the plan.

q The accomplishment of schedule milestones forquantitative press management activities, compared tothe approved plan (e.g., establishing the processmeasurements to be used on the project, determininghow the process data will be collected, and collectingthe process data).


QPM Process - Documented Procedures


The table below lists the activities for the quantitative process managementprocess recommended to be performed according to a documented procedure.











QPM Process - T ra in ing

Training The table below lists the training recommended for the quantitative processmanagement process.

Training References

The individuals implementing or supportingquantitative process management receive requiredtraining to perform these activities. (L4-6, Ab4)

The members of the software engineering group andother software-related groups receive orientation on thegoals and value of quantitative process management. (L4-6,Ab5)


QPM Process - Too ls

Tools The table below lists the tools recommended for the quantitative processmanagement process.

Tools References

Tools to support quantitative process management. (L4-5,Ab2, 3)


q software source code analyzers,

q automated test coverage analyzers,

q database systems,

q quantitative analysis packages, and

q problem tracking packages.

Organization’s software process database. (L4-10, A4, 9)


Sof tware Qual i ty Management (SQM) Process

S Q M P r o c e s s - O v e r v i e w

The purpose of Software Quality Management is to develop a quantitativeunderstanding of the quality of the project's software products and achieve specificquality goals. (L4-19)

SQM processpurpose

Software Quality Management involves defining quality goals for the softwareproducts, establishing plans to achieve these goals, and monitoring and adjustingthe software plans, software work products, activities, and quality goals to satisfythe needs and desires of the customer and end user for high quality products.

The practices of Software Quality Management build on the practices of theIntegrated Software Management and Software Product Engineering key processareas, which establish and implement the project's defined software process, andthe Quantitative Process Management key process area, which establishes aquantitative understanding of the ability of the project's defined software processto achieve the desired results.

Quantitative goals are established for the software products based on the needs ofthe organization, the customer, and the end users. So that these goals may beachieved, the organization establishes strategies and plans, and the projectspecifically adjusts its defined software process, to accomplish the quality goals.(L4-19)

SQM processdescription



S Q M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L4-Process-33



L4-Process-37


L4-Process-39


L4-Process-42


L4-Process-44

Reviews andAudits




L4-Process-51




L4-Process-53




SQM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thesoftware quality management process.


Affectedgroups

q The software quality plan is reviewedby affected groups and individuals.(L4-24, A1, 8)

q The software quality plan is availableto all affected groups and individuals.(L4-25, A1, 11)

Affectedindividuals

q The software quality plan is reviewedby affected groups and individuals.(L4-24, A1, 8)

q The software quality plan is availableto all affected groups and individuals.(L4-25, A1, 11)

Customer The customer and end users participate inquality tradeoff decisions, as appropriate.(L4-30, A4, 5.3)

End users The customer and end users participate inquality tradeoff decisions, as appropriate.(L4-30, A4, 5.3)

Individualsimplementingandsupportingsoftwarequalitymanagement

The individuals implementing andsupporting software qualitymanagement receive required training toperform their activities. (L4-22, Ab2)

Projectmanager

The activities for software qualitymanagement are reviewed with the projectmanager on both a periodic and event-driven basis. (L4-31, V2)

Seniormanagement

q Senior management reviews thesoftware quality plans. (L4-25, A1, 9)

q The activities for software qualitymanagement are reviewed with seniormanagement on a periodic basis. (L4-31, V1)



SQM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware quality management process, continued from the previous page.



or


q Responsibilities for software qualitymanagement are defined and assignedto the software engineering groupand other software-related groups. (L4-21, C1, 4)

q Criteria are established to enablethe groups to determine theirsuccess in achieving the qualitygoals for the software products.(L4-21, C1, 4.1)

q The members of the softwareengineering group and other software-related groups receive required trainingin software quality management. (L4-22, Ab3)


or

Members ofthe software-relatedgroups

q Responsibilities for software qualitymanagement are defined and assignedto the software engineering group andother software-related groups. (L4-21, C1, 4)

q Criteria are established to enablethe groups to determine theirsuccess in achieving the qualitygoals for the software products.(L4-21, C1, 4.1)

q The members of the softwareengineering group and other software-related groups receive requiredtraining in software qualitymanagement. (L4-22, Ab3)

Specialtyengineers inareas such assafety andreliability

Specialty engineers in areas such assafety and reliability are available to helpset the software quality goals and reviewprogress towards the goals. (L4-21, Ab1,1)


The software quality assurance groupreviews and/or audits the activities andwork products for software qualitymanagement and reports the results. (L4-32, V3)


SQM Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thesoftware quality management process, continued from the previous page.


Subcontractor The software project's quantitative qualitygoals for the products are allocatedappropriately to the subcontractorsdelivering software products to the project.(L4-30, A5)

Teamperformingthe softwaretask

The software tasks are planned andperformed to address the project's softwarequality goals. At the beginning of asoftware task, the team performing thetask: (L4-29, A4, 1)

q reviews the quality goals for thesoftware product,

q determines the quality goals applicableto the software task,

q identifies its plans to achieve thesoftware quality goals, and

q reviews changes made to the process tomeet the software quality goals.


SQM Process - Entry Cr i ter ia


There are no input-based entry criteria in the software quality managementprocess.


The CMM recommends that the conditions described in the table below besatisfied before entering the software quality management process.


The project follows a written organizational policy formanaging software quality. (L4-20, C1)

[Refer to Level 4 Policies for additional informationregarding SQM policy.]

Adequate resources and funding are provided for managingthe quality of the software products. (L4-21, Ab1)

Specialty engineers in areas such as safety andreliability are available to help set the software qualitygoals and review progress towards the goals. (L4-21, Ab1,1)

Tools to support predicting, measuring, tracking, andanalyzing software quality are made available. (L4-21,Ab1, 2)

The individuals implementing and supporting softwarequality management receive required training to performtheir activities. (L4-22, Ab2)

The members of the software engineering group andother software-related groups receive required training insoftware quality management. (L4-22, Ab3)


SQM Process - Inputs

Inputs The table below lists the recommended inputs to the software quality managementprocess.


Alternative software quality goals. (L4-30,A4, 5.2)

Characteristic(s) of software productquality (that describe how well thesoftware product will perform or how wellit can be developed and maintained). (L4-27, A3, 3)

Cost for achieving the software qualitygoals. (L4-30, A4, 5.1)

Desired values (for each characteristic ofsoftware product quality). (L4-27, A3, 3)

Long-term business strategies. (L4-30, A4,5.2)

Plans (software quality) for previous orcurrent projects in the organization. (L4-24, A1, 5)

Points in the process where softwarequality is measured. (L4-26, A2, 1)

Products' quantitative quality goals. (L4-29, A4)


Project's software quality goals. (L4-29,A4, 1)

Project's software quality plan or softwarequality plan. (L4-25, A2)

[Refer to Level 4 Standards for additionalinformation regarding the project's softwarequality plan.]

Quality goals for the software life-cyclestages. (L4-29, A3, 6)

Quality goals for the software products.(L4-21, C1, 4.1)

Quality measurements (of the project'ssoftware products). (L4-30, A4, 3)



SQM Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the software quality managementprocess, continued from the previous page.


Quality plans of the organization. (L4-24,A1, 4)

Required values (for each characteristic ofsoftware product quality). (L4-27, A3, 3)

Short-term priorities. (L4-30, A4, 5.2)

Significant changes to the allocatedrequirements. (L4-24, A1, 6)

Software plans. (L4-30, A4, 5.4)

Software project's quantitative qualitygoals for the products. (L4-30, A5)

Software quality goals. (L4-23, A1, 2)

Software quality needs of the customer.(L4-23, A1, 1)

Software quality needs of the end users.(L4-23, A1, 1)

Software quality needs of the organization.(L4-23, A1, 1)

Software quality priorities of the customer.(L4-23, A1, 2)

Software quality priorities of the end users.(L4-23, A1, 2)

Software quality priorities of theorganization. (L4-23, A1, 2)

Software work products or work products.(L4-30, A4, 5.4)

Subcontractor delivered software products(to the project). (L4-30, A5)

System requirements allocated to softwareor allocated requirements. (L4-23, A1, 2)


SQM Process - Act iv i t ies

Activities The table below lists the recommended activities for the software qualitymanagement process.


The project's software quality plan is developed andmaintained according to a documented procedure. (L4-23,A1)


The project's software quality plan is the basis for theproject's activities for software quality management. (L4-25, A2)

The project's quantitative quality goals for the softwareproducts are defined, monitored, and revised throughout thesoftware life cycle. (L4-27, A3)

q Characteristics of product quality that describe how wellthe software product will perform or how well it can bedeveloped and maintained are identified.

q The measurements used to quantify the characteristicsof software product quality are identified.

q For each characteristic of software product quality,measurable, numeric values, based on the required anddesired values, are selected as quality goals for theproduct.

q Quality goals for the software products are documentedin the project's software quality plan.

q Quality goals for each software life-cycle stage aredefined and documented.

q Quality goals for the software products and software life-cycle stages are revised as understanding of theproducts and understanding of the organization's,customer's, and end users' needs evolve.



SQM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software qualitymanagement process, continued from the previous page.


The quality of the project's software products is measured,analyzed, and compared to the products' quantitative qualitygoals on an event-driven basis. (L4-29, A4)

q The software tasks are planned and performed to addressthe project's software quality goals. At the beginning ofa software task, the team performing the task:

q reviews the quality goals for the software product,

q determines the quality goals applicable to thesoftware task,

q identifies its plans to achieve the software qualitygoals, and

q reviews changes made to the process to meet thesoftware quality goals.

q The quality of the software work products of eachsoftware life-cycle stage are measured.

q The quality measurements are analyzed and comparedto the software quality goals to determine whether thequality goals are satisfied.

q Appropriate actions, consistent with the software qualityplan, are taken to bring the quality measures of theproducts in line with the software quality goals.

q When it is determined that the software quality goalsconflict (that is, one goal cannot be achieved withoutcompromising another goal), actions are taken toresolve the conflict.

q The cost for achieving the software quality goals isanalyzed.

q Alternative software quality goals are considered inlight of long-term business strategies as well asshort-term priorities.

q The customer and end users participate in qualitytradeoff decisions, as appropriate.

q The software work products and plans are revised, asappropriate, to reflect the results of the tradeoffs.

The software project's quantitative quality goals for theproducts are allocated appropriately to the subcontractorsdelivering software products to the project. (L4-30, A5)


SQM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the software qualitymanagement process, continued from the previous page.


Measurements are made and used to determine the status ofthe software quality management activities. (L4-31, M1)

The activities for software quality management arereviewed with senior management on a periodic basis.(L4-31, V1)

The activities for software quality management arereviewed with the project manager on both a periodic andevent-driven basis. (L4-31, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software qualitymanagement and reports the results. (L4-32, V3)

[Refer to SQM Process Reviews and Audits for additionalinformation.]


SQM Process - Outputs

Outputs The table below lists the recommended outputs produced by the software qualitymanagement process.


Capability of the project's defined softwareprocess to satisfy the software qualitygoals. (L4-24, A1, 3)

Characteristics of product quality thatdescribe how well the software productwill perform or how well it can bedeveloped and maintained. (L4-27, A3, 1)

Criteria to enable the groups (thesoftware engineering group and othersoftware-related groups) to determinetheir success in achieving the quality goalsfor the software products. (L4-21, C1, 4.1)

Measurements to determine the status ofthe software quality managementactivities. (L4-31, M1)

Measurements used for software qualitymanagement. (L4-20, C1, 2)

Measurements used to quantify thecharacteristics of software product quality.(L4-27, A3, 2)

Numeric values (for each characteristic ofsoftware product quality). (L4-27, A3, 3)

Plans to achieve the software qualitygoals. (L4-29, A4, 1.3)

Project's quantitative quality goals for thesoftware products. (L4-27, A3)

Project's software quality plan. (L4-23,A1)

[Refer to SPF Standards for additionalinformation regarding the project's softwarequality plan.]

Quality goals applicable to the softwaretask. (L4-29, A4, 1.2)

Quality goals for each software life-cyclestage. (L4-28, A3, 5)

Quality goals for the software products.(L4-20, C1, 3)


Quality of the project's software products.(L4-29, A4)



SQM Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the software qualitymanagement process, continued from the previous page.


Quality of the software work products ofeach software life-cycle stage. (L4-29,A4, 2)

Responsibilities for software qualitymanagement. (L4-21, C1, 4)

Results (of SQA group reviews and/oraudits of the activities and work productsfor software quality management). (L4-32,V3)

Results of the quality tradeoff decisionsmade when software quality goals conflict.(L4-30, A4, 5.3)


SQM Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the software quality management process.

Output Search Criteria/

Notes

References

Capability of theproject's definedsoftware process tosatisfy the softwarequality goals

q is assessed. (L4-24, A1, 3)


Characteristics ofproduct quality (thatdescribe how wellthe software productwill perform or howwell it can bedeveloped andmaintained)


Criteria to enable thegroups (the softwareengineering groupand other software-related groups) todetermine theirsuccess in achievingthe quality goals forthe software products

are established. (L4-21, C1, 4.1)

Measurements (todetermine the statusof the softwarequality managementactivities)



Measurements usedfor software qualitymanagement


q are collected. (L4-20, C1, 2)

q are based on the project'sdefined software process. (L4-20, C1, 2)

Measurements usedto quantify thecharacteristics ofsoftware productquality




SQM Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the software quality management process, continued from the previouspage.


Numeric values (foreach characteristic ofsoftware productquality)

q are measurable. (L4-27, A3, 3)

q are based on the required anddesired values. (L4-27, A3, 3)

q are selected as quality goals forthe product. (L4-27, A3, 3)

Plans to achieve thesoftware qualitygoals

are identified by the teamperforming the software task. (L4-29, A4, 1.3)

Project's quantitativequality goals for thesoftware products

q are defined. (L4-27, A3)

q are monitored throughout thesoftware life cycle. (L4-27, A3)

q are revised throughout thesoftware life cycle. (L4-27, A3)







Project's softwarequality plan



q satisfies the quality plans of theorganization, as appropriate.(L4-24, A1, 4)

q is based on plans for previous orcurrent projects in theorganization, as appropriate.(L4-24, A1, 5)

q is updated at the start of theproject. (L4-24, A1, 6)

q is updated at major projectmilestones. (L4-24, A1, 6)

q is updated whenever theallocated requirements changesignificantly. (L4-24, A1, 6)


q is reviewed by affected groupsand individuals. (L4-24, A1, 8)

q is reviewed by seniormanagement. (L4-25, A1, 9)


q is available to all affectedgroups and individuals. (L4-25, A1, 11)







Quality goalsapplicable to thesoftware task

are determined by the teamperforming the software task. (L4-29, A4, 1.2)

Quality goals foreach software life-cycle stage



Quality goals for thesoftware products

q are defined by the project. (L4-20, C1, 3)

q are documented in the project’ssoftware quality plan. (L4-28,A3, 4)

Quality of theproject's softwareproducts

q is measured on an event-drivenbasis. (L4-29, A4)

q is analyzed on an event-drivenbasis. (L4-29, A4)

q is compared to the products'quantitative quality goals on anevent-driven basis. (L4-29, A4)

Quality of thesoftware workproducts of eachsoftware life-cyclestage

are measured. (L4-29, A4, 2)

Responsibilities forsoftware qualitymanagement


q are assigned to the softwareengineering group and othersoftware-related groups. (L4-21, C1, 4)

Results (of SQAgroup reviews and/oraudits of theactivities and workproducts for softwarequality management)





The CMM recommends that the conditions described in the table below besatisfied to exit the software quality management process.


The project's software quality management activitiessupport the organization's commitment to improve thequality of the software products. (L4-20, C1, 1)

The project defines the quality goals for the softwareproducts and monitors its progress towards them. (L4-20,C1, 3)

An understanding of the software quality needs of theorganization, customer, and end users is developed asappropriate. (L4-23, A1, 1)

The software quality needs and priorities of theorganization, customer, and end user are traceable to thesystem requirements allocated to software and the softwarequality goals. (L4-23, A1, 2)

The project's software quality plan is the basis for theproject's activities for software quality management. (L4-25, A2)

Quality goals for the software products and software life-cycle stages are revised as understanding of the productsand understanding of the organization's, customer's, and endusers' needs evolve. (L4-29, A3, 6)

The software tasks are planned and performed to address theproject's software quality goals. At the beginning of asoftware task, the team performing the task: (L4-29, A4,1)

q Reviews the quality goals for the software product. (L4-29, A4, 1.1)

q Reviews changes made to the process to meet thesoftware quality goals. (L4-29, A4, 1.4)

The quality measurements are analyzed and compared tothe software quality goals to determine whether the qualitygoals are satisfied. (L4-30, A4, 3)

Appropriate actions, consistent with the software qualityplan, are taken to bring the quality measures of the productsin line with the software quality goals. (L4-30, A4, 4)





The CMM recommends that the conditions described in the table below besatisfied to exit the software quality management process, continued from theprevious page.


When it is determined that the software quality goalsconflict (that is, one goal cannot be achieved withoutcompromising another goal), actions are taken to resolvethe conflict. (L4-30, A4, 5)

q The cost for achieving the software quality goals isanalyzed.

q Alternative software quality goals are considered inlight of long-term business strategies as well as short-term priorities.

q The customer and end users participate in qualitytradeoff decisions, as appropriate.

q The software work products and plans are revised, asappropriate, to reflect the results of the tradeoffs.

The software project's quantitative quality goals for theproducts are allocated appropriately to the subcontractorsdelivering software products to the project. (L4-30, A5)

The activities for software quality management arereviewed with senior management on a periodic basis.(L4-31, V1)

The activities for software quality management arereviewed with the project manager on both a periodic andevent-driven basis. (L4-31, V2)

The software quality assurance group reviews and/oraudits the activities and work products for software qualitymanagement and reports the results. (L4-32, V3)


SQM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the software qualitymanagement process.


References

Specialty engineers in areas such assafety and reliability are available to helpset the software quality goals and reviewprogress towards the goals. (L4-21, Ab1,1)


The software quality plan undergoes peerreview. (L4-24, A1, 7)

Not specifiedin CMM

The software quality plan is reviewed byaffected groups and individuals. (L4-24,A1, 8)


Senior management reviews the softwarequality plans. (L4-25, A1, 9)

Seniormanagement

The software tasks are planned andperformed to address the project's softwarequality goals. At the beginning of asoftware task, the team performing thetask: (L4-29, A4, 1)

q Reviews the quality goals for thesoftware product. (L4-29, A4, 1.1)

q Reviews changes made to the processto meet the software quality goals.(L4-29, A4, 1.4)


The activities for software qualitymanagement are reviewed with seniormanagement on a periodic basis. (L4-31,V1)

Seniormanagement

The activities for software qualitymanagement are reviewed with theproject manager on both a periodic andevent-driven basis. (L4-31, V2)

Projectmanager


The software quality assurance groupreviews and/or audits the activities andwork products for software qualitymanagement and reports the results. (L4-32, V3)


q The preparation of the project'ssoftware quality plan.

q The process for establishing andtracking the software quality goals.



SQM Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the software quality management process.


Project’s software quality plan. (L4-25, A1, 10)


SQM Process - Measurements

Measurements The table below lists the measurements recommended for the software qualitymanagement process.


Measurements used for software quality management basedon the project's defined software process. (L4-20, C1, 2)

Software quality. (L4-26, A2, 1)

Software product quality. (L4-26, A2, 4)

Measurements used to quantify the characteristics ofsoftware product quality. (L4-27, A3, 2)

Quality of the project’s software products. (L4-29, A4)

Quality of the software work products of each software life-cycle stage. (L4-29, A4, 4)

Measurements to determine the status of the softwarequality management activities. (L4-31, M1)


q The cost of poor quality (based on known qualitymeasurements to whatever degree of accuracy they canbe collected).

q The costs for achieving the quality goals.


SQM Process - Documented Procedures


The table below lists the software quality management process activities that arerecommended to be performed according to a documented procedure.





SQM Process - T ra in ing

Training The table below lists the training recommended for the software qualitymanagement process.

Training References

The individuals implementing and supporting softwarequality management receive required training to performtheir activities. (L4-22, Ab2)

The members of the software engineering group andother software-related groups receive required training insoftware quality management. (L4-22, Ab3)


SQM Process - Too ls

Tools The table below lists the tools recommended for the software quality managementprocess.

Tools References

Tools to support predicting, measuring, tracking, andanalyzing software quality. (L4-21, Ab1, 2)


q data collection tools,

q database systems,


q software life-cycle simulators,

q quantitative analysis tools, and

q code audit tools.



O v e r v i e w

Introduction This section describes all the explicit documented procedures in the CapabilityMaturity Model for maturity level 4.







Quantitative process management procedures L4-Procedures-2

Software quality management procedure L4-Procedures-6


Quant i ta t ive Process Management (QPM)Procedures

The table below lists the recommended documented procedures for thequantitative process management process.





q The quantitative process management plan is based on:

q the organization's strategic goals for product quality,productivity, and product development cycle time;

q the organization's measurement program;

q the organization's standard software process;

q the project's goals for the software product's quality,productivity, and product development cycle time;

q the measured performance of other projects' definedsoftware processes; and

q the description of the project's defined softwareprocess.

q The plan undergoes peer review.

q The plan is reviewed by the group responsible for theorganization's software process activities (e.g., thesoftware engineering process group).

q The plan is managed and controlled.



Q P M P r o c e d u r e s , Continued

The table below lists the recommended documented procedures for thequantitative process management process, continued from the previous page.





q The measurement data collected support theorganization's and the software project's measurementgoals and objectives.

q The specific measurement data to be collected, theirprecise definitions, the intended use and analysis ofeach measurement, and the process control points atwhich they will be collected are defined.

q The measurements are chosen from the entire softwarelife cycle (e.g., both the development and post-development stages).

q The measurements cover the properties of the keysoftware process activities and major software workproducts.

q The measurement data that relate to the organization'sstandard software process are uniformly collected acrossthe software projects.

q The measurements to be controlled are a natural resultof the software activities where possible.

q The measurements are selected to support predefinedanalysis activities.

q The validity of the measurement data is independentlyassessed.

q The collected measurement data are stored in theorganization's software process database as appropriate.









q The specific data analysis activities are predefined.

q Measurement data on the process activities throughoutthe project's defined software process are identified,collected, and analyzed.

q The selected measurements appropriately characterizethe process they represent.

q The expected values for mean and variance arespecified for each measurement.

q The acceptable limits for each measurement are definedand the project's process performance baseline isestablished.

q The actual values of each measurement are comparedto the expected values of the mean and variance.

q Adjustments are made to bring the actual processperformance in line with the defined acceptable limits,as appropriate.

q When the project's defined software process iscontrolled quantitatively, baselines are established for:

q the definition of the measurements,

q the actual measurement data, and

q the acceptable limits for the measurements.

q The process performance baseline for the softwareproject is managed and controlled.









q The project's software process data, as summarized inits process performance baseline, are recorded in theorganization's software process database.

q The process performance baseline for each project'sdefined software process is incorporated, as appropriate,into the process capability baseline for theorganization's standard software process.

q The process capability baseline for the organization'sstandard software process is documented.

q Process capability trends for the organization's standardsoftware process are examined to predict likelyproblems or opportunities for improvements.

q The process capability baseline for the organization'sstandard software process is managed and controlled.

q When a software project that is substantially differentfrom past projects is undertaken, a new processperformance baseline is established for that project aspart of tailoring the organization's standard softwareprocess.

q Changes to the organization's standard software processare tracked and analyzed to assess their effects on theprocess capability baseline.


Sof tware Qua l i ty Management (SQM) Procedure

The table below lists the recommended documented procedure for the softwarequality management process.

Documentedprocedure




q An understanding of the software quality needs of theorganization, customer, and end users is developed asappropriate.

q The software quality needs and priorities of theorganization, customer, and end user are traceable tothe system requirements allocated to software and thesoftware quality goals.

q The capability of the project's defined software processto satisfy the software quality goals is assessed anddocumented.

q The software quality plan satisfies the quality plans ofthe organization, as appropriate.

q The software quality plan is based on plans for previousor current projects in the organization, as appropriate.

q The software quality plan is updated at the start of theproject, at major project milestones, and whenever theallocated requirements change significantly.

q The software quality plan undergoes peer review.

q The software quality plan is reviewed by affectedgroups and individuals.

q Senior management reviews the software qualityplans.

q The software quality plan is managed and controlled.

q The software quality plan is available to all affectedgroups and individuals.


Level 4 Summary

Overview

The purpose of this section is to provide checklists that provide a summary of themanaged level (level 4). This section contains three perspectives of a CMM level.

Section purpose





Topic Page














Level 4 KPApurposes



QPM The purpose of Quantitative Process Management is to control theprocess performance of the software project quantitatively. Softwareprocess performance represents the actual results achieved fromfollowing a software process. (L4-1)

SQM The purpose of Software Quality Management is to develop aquantitative understanding of the quality of the project's softwareproducts and achieve specific quality goals. (L4-19)


Level 4 - KPA Goals

Level 4 KPAgoals



QPM The quantitative process management activities areplanned. (L4-2, G1)

QPM The process performance of the project's definedsoftware process is controlled quantitatively. (L4-2,G2)

QPM The process capability of the organization's standardsoftware process is known in quantitative terms. (L4-2, G3)

SQM The project's software quality management activitiesare planned. (L4-20, G1)

SQM Measurable goals for software product quality andtheir priorities are defined. (L4-20, G2)

SQM Actual progress toward achieving the quality goals forthe software products is quantified and managed. (L4-20, G3)


Level 4 - Policies



QPM Written organizational policy for measuring andquantitatively controlling the performance of theproject's defined software process. (L4-2, C1)

QPM Written policy for analyzing the process capability ofthe organization's standard software process. (L4-3,C2)

SQM Written organizational policy for managing softwarequality. (L4-20, C1)


Level 4 - Standards

Level 4standards



QPM Projects’ quantitative process management plan. (L4-7, A2)

SQM Project's software quality plan. (L4-25, A2)


Reference



QPM processdescription

Quantitative Process Management involves establishing goals for the performance ofthe project's defined software process, which is described in the Integrated SoftwareManagement key process area, taking measurements of the process performance,analyzing these measurements, and making adjustments to maintain processperformance within acceptable limits. When the process performance is stabilizedwithin acceptable limits, the project's defined software process, the associatedmeasurements, and the acceptable limits for the measurements are established as abaseline and used to control process performance quantitatively.

The organization collects process performance data from the software projects anduses these data to characterize the process capability (i.e., the process performance anew project can expect to attain) of the organization's standard software process,which is described in the Organization Process Definition key process area. Processcapability describes the range of expected results from following a software process(i.e., the most likely outcomes that are expected from the next software project theorganization undertakes). These process capability data are, in turn, used by thesoftware projects to establish and revise their process performance goals and toanalyze the performance of the projects' defined software processes. (L4-1)

SQM processdescription

Software Quality Management involves defining quality goals for the softwareproducts, establishing plans to achieve these goals, and monitoring and adjusting thesoftware plans, software work products, activities, and quality goals to satisfy theneeds and desires of the customer and end user for high quality products.

The practices of Software Quality Management build on the practices of the IntegratedSoftware Management and Software Product Engineering key process areas, whichestablish and implement the project's defined software process, and the QuantitativeProcess Management key process area, which establishes a quantitative understandingof the ability of the project's defined software process to achieve the desired results.

Quantitative goals are established for the software products based on the needs of theorganization, the customer, and the end users. So that these goals may be achieved,the organization establishes strategies and plans, and the project specifically adjusts itsdefined software process, to accomplish the quality goals. (L4-19)



Level 4procedures

The table below lists the activities that are recommended to be performed accordingto a documented procedure in the CMM at level 4. Refer to the Level 4 ProcedureChecklists for additional information regarding the content of each documentedprocedure.


QPM The software project's plan for quantitative processmanagement is developed according to a documentedprocedure. (L4-6, A1)

QPM The measurement data used to control the project'sdefined software process quantitatively are collectedaccording to a documented procedure. (L4-9, A4)

QPM The project's defined software process is analyzed andbrought under quantitative control according to adocumented procedure. (L4-10, A5)

QPM The process capability baseline for the organization'sstandard software process is established andmaintained according to a documented procedure.(L4-13, A7)

SQM The project's software quality plan is developed andmaintained according to a documented procedure.(L4-23, A1)


Level 4 - Training



QPM The individuals implementing or supportingquantitative process management receive requiredtraining to perform these activities. (L4-6, Ab4)

QPM The members of the software engineering group andother software-related groups receive orientation onthe goals and value of quantitative processmanagement. (L4-6, Ab5)

SQM The individuals implementing and supportingsoftware quality management receive requiredtraining to perform their activities. (L4-22, Ab2)

SQM The members of the software engineering groupand other software-related groups receive requiredtraining in software quality management. (L4-22,Ab3)


Level 4 - Tools



QPM Tools to support quantitative process management.(L4-5, Ab2, 3)

QPM Organization’s software process database. (L4-10, A4,9)

SQM Tools to support predicting, measuring, tracking, andanalyzing software quality. (L4-21, Ab1, 2)






References

QPM The project’s quantitative processmanagement plan undergoes peerreview. (L4-7, A1, 2)


QPM The project’s quantitative processmanagement plan is reviewed by thegroup responsible for theorganization's software processactivities (e.g., the softwareengineering process group). (L4-7,A1, 3)

Groupresponsible fortheorganization'ssoftwareprocessactivities (e.g.,the softwareengineeringprocess group)

QPM The results of the data analysis arereviewed with those affected by thedata before they are reported toanyone else. (L4-12, A6, 1)


QPM The activities for quantitativeprocess management are reviewedwith senior management on aperiodic basis. (L4-15, V1)

Seniormanagement

QPM The software project's activities forquantitative process management arereviewed with the project manageron both a periodic and event-drivenbasis. (L4-16, V2)

Projectmanager

QPM The software quality assurancegroup reviews and/or audits theactivities and work products forquantitative process managementand reports the results. (L4-16, V3)


SQM Specialty engineers in areas suchas safety and reliability areavailable to help set the softwarequality goals and review progresstowards the goals. (L4-21, Ab1, 1)


SQM The software quality plan undergoespeer review. (L4-24, A1, 7)

Not specifiedin CMM

SQM The software quality plan isreviewed by affected groups andindividuals. (L4-24, A1, 8)







References

SQM Senior management reviews thesoftware quality plans. (L4-25, A1,9)

Seniormanagement

SQM The software tasks are planned andperformed to address the project'ssoftware quality goals. At thebeginning of a software task, theteam performing the task: (L4-29,A4, 1)

q Reviews the quality goals for thesoftware product. (L4-29, A4,1.1)

q Reviews changes made to theprocess to meet the softwarequality goals. (L4-29, A4, 1.4)

Teamperforming thesoftware task

SQM The activities for software qualitymanagement are reviewed withsenior management on a periodicbasis. (L4-31, V1)

Seniormanagement

SQM The activities for software qualitymanagement are reviewed with theproject manager on both a periodicand event-driven basis. (L4-31, V2)

Projectmanager

SQM The software quality assurancegroup reviews and/or audits theactivities and work products forsoftware quality management andreports the results. (L4-32, V3)







QPM Project’s quantitative process management plan. (L4-7, A1, 4)

QPM Process performance baseline for the software project.(L4-12, A5, 9)

QPM Process capability baseline for the organization'sstandard software process. (L4-14, A7, 5)

SQM Software quality plan. (L4-25, A1, 10)



Level 4measurements



QPM Measurements to determine the status of the activitiesfor quantitative process management. (L4-15, M1)

SQM Measurements used for software quality managementbased on the project's defined software process. (L4-20, C1, 2)

SQM Software quality. (L4-26, A2, 1)

SQM Software product quality. (L4-26, A2, 4)

SQM Measurements used to quantify the characteristics ofsoftware product quality. (L4-27, A3, 2)

SQM Quality of the project’s software products. (L4-29,A4)

SQM Quality of the software work products of each softwarelife-cycle stage. (L4-29, A4, 4)

SQM Measurements to determine the status of the softwarequality management activities. (L4-31, M1)


Chapter 7. Optimizing Level (Level 5)

Overview

This chapter contains the checklists for Level 5 of the CMM.Introduction


Section Title Page








O v e r v i e w

This section describes the explicit policies found in the Capability MaturityModel at maturity level 5.

Introduction











Policies See Page

Defect prevention policies L5-Policy-2

Technology change management policy L5-Policy-3

Process change management policy L5-Policy-4


Defec t Prevent ion (DP) Po l ic ies

The organization follows a written policy for defect prevention activities (L5-2,C1). This policy typically specifies that:

DP policy 1checklist


Long-term plans and commitments are established forfunding, staffing, and other resources for defect prevention.(L5-2, C1, 1)

The resources needed are allocated for the defect preventionactivities. (L5-2, C1, 2)

Defect prevention activities are implemented across theorganization to improve the software processes and products.(L5-2, C1, 3)

The results of the defect prevention activities are reviewedto ensure the effectiveness of those activities. (L5-2, C1, 4)

Management and technical actions identified as a result ofthe defect prevention activities are addressed. (L5-2, C1, 5)

The project follows a written organizational policy for defect prevention activities(L5-2, C2). This policy typically specifies that:

DP policy 2checklist


Defect prevention activities are included in each project'ssoftware development plan. (L5-3, C2, 1)

The resources needed are allocated for the defect preventionactivities. (L5-3, C2, 2)

Project management and technical actions identified as aresult of the defect prevention activities are addressed. (L5-3, C2, 3)

Implementation of effective defect prevention policies has the following results:DP policygoals

Results of Effectively Implementing DP Policies References

Defect prevention activities are planned. (L5-2, G1)

Common causes of defects are sought out and identified.(L5-2, G2)

Common causes of defects are prioritized andsystematically eliminated. (L5-2, G3)


T e c h n o l o g y C h a n g e M a n a g e m e n t ( T C M ) P o l i c y

TCM policychecklist

The organization follows a written policy for improving its technology capability(L5-18, C1). This policy typically specifies that:


Objectives for technology change management areestablished and documented. (L5-18, C1, 1)

A documented plan addresses the objectives for technologychange management. (L5-19, C1, 2)

Implementation of an effective technology change management policy has thefollowing results:

TCM policygoals

Results of Effectively Implementing TCM Policy References

Incorporation of technology changes are planned. (L5-18,G1)

New technologies are evaluated to determine their effect onquality and productivity. (L5-18, G2)

Appropriate new technologies are transferred into normalpractice across the organization. (L5-18, G3)


Process Change Management (PCM) Po l icy

PCM policychecklist

The organization follows a written policy for implementing software processimprovements (L5-32, C1). This policy typically specifies that:


The organization has quantitative, measurable goals forsoftware process improvement and tracks performanceagainst these goals. (L5-32, C1, 1)

The organization's process improvements are directedtoward improving product quality, increasing productivity,and decreasing the cycle time for product development.(L5-32, C1, 2)

All of the organization's staff and managers are expected toparticipate in improving the software processes. (L5-32, C1,3)

PCM policygoals

Implementation of an effective process change management policy has thefollowing results:

Results of Effectively Implementing PCM Policy References

Continuous process improvement is planned. (L5-32, G1)

Participation in the organization's software processimprovement activities is organization wide. (L5-32, G2)

The organization's standard software process and theprojects' defined software processes are improvedcontinuously. (L5-32, G3)



O v e r v i e w



Definition









Project plan for defect prevention activities DP L5-Standards-2

Plan for technology change management TCM L5-Standards-3

Plan for pilot efforts to improve technology TCM L5-Standards-4

Software process improvement plan PCM L5-Standards-5


Project P lan for Defect Prevent ion Act iv i t ies

The following table contains what the CMM describes as the recommendedcontent of a project plan for defect prevention activities. This plan:

Standardchecklist

Recommended Content

Identifies the defect prevention activities (e.g., task kick-off and causalanalysis meetings) that will be held. (L5-5, A1, 1)

Specifies the schedule of defect prevention activities. (L5-5, A1, 2)

Covers the assigned responsibilities and resources required, including staffand tools. (L5-5, A1, 3)


Plan for Technology Change Management

The following table contains what the CMM describes as the recommendedcontent of a plan for technology change management. This plan:

Standardchecklist

Recommended Content

Covers the assigned responsibilities and resources required, including staffand tools. (L5-23, A1, 1)

Defines the long-term technical strategy for automating and improving theorganization's standard software process and enhancing the organization'smarket position. (L5-23, A1, 2)

Identifies the procedures to be followed in performing the organization'stechnology change management activities. (L5-23, A1, 3)

Describes the approach for introducing new technologies to address specificneeds of the organization and projects. (L5-24, A1, 4)

q Process areas that are potential areas for technology changes areidentified.

q Approaches for identifying opportunities for technology changes areidentified.

q The specific planned or candidate technologies are identified.

q Where appropriate, the life span for the planned technologies isestimated, from introduction to replacement.

q The make/buy tradeoff studies are documented.

q Approaches for assessing unproven candidate technologies are defined.

q The acquisition and installation procedures are defined.

q The initial training, continuing training, and consultation support aredefined.


Plan for Pi lot Ef forts to Improve Technology

The following table contains what the CMM describes as the recommendedcontent of a plan for pilot efforts to improve technology:

Standardchecklist

Recommended Content

Objectives for the pilot effort. (L5-27, A6, 2.1)

Evaluation criteria for the pilot effort. (L5-27, A6, 2.1)

Activities for the pilot effort. (L5-27, A6, 2.1)


Software Process Improvement Plan

The following table contains what the CMM describes as the recommendedcontent of a software process improvement plan:

Standardchecklist

Recommended Content

The resources required, including staff and tools. (L5-38, A4, 1)

The highest priority process areas for improvement. (L5-38, A4, 2)

Measurable short-term and long-term goals for software processperformance and improvement. (L5-38, A4, 3)

Teams and their assignments for addressing improvements for specificprocess areas. (L5-38, A4, 4)

The procedures for: (L5-38, A4, 5)

q the senior managers overseeing the software process improvementactivities;

q the software managers planning and coordinating the software processimprovement activities;

q individuals and teams identifying, evaluating, and introducingappropriate software process improvements; and

q the teams developing software process improvements for assignedprocess areas.

The administrative and support plans required to maintain continuousprocess improvement. (L5-38, A4, 6)

q Appropriate administrative procedures are included to encourageparticipation in and facilitate the software process improvementactivities.

q Administrative personnel are included in oversight and review of thesoftware process improvement activities.

q The roles and contributions of employees to continuous processimprovement are recognized.



O v e r v i e w







Defect Prevention L5-Process-3

Technology Change Management L5-Process-35

Process Change Management L5-Process-77


Defec t Prevent ion (DP) Process

DP Process - Overv iew

The purpose of Defect Prevention is to identify the cause of defects and preventthem from recurring. (L5-1)

DP processpurpose

Defect Prevention involves analyzing defects that were encountered in the pastand taking specific actions to prevent the occurrence of those types of defects inthe future. The defects may have been identified on other projects as well as inearlier stages or tasks of the current project. Defect prevention activities are alsoone mechanism for spreading lessons learned between projects.

Trends are analyzed to track the types of defects that have been encountered andto identify defects that are likely to recur. Based on an understanding of theproject's defined software process and how it is implemented (as described in theIntegrated Software Management and Software Product Engineering key processareas), the root causes of the defects and the implications of the defects for futureactivities are determined.

Both the project and the organization take specific actions to prevent recurrenceof the defects. Some of the organizational actions may be handled as described inthe Process Change Management key process area. (L5-1)

DP processdescription



D P P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L5-Process-5



L5-Process-10


L5-Process-12


L5-Process-16


L5-Process-20

Reviews andAudits




L5-Process-29




L5-Process-31




DP Process - Ro les

Roles The table below lists the roles and the activities in which they participate in thedefect prevention process.

Roles Activities Participated in... Reference

Causalanalysismeetingleader

The (causal analysis meetings) are led bya person trained in conducting causalanalysis meetings. (L5-7, A3, 2)

Projectmanager

The software project's activities for defectprevention are reviewed with the projectmanager on both a periodic and event-driven basis. (L5-15, V2)

Seniormanagement

The organization's activities for defectprevention are reviewed with seniormanagement on a periodic basis. (L5-14,V1)


or


q Members of the softwareengineering group and other software-related groups receive required trainingto perform their defect preventionactivities. (L5-4, Ab4)

q Members of the softwareengineering group and software-related groups receive feedback on thestatus and results of the organization'sand project's defect preventionactivities on a periodic basis. (L5-12,A8)

Softwareengineeringmanager

The software engineering managers andtechnical staff are trained for their defectprevention roles. (L5-15, V3, 1)


or

Members ofthe software-relatedgroups

q Members of the software engineeringgroup and other software-relatedgroups receive required training toperform their defect preventionactivities. (L5-4, Ab4)

q Members of the software engineeringgroup and software-related groupsreceive feedback on the status andresults of the organization's andproject's defect prevention activities ona periodic basis. (L5-12, A8)



DP Process - Ro les , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thedefect prevention process, continued from the previous page.



The software quality assurance groupreviews and/or audits the activities andwork products for defect prevention andreports the results. (L5-15, V3)

Submitters ofthe actionproposals

Each of the teams assigned to coordinatedefect prevention activities document theirrationale for decisions and provide thedecision and the rationale to thesubmitters of the action proposals. (L5-9, A4, 6)


or

Members ofthe teamperformingthe softwaretask

q At the beginning of a software task, themembers of the team performingthe task meet to prepare for theactivities of that task and the relateddefect prevention activities. (L5-6,A2)

q Each team that performs a softwaretask conducts causal analysismeetings. (L5-7, A3, 1)

Teamsassigned tocoordinatedefectpreventionactivities (theorganization-level team orthe teams foreach softwareproject)

q Each of the teams assigned tocoordinate defect preventionactivities meets on a periodic basis toreview and coordinate implementationof action proposals from the causalanalysis meetings. (L5-8, A4)

q The teams:

q Review the output from the causalanalysis meetings and select actionproposals that will be addressed.

q Review action proposals that havebeen assigned to them by otherteams coordinating defectprevention activities in theorganization and select actionproposals that will be addressed.

q Review actions taken by the otherteams in the organization to assesswhether these actions can beapplied to their activities andprocesses.



Roles,continued



Teamsassigned tocoordinatedefectpreventionactivities (theorganization-level team orthe teams foreach softwareproject),continued

q The teams: (L5-8, A4)

q Perform a preliminary analysis ofthe action proposals and set theirpriorities.

q Reassign action proposals to teamsat another level in theorganization, as appropriate.

q Document their rationale fordecisions and provide the decisionand the rationale to the submittersof the action proposals.

q Assign responsibility forimplementing the action itemsresulting from the action proposals.

q Implementation of the actionitems includes makingimmediate changes to theactivities that are within thepurview of the team andarranging for other changes.

q Members of the team usuallyimplement the action items,but, in some cases, the teamcan arrange for someone else toimplement an action item.

q Review results of defect preventionexperiments and take actions toincorporate the results of successfulexperiments into the rest of theproject or organization, asappropriate.

q Track the status of the actionproposals and action items.





Roles,continued



Teamsassigned tocoordinatedefectpreventionactivities (theorganization-level team orthe teams foreach softwareproject),continued

q The teams: (L5-8, A4)

q Document software processimprovement proposals for theorganization's standard softwareprocess and the projects' definedsoftware processes as appropriate.

q Review and verify completedaction items before they are closed.

q Ensure that significant efforts andsuccesses in preventing defects arerecognized.

q Defect prevention data are documentedand tracked across the teamscoordinating defect preventionactivities. (L5-11, A5)

Teams atanother levelin theorganization

The teams assigned to coordinate defectprevention activities reassign actionproposals (from the causal analysismeetings) to teams at another level inthe organization, as appropriate. (L5-9,A4, 5)

Technicalstaff

The software engineering managers andtechnical staff are trained for their defectprevention roles. (L5-15, V3, 1)


DP Process - Entry Cr i ter ia


There are no input-based entry criteria in the defect prevention process.


The CMM recommends that the conditions described in the table below besatisfied before entering the defect prevention process.


The organization follows a written policy for defectprevention activities (L5-2, C1).

[Refer to Level 5 Policies for additional informationregarding DP policy.]

An organization-level team to coordinate defectprevention activities exists. (L5-3, Ab1)

The organization-level team to coordinate defectprevention activities is either part of the groupresponsible for the organization's software processactivities (e.g., software engineering process group) or itsactivities are closely coordinated with that group. (L5-3,Ab1, 1)

A team to coordinate defect prevention activities for thesoftware project exists. (L5-3, Ab2)

This team is closely tied to the team responsible fordeveloping and maintaining the project's definedsoftware process. (L5-3, Ab2, 1)

Adequate resources and funding are provided for defectprevention activities at the project and organization levels.(L5-4, Ab3)

Defect prevention activities are planned into each person'sresponsibilities, as appropriate. (L5-4, Ab3, 1)

Management participation in the defect preventionactivities is planned. (L5-4, Ab3, 2)

Each software project is represented on the teamcoordinating defect prevention activities for theorganization, as appropriate. (L5-4, Ab3, 3)

Tools to support defect prevention activities are madeavailable. (L5-4, Ab3, 4)

Members of the software engineering group and othersoftware-related groups receive required training toperform their defect prevention activities. (L5-4, Ab4)


DP Process - Inputs

Inputs The table below lists the recommended inputs to the defect prevention process.


Action items resulting from the actionproposals (from the causal analysismeetings). (L5-9, A4, 7)

Action proposals from the causal analysismeetings. (L5-8, A4)

Categories of root causes. (L5-7, A3, 4)

Changes to software methods. (L5-6, A2,1)

Completed action items (resulting fromaction proposals from the causal analysismeetings). (L5-10, A4, 11)

Inputs required and available for the(software) task. (L5-6, A2, 2)

List of errors that are commonly made orintroduced during the current stage. (L5-6,A2, 6)

Methods to be used to evaluate theoutputs. (L5-6, A2, 4)

Methods to be used to verify adherence tothe software process. (L5-6, A2, 5)

Organization's standard software process.(L5-10, A4, 10)

Output from the causal analysis meetings.(L5-9, A4, 1)

Outputs to be produced with examples, ifavailable. (L5-6, A2, 3)

Projects' defined software processes. (L5-3, Ab2, 1)

Recommended preventive actions (forerrors that are commonly made orintroduced during the current stage). (L5-6, A2, 6)

Results of defect prevention experiments.(L5-10, A4, 8)

Results of successful (defect prevention)experiments. (L5-10, A4, 8)

Software methods. (L5-6, A2, 1)


Software product quality goals for thesoftware project. (L5-7, A2, 9)



DP Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the defect prevention process,continued from the previous page.


Software product quality goals for thesoftware task. (L5-7, A2, 9)

Software products. (L5-2, C1, 3)

Task schedule. (L5-6, A2, 8)

Team assignments. (L5-6, A2, 7)

Work products for defect prevention. (L5-15, V3)


DP Process - Act iv i t ies

Activities The table below lists the recommended activities for the defect preventionprocess.


The software project develops and maintains a plan for itsdefect prevention activities. (L5-5, A1)

q This plan undergoes peer review. (L5-5, A1, 4)

At the beginning of a software task, the members of theteam performing the task meet to prepare for theactivities of that task and the related defect preventionactivities. (L5-6, A2)These kick-off meetings cover:q The software process, standards, procedures, methods,

and tools applicable to the task, with an emphasis onrecent changes.

q The inputs required and available for the task.

q The outputs to be produced with examples, if available.

q The methods to be used to evaluate the outputs.

q The methods to be used to verify adherence to thesoftware process.

q A list of errors that are commonly made or introducedduring the current stage and recommended preventiveactions for these errors.

q The team assignments.

q The task schedule.

q The software product quality goals for the task andsoftware project.

Causal analysis meetings are conducted according to adocumented procedure. (L5-7, A3)




DP Process - Act iv i t ies , Continued


The table below lists the recommended activities for the defect preventionprocess, continued from the previous page.


Each of the teams assigned to coordinate defectprevention activities meets on a periodic basis to reviewand coordinate implementation of action proposals from thecausal analysis meetings. (L5-8, A4)

q The teams:

q Review the output from the causal analysismeetings and select action proposals that will beaddressed.

q Review action proposals that have been assigned tothem by other teams coordinating defectprevention activities in the organization andselect action proposals that will be addressed.

q Review actions taken by the other teams in theorganization to assess whether these actions can beapplied to their activities and processes.

q Perform a preliminary analysis of the actionproposals and set their priorities.

q Reassign action proposals to teams at another levelin the organization, as appropriate.

q Document their rationale for decisions and providethe decision and the rationale to the submitters ofthe action proposals.

q Assign responsibility for implementing the actionitems resulting from the action proposals.

q Implementation of the action items includesmaking immediate changes to the activities thatare within the purview of the team and arrangingfor other changes.

q Members of the team usually implement theaction items, but, in some cases, the team canarrange for someone else to implement an actionitem.

q Review results of defect prevention experiments andtake actions to incorporate the results of successfulexperiments into the rest of the project ororganization, as appropriate.

q Track the status of the action proposals and actionitems.

Activity continued on next page






Activity continued from previous page

q Review results of defect prevention experiments andtake actions to incorporate the results of successfulexperiments into the rest of the project ororganization, as appropriate.

q Track the status of the action proposals and actionitems.

q Document software process improvement proposalsfor the organization's standard software process andthe projects' defined software processes asappropriate.

q Review and verify completed action items beforethey are closed.

q Ensure that significant efforts and successes inpreventing defects are recognized.

Defect prevention data are documented and tracked acrossthe teams coordinating defect prevention activities. (L5-11, A5)

q Action proposals identified in causal analysis meetingsare documented.

q Action items resulting from action proposals aredocumented.

q The defect prevention data are managed and controlled.

Revisions to the organization's standard software processresulting from defect prevention actions are incorporatedaccording to a documented procedure. (L5-12, A6)

Revisions to the project's defined software process resultingfrom defect prevention actions are incorporated according toa documented procedure. (L5-12, A7)

Members of the software engineering group andsoftware-related groups receive feedback on the status andresults of the organization's and project's defect preventionactivities on a periodic basis. (L5-12, A8)

Measurements are made and used to determine the status ofthe defect prevention activities. (L5-13, M1)

The organization's activities for defect prevention arereviewed with senior management on a periodic basis.(L5-14, V1)






The software project's activities for defect prevention arereviewed with the project manager on both a periodic andevent-driven basis. (L5-15, V2)

The software quality assurance group reviews and/oraudits the activities and work products for defect preventionand reports the results. (L5-15, V3)


DP Process - Outputs

Outputs The table below lists the recommended outputs produced by the defect preventionprocess.


Action items resulting from actionproposals. (L5-11, A5, 2)

Action proposals (from the causal analysismeetings). (L5-9, A4, 1)

Actual cost of completed defect preventionactivities. (L5-15, V1, 6)

Commitments for funding, staffing, andother resources for defect prevention. (L5-2, C1, 1)

Common causes of defects. (L5-8, A3, 6)

Decision(s) (for action proposals). (L5-9,A4, 6)

Defect prevention data. (L5-11, A5)

Defects. (L5-7, A3, 3)

Feedback on the status and results of theorganization's and project's defectprevention activities. (L5-12, A8)

Frequency distribution of actions in themajor action categories. (L5-14, V1, 2)

Frequency distribution of defects in themajor defect categories. (L5-13, A8, 2)

Inputs required and available for the(software) task. (L5-6, A2, 2)

List of errors that are commonly made orintroduced during the current stage. (L5-6,A2, 6)

Long-term plans for funding, staffing, andother resources for defect prevention. (L5-2, C1, 1)

Management actions identified as a resultof the defect prevention activities. (L5-2,C1, 5)

Measurements (to determine the status ofdefect prevention activities). (L5-13, M1)

Methods to be used to evaluate theoutputs. (L5-6, A2, 4)


Methods to be used to verify adherence tothe software process. (L5-6, A2, 5)



DP Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the defect preventionprocess, continued from the previous page.


Number of defects uncovered. (L5-7, A3,1.2)

Outputs to be produced with examples, ifavailable. (L5-6, A2, 3)

Plan for (the software project’s) defectprevention activities. (L5-5, A1)

[Refer to Level 5 Standards for additionalinformation regarding this plan.]

Priorities (for action proposals). (L5-9,A4, 4)

Project management actions identified asa result of the defect prevention activities.(L5-3, C2, 3)

Project technical actions identified as aresult of the defect prevention activities.(L5-3, C2, 3)

Project's software development plan. (L5-3, C2, 1)

Projected cost of planned defectprevention activities. (L5-15, V1, 6)

Proposed actions to prevent the futureoccurrence of identified defects andsimilar defects. (L5-8, A3, 5)

Rationale for decisions (aboutimplementing action proposals from thecausal analysis meetings). (L5-9, A4, 6)

Recommended preventive actions (forerrors that are commonly made orintroduced during the current stage of asoftware task). (L5-6, A2, 6)

Results (of the SQA group reviews and/oraudits of the activities and work productsfor defect prevention). (L5-15, V3)

Results of the (causal analysis) meeting.(L5-8, A3, 7)

Results of the defect prevention activities.(L5-2, C1, 4)



Outputs,continued



Revisions to the organization's standardsoftware process resulting from defectprevention actions. (L5-12, A6)

Revisions to the project's defined softwareprocess resulting from defect preventionactions. (L5-12, A7)

Root causes (of defects). (L5-7, A3, 3)

Schedule of defect prevention activities.(L5-5, A1, 2)

Significant innovations to address themajor defect categories. (L5-13, A8, 3)

Software methods. (L5-6, A2, 1)

Software process improvement proposalsfor the organization's standard softwareprocess. (L5-10, A4, 10)

Software process improvement proposalsfor the projects' defined software processes.(L5-10, A4, 10)

Software product quality goals for thesoftware project. (L5-7, A2, 9)

Software product quality goals for the task.(L5-7, A2, 9)

Software products. (L5-7, A3, 1.3)

Summary of the effectiveness of andsavings attributable to the defectprevention activities. (L5-15, V1, 5)

Summary of the major action categories.(L5-14, V1, 2)

Summary of the major defect categories.(L5-13, A8, 1)

Summary status of the action proposalsand action items. (L5-13, A8, 4)

Summary status of the proposed, open, andcompleted action items. (L5-15, V1, 4)

Task schedule. (L5-6, A2, 8)




Outputs,continued



Team assignments. (L5-6, A2, 7)

Technical actions identified as a result ofthe defect prevention activities. (L5-2,C1, 5)


DP Process - Exi t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the defect prevention process.


Action itemsresulting from actionproposals


Action proposals(from the causalanalysis meetings)

are selected. (L5-9, A4, 1)

Changes to softwaremethods

are covered in kick-off meetings atthe beginning of a software task.(L5-6, A2, 1)

Commitments forfunding, staffing, andother resources fordefect prevention


Common causes ofdefects



Decision(s) (foraction proposals)

are provided to the submitters ofthe action proposals. (L5-9, A4, 6)

Defect preventiondata


q are tracked across the teamscoordinating defect preventionactivities. (L5-11, A5)


Defects q are identified. (L5-7, A3, 3)

q are analyzed to determine theirroot causes. (L5-7, A3, 3)

q are assigned to categories of rootcauses. (L5-7, A3, 4)



DP Process - Ex i t Cr i ter ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the defect prevention process, continued from the previous page.


Feedback on thestatus and results ofthe organization'sand project's defectprevention activities

q is received by members of thesoftware engineering group ona periodic basis. (L5-12, A8)

q is received by members of thesoftware-related groups on aperiodic basis. (L5-12, A8)

q provides (L5-12, A8):

q A summary of the majordefect categories.

q The frequency distribution ofdefects in the major defectcategories.

q Significant innovations andactions taken to address themajor defect categories.

q A summary status of theaction proposals and actionitems.

Inputs required andavailable for the(software) task


List of errors that arecommonly made orintroduced during thecurrent stage


Long-term plans forfunding, staffing, andother resources fordefect prevention


Management actionsidentified as a resultof the defectprevention activities

are addressed. (L5-2, C1, 5)

Measurements (todetermine the statusof the defectprevention activities)









Methods to evaluatethe outputs (of asoftware task)


Methods to verifyadherence to thesoftware process


Outputs to beproduced withexamples, ifavailable


Plan for (the softwareproject’s) defectprevention activities

q is developed by the softwareproject. (L5-5, A1)

q is maintained by the softwareproject. (L5-5, A1)


Priorities (for actionproposals)

are set. (L5-9, A4, 4)

Project managementactions identified asa result of the defectprevention activities


Project technicalactions identified asa result of the defectprevention activities



includes defect prevention activities.(L5-3, C2, 1)

Proposed actions toprevent the futureoccurrence ofidentified defects andsimilar defects

q are developed. (L5-8, A3, 5)


Rationale fordecisions (aboutimplementing actionproposals from causalanalysis meetings)


q are provided to the submittersof the action proposals. (L5-9,A4, 6)






Recommendedpreventive actions(for errors that arecommonly made orintroduced during thecurrent stage of asoftware task)


Results (of the SQAgroup reviews and/oraudits of theactivities and workproducts for defectprevention)


Results of the(causal analysis)meeting

are recorded for use by theorganization and other projects. (L5-8, A3, 7)

Results of the defectprevention activities

are reviewed to ensure theeffectiveness of those activities.(L5-2, C1, 4)

Revisions to theorganization'sstandard softwareprocess resultingfrom defectprevention actions

are incorporated according to adocumented procedure. (L5-12, A6)

Revisions to theproject's definedsoftware processresulting from defectprevention actions

are incorporated according to adocumented procedure. (L5-12, A7)

Root causes (ofdefects)

are determined. (L5-7, A3, 3)

Software methods are covered in kick-off meetings atthe beginning of a software task.(L5-6, A2, 1)

Software processimprovementproposals for theorganization'sstandard softwareprocess

are documented, as appropriate.(L5-10, A4, 10)






Software processimprovementproposals for theprojects' definedsoftware processes

are documented, as appropriate.(L5-10, A4, 10)

Software productquality goals for thesoftware project


Software productquality goals for thetask


Task schedule is covered in kick-off meetings at thebeginning of a software task. (L5-7,A2, 8)

Team assignments are covered in kick-off meetings atthe beginning of a software task.(L5-6, A2, 7)

Technical actionsidentified as a resultof the defectprevention activities


The CMM recommends that the conditions described in the table below besatisfied to exit the defect prevention process.



The resources needed are allocated for the (organization’s)defect prevention activities. (L5-2, C1, 2)

Defect prevention activities are implemented across theorganization to improve the software processes and products.(L5-2, C1, 3)

The resources needed are allocated for the (project’s) defectprevention activities. (L5-3, C2, 2)

At the beginning of a software task, the members of theteam performing the task meet to prepare for theactivities of that task and the related defect preventionactivities. (L5-6, A2)




The CMM recommends that the conditions described in the table below besatisfied to exit the defect prevention process, continued from the previous page.


Each of the teams assigned to coordinate defectprevention activities meets on a periodic basis to reviewand coordinate implementation of action proposals from thecausal analysis meetings. (L5-8, A4)

The teams:

q Review the output from the causal analysis meetingsand select action proposals that will be addressed. (L5-9, A4, 1)

q Review action proposals that have been assigned tothem by other teams coordinating defect preventionactivities in the organization and select actionproposals that will be addressed. (L5-9, A4, 2)

q Review actions taken by the other teams in theorganization to assess whether these actions can beapplied to their activities and processes. (L5-9, A4, 3)

q Perform a preliminary analysis of the action proposalsand set their priorities. (L5-9, A4, 4)

q Reassign action proposals to teams at another level inthe organization, as appropriate. (L5-9, A4, 5)

q Assign responsibility for implementing the action itemsresulting from the action proposals. (L5-9, A4, 7)

q Implementation of the action items includes makingimmediate changes to the activities that are withinthe purview of the team and arranging for otherchanges. (L5-10, A4, 7.1)

q Members of the team usually implement the actionitems, but, in some cases, the team can arrange forsomeone else to implement an action item. (L5-10,A4, 7.2)

q Review results of defect prevention experiments andtake actions to incorporate the results of successfulexperiments into the rest of the project or organization,as appropriate. (L5-10, A4, 8)

q Track the status of the action proposals and actionitems. (L5-10, A4, 9)

q Review and verify completed action items before theyare closed. (L5-10, A4, 11)

q Ensure that significant efforts and successes inpreventing defects are recognized. (L5-10, A4, 12)




The CMM recommends that the conditions described in the table below besatisfied to exit the defect prevention process, continued from the previous page.


The organization's activities for defect prevention arereviewed with senior management on a periodic basis.(L5-14, V1)

The software project's activities for defect prevention arereviewed with the project manager on both a periodic andevent-driven basis. (L5-15, V2)

The software quality assurance group reviews and/oraudits the activities and work products for defect preventionand reports the results. (L5-15, V3)


DP Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the defectprevention process.


References

The results of the defect preventionactivities are reviewed to ensure theeffectiveness of those activities. (L5-2,C1, 4)


The (software project’s plan for defectprevention activities) undergoes peerreview. (L5-5, A1, 4)


Each of the teams assigned to coordinatedefect prevention activities meets on aperiodic basis to review and coordinateimplementation of action proposals fromthe causal analysis meetings. (L5-8, A4)

Teamsassigned tocoordinatedefectpreventionactivities

The teams assigned to coordinate defectprevention activities review the outputfrom the causal analysis meetings andselect action proposals that will beaddressed. (L5-9, A4, 1)


The teams assigned to coordinate defectprevention activities review actionproposals that have been assigned to themby other teams coordinating defectprevention activities in the organizationand select action proposals that will beaddressed. (L5-9, A4, 2)


The teams assigned to coordinate defectprevention activities review actions takenby the other teams in the organization toassess whether these actions can beapplied to their activities and processes.(L5-9, A4, 3)


The teams assigned to coordinate defectprevention activities review results ofdefect prevention experiments and takeactions to incorporate the results ofsuccessful experiments into the rest of theproject or organization, as appropriate.(L5-10, A4, 8)



DP Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the defectprevention process, continued from the previous page.


References

The teams assigned to coordinate defectprevention activities review and verifycompleted action items before they areclosed. (L5-10, A4, 11)


The organization's activities for defectprevention are reviewed with seniormanagement on a periodic basis. (L5-14,V1)

Seniormanagement

The software project's activities for defectprevention are reviewed with the projectmanager on both a periodic and event-driven basis. (L5-15, V2)

Projectmanager

The software quality assurance groupreviews and/or audits the activities andwork products for defect prevention andreports the results. (L5-15, V3)


q The software engineering managersand technical staff are trained for theirdefect prevention roles. (L5-15, V3, 1)

q The task kick-off meetings and causalanalysis meetings are properlyconducted. (L5-15, V3, 2)

q The process for reviewing actionproposals and implementing actionitems is followed. (L5-15, V3, 3)



DP Process - Work Products Managed andContro l led


The table below lists the work products that are recommended to be managed andcontrolled during the defect prevention process.


Defect prevention data. (L5-11, A5, 3)


DP Process - Measurements

Measurements The table below lists the measurements recommended for the defect preventionprocess.


Defect prevention data. (L5-11, A5)

Measurements to determine the status of the defectprevention activities. (L5-13, M1)


q The costs of defect prevention activities (e.g., holdingcausal analysis meetings and implementing actionitems.

q The time and cost for identifying the defects andcorrecting them, compared to the estimated cost of notcorrecting the defects.

q Profiles measuring the number of action items proposed,open, and completed.

q The number of defects injected in each stage,cumulatively, and over releases of similar products.

q The number of defects.


DP Process - Documented Procedures


The table below lists the activities for the defect prevention process recommendedto be performed according to a documented procedure.




Revisions to the organization's standard software processresulting from defect prevention actions are incorporatedaccording to a documented procedure. (L5-12, A6)

Revisions to the project's defined software process resultingfrom defect prevention actions are incorporated according toa documented procedure. (L5-12, A7)


DP Process - T ra in ing

Training The table below lists the training recommended for the defect prevention process.

Training References

Members of the software engineering group and othersoftware-related groups receive required training toperform their defect prevention activities. (L5-4, Ab4)


DP Process - Too ls

Tools The table below lists the tools recommended for the defect prevention process.

Tools References

Tools to support defect prevention activities. (L5-4, Ab3, 4)


q statistical analysis tools, and

q database systems.


T e c h n o l o g y C h a n g e M a n a g e m e n t ( T C M ) P r o c e s s

T C M P r o c e s s - O v e r v i e w

The purpose of Technology Change Management is to identify new technologies(i.e., tools, methods, and processes) and track them into the organization in anorderly manner. (L5-17)

TCM processpurpose

Technology Change Management involves identifying, selecting, and evaluatingnew technologies, and incorporating effective technologies into the organization.The objective is to improve software quality, increase productivity, and decreasethe cycle time for product development.

The organization establishes a group (such as a software engineering processgroup or a technology support group) that works with the software projects tointroduce and evaluate new technologies and manage changes to existingtechnologies. Particular emphasis is placed on technology changes that are likelyto improve the capability of the organization's standard software process (asdescribed in the Organization Process Definition key process area).

By maintaining an awareness of software-related technology innovations andsystematically evaluating and experimenting with them, the organization selectsappropriate technologies to improve the quality of its software and the productivityof its software activities. Pilot efforts are performed to assess new and unproventechnologies before they are incorporated into normal practice. With appropriatesponsorship of the organization's management, the selected technologies areincorporated into the organization's standard software process and current projects,as appropriate.

Changes to the organization's standard software process (as described in theOrganization Process Definition key process area) and the projects' definedsoftware processes (as described in the Integrated Software Management keyprocess area) resulting from these technology changes are handled as described inthe Process Change Management key process area. (L5-17)

TCM processdescription



T C M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L5-Process-37



L5-Process-46


L5-Process-48


L5-Process-52


L5-Process-57

Reviews andAudits




L5-Process-71




L5-Process-73




T C M P r o c e s s - R o l e s

Roles The table below lists the roles and the activities in which they participate in thetechnology change management process.

Roles Activities Participated in... Reference

Affectedmanagers

The plan for technology changemanagement is reviewed by the affectedmanagers. (L5-24, A1, 6)

Groupresponsiblefor theorganization'stechnologychangemanagementactivities

q The group responsible for theorganization's technology changemanagement activities coordinatesand helps to (L5-20, Ab1, 2):

q explore potential areas for applyingnew technology;

q select and plan for newtechnologies;

q acquire, install, and customize newtechnologies;

q communicate and coordinate withrelated research and developmentactivities within the organization;and

q communicate with the technologysuppliers on problems andenhancements.

q Experienced staff members withexpertise in specialized areas areavailable to this group responsiblefor the organization's technologychange management activities to helpin evaluating, planning, and supportinginitiatives for technology changemanagement. (L5-21, Ab2, 1)

q Members of the group responsible forthe organization's technology changemanagement activities receiverequired training to perform theseactivities. (L5-23, Ab5)

q The group responsible for theorganization's technology changemanagement activities works with thesoftware projects in identifying areas oftechnology change. (L5-24, A2)

Role continued on next page


T C M P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in thetechnology change management process, continued from the previous page.


Role continued from previous page

Groupresponsiblefor theorganization'stechnologychangemanagementactivities,continued

q The group responsible for theorganization's technology changemanagement activities: (L5-24, A2)

q Solicits suggestions for technologychanges.

q Identifies available newtechnologies that may beappropriate to the organization'sand projects' needs.

q A periodic search is made toidentify commerciallyavailable technologies thatmeet identified and anticipatedneeds.

q Systematic efforts are made tomaintain awareness of leadingrelevant technical work andtrends of new technologies.

q Systematic efforts are made toreview the technologies usedexternally and to comparethese technologies to thoseused within the organization.

q Areas where new technologieshave been used successfullyare identified, and data anddocumentation of experiencewith using them are collectedand reviewed.

q Evaluates new technologies todetermine their applicability to theorganization's and projects' currentand future needs.





Roles,continued





q The group responsible for theorganization's technology changemanagement systematically analyzesthe organization's standard softwareprocess to identify areas that need orcould benefit from new technology.(L5-25, A4)

The group responsible for theorganization's technology changemanagement activities: (L5-25, A4)

q Analyzes the organization'sstandard software process todetermine areas where newtechnologies would be mosthelpful.

q Identifies helpful technologychanges and determines theeconomics of those changes.

q Defines the relationship of theidentified technology to theorganization's standard softwareprocess.

q Defines the expected outcomes ofthe technology changequalitatively and quantitatively, asappropriate.

q Determines the need for pilotingeach potential technology change.

q Determines the priority of thecandidate new technologies.

q Documents results of the analysisactivities.





Roles,continued





q The requirements and plans arereviewed by the managers of theaffected groups and the groupresponsible for technology changemanagement activities. (L5-26, A5,4.4)

q The group responsible fortechnology change managementactivities provides consultation andassistance to the project implementingthe pilot effort (for improvingtechnology). (L5-27, A6, 4)

Managers ofthe affectedgroups

q The requirements and plans arereviewed by the managers of theaffected groups and the groupresponsible for technology changemanagement activities. (L5-26, A5,4.4)

q The plan for conducting the pilot effortis reviewed and approved by themanagers of the affected groups.(L5-27, A6, 3)

Organization's managers

q Senior management coordinates withthe organization's managers indefining their goals and approaches foraccomplishing the organization'sstrategy. (L5-19, C2, 3)

q Senior management coordinates withthe organization's managers to securethe managers' and staff's support andparticipation. (L5-20, C3, 4.2)




Roles,continued



Seniormanagement

q Senior management sponsors theorganization's activities for technologychange management. (L5-19, C2)

Senior management:

q Helps to define a strategy thataddresses the organization's goalsfor product quality, productivity,and cycle time for productdevelopment.

q Helps to define a strategy thataddresses the customer's and endusers' needs and desires, asappropriate.

q Coordinates with the organization'smanagers in defining their goalsand approaches for accomplishingthe organization's strategy.

q Makes a commitment to the effortfor technology change managementthat is visible throughout theorganization.

q Establishes long-term plans andcommitments for funding, staffing,and other resources.





Roles,continued





q Senior management oversees theorganization's technology changemanagement activities. (L5-19, C3)

Senior management:

q Helps to establish policies fortechnology change managementand reviews and approves thesepolicies.

q Allocates resources for technologychange management activities.

q Helps relate organizationalstrategies and objectives tostrategies for technology changemanagement.

q Participates in establishing theplans for technology changemanagement.

q Senior managementcoordinates requirements andissues for technology changemanagement at all appropriatelevels of the organization.

q Senior managementcoordinates with theorganization's managers tosecure the managers' and staff'ssupport and participation.

q The organization's activities fortechnology change management arereviewed with senior management ona periodic basis. (L5-29, V1)




Roles,continued



Softwaremanager

Software managers and technical staff arekept informed of new technologies. (L5-25, A3)


The software quality assurance groupreviews and/or audits the activities andwork products for technology changemanagement and reports the results. (L5-29, V2)

Staff q Senior management coordinates withthe organization's managers to securethe managers' and staff's support andparticipation. (L5-20, C3, 4.2)

q Experienced staff members withexpertise in specialized areas areavailable to this group to help inevaluating, planning, and supportinginitiatives for technology changemanagement. (L5-21, Ab2, 1)

q Software managers and technical staffare kept informed of new technologies.(L5-25, A3)

Technologysuppliers

The group responsible for the organization'stechnology change management activitiescoordinates and helps to communicate withthe technology suppliers on problems andenhancements. (L5-21, Ab1, 2.5)


TCM Process - Ent ry Cr i te r ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the technology change management process.


Data on the softwareprocesses

are available to support analysesperformed to evaluate and selecttechnology changes. (L5-22, Ab4)

Data on the softwarework products

are available to support analysesperformed to evaluate and selecttechnology changes. (L5-22, Ab4)

Needs of theorganization (currentand future)


q are anticipated. (L5-24, A2, 2.1)

Needs of the projects(current and future)


q are anticipated. (L5-24, A2, 2.1)

Selection criteria toidentify the highestpotential benefits (forselectingtechnologies)

q are predefined. (L5-26, A5, 3)

q are approved. (L5-26, A5, 3)

The CMM recommends that the conditions described in the table below besatisfied before entering the technology change management process.



The organization follows a written policy for improving itstechnology capability. (L5-18, C1)

[Refer to Level 5 Policies for additional informationregarding TCM policy.]

Senior management sponsors the organization's activitiesfor technology change management. (L5-19, C2)

A group responsible for the organization's technologychange management activities exists. (L5-20, Ab1)

q The group is either part of the group responsible forthe organization's software process activities (e.g.,software engineering process group) or its activitiesare closely coordinated with that group. (L5-20, Ab1, 1)

Adequate resources and funding are provided to establishand staff a group responsible for the organization'stechnology change management activities. (L5-21, Ab2)



TCM Process - Ent ry Cr i te r ia , Continued


The CMM recommends that the conditions described in the table below besatisfied before entering the technology change management process, continuedfrom the previous page.


Experienced staff members with expertise in specializedareas are available to this group (responsible for theorganization's technology change managementactivities) to help in evaluating, planning, and supportinginitiatives for technology change management. (L5-21,Ab2, 1)

Tools to support technology change management are madeavailable. (L5-21, Ab2, 2)

Support exists for collecting and analyzing data needed toevaluate technology changes. (L5-21, Ab3)

This support includes the ability to:

q Record selected process and product data automatically.

q Support data analysis.

q Display selected data.

Members of the group responsible for the organization'stechnology change management activities receiverequired training to perform these activities. (L5-23, Ab5)


TCM Process - Inputs

Inputs The table below lists the recommended inputs to the technology changemanagement process.


Advanced technologies. (L5-27, A6, 1)

Customer's needs and desires. (L5-19, C2,2)

Data on the software processes. (L5-22,Ab4)

Data on the software work products. (L5-22, Ab4)

End users' needs and desires. (L5-19, C2,2)

Information on advanced technologiesalready in use in parts of the organization.(L5-25, A3, 2)

Information on new technologies. (L5-25,A3, 1)

Information on the status of technologiesbeing transferred into the organization.(L5-25, A3, 3)

Issues for technology change management.(L5-20, C3, 4.1)

Needs of the organization (current andfuture). (L5-24, A1, 4)

Needs of the projects (current and future).(L5-24, A1, 4)

New technology. (L5-20, Ab1, 2.1)

Objectives for technology changemanagement. (L5-19, C1, 2)

Organization's goals for cycle time forproduct development. (L5-19, C2, 1)

Organization's goals for product quality.(L5-19, C2, 1)

Organization's goals for productivity. (L5-19, C2, 1)

Organization's standard software process.(L5-23, A1, 2)


Plans for technology change management.(L5-23, A1)




TCM Process - Inputs , Continued

Inputs,continued

The table below lists the recommended inputs to the technology changemanagement process, continued from the previous page.


Potential technology changes. (L5-26, A4,5)

Requirements for technology changemanagement. (L5-20, C3, 4.1)

Revisions to the plans for technologychange management. (L5-29, V1, 4)

Selection criteria (for selectingtechnologies) to identify the highestpotential benefits. (L5-26, A5, 3)

Suggestions for technology changes. (L5-24, A2, 1)

Technologies used externally (to theorganization). (L5-25, A2, 2.3)

Technologies used within the organization.(L5-25, A2, 2.3)

Technology changes. (L5-21, Ab3)

Untried technologies. (L5-27, A6, 1)


TCM Process - Act iv i t ies

Activities The table below lists the recommended activities for the technology changemanagement process.


The organization develops and maintains a plan fortechnology change management. (L5-23, A1)

The group responsible for the organization's technologychange management activities works with the softwareprojects in identifying areas of technology change. (L5-24,A2)

This group:

q Solicits suggestions for technology changes.

q Identifies available new technologies that may beappropriate to the organization's and projects' needs.

q A periodic search is made to identify commerciallyavailable technologies that meet identified andanticipated needs.

q Systematic efforts are made to maintain awarenessof leading relevant technical work and trends of newtechnologies.

q Systematic efforts are made to review thetechnologies used externally and to compare thesetechnologies to those used within the organization.

q Areas where new technologies have been usedsuccessfully are identified, and data anddocumentation of experience with using them arecollected and reviewed.

q Evaluates new technologies to determine theirapplicability to the organization's and projects' currentand future needs.

Software managers and technical staff are kept informed ofnew technologies. (L5-25, A3)

q Information on new technologies is disseminated asappropriate.

q Information on advanced technologies already in use inparts of the organization is disseminated as appropriate.

q Information on the status of technologies beingtransferred into the organization is disseminated asappropriate.



TCM Process - Act iv i t i es , Continued


The table below lists the recommended activities for the technology changemanagement process, continued from the previous page.


The group responsible for the organization's technologychange management systematically analyzes theorganization's standard software process to identify areasthat need or could benefit from new technology. (L5-25,A4)

This group:

q Analyzes the organization's standard software process todetermine areas where new technologies would be mosthelpful.

q Identifies helpful technology changes and determinesthe economics of those changes.

q Defines the relationship of the identified technology tothe organization's standard software process.

q Defines the expected outcomes of the technologychange qualitatively and quantitatively, as appropriate.

q Determines the need for piloting each potentialtechnology change.

q Determines the priority of the candidate newtechnologies.

q Documents results of the analysis activities.

Technologies are selected and acquired for the organizationand software projects according to a documented procedure.(L5-26, A5)








Pilot efforts for improving technology are conducted, whereappropriate, before a new technology is introduced intonormal practice. (L5-27, A6)

q These pilot efforts are conducted to determine thefeasibility and economics of untried or advancedtechnologies.

q The plans for the pilot effort are documented.

q The plan for conducting the pilot effort is reviewed andapproved by the managers of the affected groups.

q The group responsible for technology changemanagement activities provides consultation andassistance to the project implementing the pilot effort.

q The pilot effort is performed in an environment that isrelevant to the development or maintenanceenvironment.

q The results of the pilot effort are collected, analyzed,and documented.

q Lessons learned and problems encountered duringthe effort are documented.

q The benefits and impacts of broader use in theorganization are estimated. The uncertainty in theseestimates is assessed.

q A decision is made whether to terminate the effort,proceed with broad-scale implementation of thetechnology, or replan and continue the pilot effort.

Appropriate new technologies are incorporated into theorganization's standard software process according to adocumented procedure. (L5-28, A7)

Appropriate new technologies are incorporated into theprojects' defined software processes according to adocumented procedure. (L5-28, A8)

Measurements are made and used to determine the status ofthe organization's activities for technology changemanagement. (L5-28, M1)


The organization's activities for technology changemanagement are reviewed with senior management on aperiodic basis. (L5-29, V1)

[Refer to TCM Process Reviews and Audits for additionalinformation.]







The software quality assurance group reviews and/oraudits the activities and work products for technologychange management and reports the results. (L5-29, V2)

[Refer to TCM Process Reviews and Audits for additionalinformation.]


TCM Process - Outputs

Outputs The table below lists the recommended outputs produced by the technologychange management process.


Approach for introducing new technologiesto address specific needs of theorganization and projects. (L5-24, A1, 4)

Approaches for accomplishing theorganization's strategy. (L5-19, C2, 3)

Approaches for assessing unprovencandidate technologies. (L5-24, A1, 4.6)

Approaches for identifying opportunities fortechnology changes. (L5-24, A1, 4.2)

Areas of technology change. (L5-24, A2)

Areas that need or could benefit from newtechnology. (L5-25, A4)

Areas where new technologies have beenused successfully. (L5-25, A2, 2.4)

Areas where new technologies would bemost helpful. (L5-25, A4, 1)

Available new technologies that may beappropriate to the organization's andprojects' needs. (L5-24, A2, 2)

Benefits of (a new technology’s) broaderuse in the organization (based on theresults of the pilot efforts for improvingtechnology). (L5-28, A6, 6.2)

Candidate technologies. (L5-24, A1, 4.3)

Commercially available technologies thatmeet identified and anticipated needs.(L5-24, A2, 2.1)

Commitment to the effort for technologychange management. (L5-19, C2, 4)

Commitments for funding, staffing, andother resources (for technology changemanagement activities). (L5-19, C2, 5)

Data needed to evaluate technologychanges. (L5-21, Ab3)

Data of experience (with using newtechnologies in areas where they havebeen used successfully). (L5-25, A2, 2.4)


TCM Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the technologychange management process, continued from the previous page.


Decision whether to terminate the effort(pilot effort for improving technology),proceed with broad-scale implementationof the technology, or replan and continuethe pilot effort. (L5-28, A6, 6.3)

Documentation of experience (with usingnew technologies in areas where they havebeen used successfully). (L5-25, A2, 2.4)

Enhancements (to technology). (L5-21,Ab1, 2.5)

Evaluation criteria for the pilot effort. (L5-27, A6, 2.1)

Expected life span for replacement/upgrade. (L5-26, A5, 4.1)

Expected outcomes of the technologychange. (L5-26, A4, 4)

Goals for accomplishing the organization'sstrategy. (L5-19, C2, 3)

Impacts of (a new technology’s) broaderuse in the organization (based on theresults of the pilot efforts for improvingtechnology). (L5-28, A6, 6.2)

Information on advanced technologiesalready in use in parts of the organization.(L5-25, A3, 2)

Information on new technologies. (L5-25,A3, 1)

Information on the status of technologiesbeing transferred into the organization.(L5-25, A3, 3)

Lessons learned encountered during the(pilot) effort. (L5-27, A6, 6.1)

Life span for the planned technologies(from introduction to replacement). (L5-24, A1, 4.4)

Long-term plans for funding, staffing, andother resources. (L5-19, C2, 5)



Outputs,continued



Long-term technical strategy (forautomating and improving theorganization's standard software processand enhancing the organization's marketposition). (L5-23, A1, 2)

Make/buy tradeoff studies (for introducingnew technology). (L5-24, A1, 4.5)

Measurements to determine the status ofthe organization's activities for technologychange management. (L5-28, M1)

Need for piloting each potentialtechnology change. (L5-26, A4, 5)

Needed strategy changes. (L5-29, V1, 2)

New technologies. (L5-21, Ab1, 2.2)

Objectives for technology changemanagement. (L5-18, C1, 1)

Objectives for the pilot effort. (L5-27, A6,2.1)

Organization's standard software process.(L5-28, A7)

Organizational objectives. (L5-20, C3, 3)

Organizational strategies. (L5-20, C3, 3)

Plan for conducting the pilot effort. (L5-27, A6, 2)


Plan for technology change management.(L5-19, C1, 2)


Planned technologies. (L5-24, A1, 4.3)

Plans for the selected technology changes.(L5-26, A5, 4)

Potential areas for applying newtechnology. (L5-20, Ab1, 2.1)

Priority of the candidate new technologies.(L5-26, A4, 6)



Outputs,continued



Problems encountered during the (pilot)effort. (L5-27, A6, 6.1)

Problems (with technology). (L5-21, Ab1,2.5)

Process areas that are potential areas fortechnology changes. (L5-24, A1, 4.1)

Process data (selected). (L5-22, Ab3, 1)

Product data (selected). (L5-22, Ab3, 1)

Projects' defined software processes. (L5-28, A8)

Relationship of the identified technologyto the organization's standard softwareprocess. (L5-25, A4, 3)

Requests for the acquisition of newtechnologies. (L5-26, A5, 1)

Requirements for the selected technologychanges. (L5-26, A5, 4)

Results (of the software qualityassurance group reviews and/or audits ofthe activities and work products fortechnology change management). (L5-29,V2)

Results of the analysis activities (forperforming systematic analysis of theorganization's standard software process toidentify areas that need or could benefitfrom new technology). (L5-26, A4, 7)

Results of the pilot effort (for improvingtechnology). (L5-27, A6, 6)

Strategies for technology changemanagement. (L5-20, C3, 3)

Strategy that addresses the customer's andend users' needs and desires. (L5-19, C2,2)

Strategy that addresses the organization'sgoals for product quality, productivity, andcycle time for product development. (L5-19, C2, 1)



Outputs,continued



Technologies with projected expensesabove a predefined level. (L5-26, A5, 1.1)

Technologies. (L5-26, A5)

Technology changes. (L5-22, Ab4)

Tradeoff studies (to determine whether thetechnology should be developed internallyor procured externally). (L5-26, A5, 4.2)

Uncertainty in the estimates of benefits of(a new technology’s) broader use in theorganization (based on the results of thepilot efforts for improving technology).(L5-28, A6, 6.2)

Uncertainty in the estimates of impacts of(a new technology’s) broader use in theorganization (based on the results of thepilot efforts for improving technology).(L5-28, A6, 6.2)


TCM Process - Ex i t Cr i te r ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the technology change management process.


Approaches foraccomplishing theorganization'sstrategy

are defined by coordination betweenthe organization's managers andsenior management. (L5-19, C2,3)

Areas of technologychange

are identified by the groupresponsible for the organization'stechnology change managementactivities working with the softwareprojects. (L5-24, A2)

Areas that need orcould benefit fromnew technology

are identified by the groupresponsible for the organization'stechnology change management bysystematically analyzing theorganization's standard softwareprocess. (L5-25, A4)

Areas where newtechnologies havebeen usedsuccessfully

are identified by the groupresponsible for the organization'stechnology change managementactivities. (L5-25, A2, 2.4)

Areas where newtechnologies wouldbe most helpful

are determined by the groupresponsible for the organization'stechnology change management byanalyzing the organization's standardsoftware process. (L5-25, A4, 1)

Available newtechnologies thatmay be appropriateto the organization'sand projects' needs

are identified by the groupresponsible for the organization'stechnology change managementactivities. (L5-24, A2, 2)

Benefits of (a newtechnology’s) broaderuse in theorganization (basedon the results of thepilot efforts forimprovingtechnology)

are estimated. (L5-28, A6, 6.2)


Commerciallyavailabletechnologies thatmeet identified andanticipated needs

are identified by a periodic search bythe group responsible for theorganization's technology changemanagement activities. (L5-24, A2,2.1)



TCM Process - Ex i t Cr i te r ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the technology change management process, continued from the previouspage.


Commitment to theeffort for technologychange management

q is made by senior management.(L5-19, C2, 4)

q is visible throughout theorganization. (L5-19, C2, 4)

Commitments forfunding, staffing, andother resources


Data of experience(in areas where newtechnologies havebeen usedsuccessfully)

q are collected by the groupresponsible for theorganization's technologychange management activities.(L5-25, A2, 2.4)

q are reviewed by the groupresponsible for theorganization's technologychange management activities.(L5-25, A2, 2.4)

Decision whether toterminate the effort(pilot effort forimprovingtechnology), proceedwith broad-scaleimplementation ofthe technology, orreplan and continuethe pilot effort

is made. (L5-28, A6, 6.3)

Documentation ofexperience (in areaswhere newtechnologies havebeen usedsuccessfully)

q is collected by the groupresponsible for theorganization's technologychange management activities.(L5-25, A2, 2.4)

q is reviewed by the groupresponsible for theorganization's technologychange management activities.(L5-25, A2, 2.4)







Enhancements (totechnology)

are communicated to the technologysuppliers (with coordination andhelp from the group responsible forthe organization's technologychange management activities).(L5-21, Ab1, 2.5)

Expected life spanfor replacement/upgrade

is estimated, where practical. (L5-26, A5, 4.1)

Expected outcomesof the technologychange

q are defined qualitatively by thegroup responsible for theorganization's technologychange management, asappropriate. (L5-26, A4, 4)

q are defined quantitatively by thegroup responsible for theorganization's technologychange management, asappropriate. (L5-26, A4, 4)

Goals foraccomplishing theorganization'sstrategy

are defined by senior managementcoordinating with the organization'smanagers. (L5-19, C2, 3)

Impacts of (a newtechnology’s) broaderuse in theorganization (basedon the results of thepilot efforts forimprovingtechnology)

are estimated. (L5-28, A6, 6.2)

Information onadvancedtechnologies alreadyin use in parts of theorganization

is disseminated as appropriate. (L5-25, A3, 2)

Information on newtechnologies








Information on thestatus of technologiesbeing transferred intothe organization


Lessons learned thatare encounteredduring the (pilot)effort


Life span for theplanned technologies(from introduction toreplacement)

is estimated, where appropriate.(L5-24, A1, 4.4)

Long-term plans forfunding, staffing, andother resources (fortechnology changemanagementactivities)


Long-term technicalstrategy (forautomating andimproving theorganization'sstandard softwareprocess andenhancing theorganization's marketposition)

is defined in the plan for technologychange management. (L5-23, A1, 2)

Make/buy tradeoffstudies (forintroducing newtechnology)


Measurements (todetermine the statusof the organization'sactivities fortechnology changemanagement)




Need for pilotingeach potentialtechnology change

is determined by the groupresponsible for the organization'stechnology change management.(L5-26, A4, 5)







Needed strategychanges

are identified in periodic reviewswith senior management. (L5-29,V1, 2)

New technologies q are selected (with coordinationand help from the groupresponsible for theorganization's technologychange managementactivities). (L5-21, Ab1, 2.2)

q are planned (with coordinationand help from the groupresponsible for theorganization's technologychange managementactivities). (L5-21, Ab1, 2.2)

q are acquired (with coordinationand help from the groupresponsible for theorganization's technologychange managementactivities). (L5-21, Ab1, 2.3)

q are installed (with coordinationand help from the groupresponsible for theorganization's technologychange managementactivities). (L5-21, Ab1, 2.3)

q are customized (withcoordination and help from thegroup responsible for theorganization's technologychange managementactivities). (L5-21, Ab1, 2.3)

Objectives fortechnology changemanagement

q are established. (L5-18, C1, 1)


Organization'sstandard softwareprocess

has incorporated appropriate newtechnologies according to adocumented procedure. (L5-28, A7)






Organizationalobjectives

are related to strategies fortechnology change management(with senior management’s help).(L5-20, C3, 3)

Organizationalstrategies

are related to strategies fortechnology change management(with senior management’s help).(L5-20, C3, 3)

Plan for conductingthe pilot effort (forimprovingtechnology)


q is reviewed by the managers ofthe affected groups. (L5-27,A6, 3)

q is approved by the managers ofthe affected groups. (L5-27,A6, 3)

Plan for technologychange management

q is documented. (L5-19, C1, 2)

q addresses the objectives fortechnology change management.(L5-19, C1, 2)

q is established (with seniormanagement participation).(L5-20, C3, 4)

q is developed by the organization.(L5-23, A1)

q is maintained by theorganization. (L5-23, A1)


q is reviewed by the affectedmanagers. (L5-24, A1, 6)







Plans for the selectedtechnology changes



q are estimated. (L5-26, A5, 4.1)

q provide for installing the newtechnology on a pilot basis todetermine its effectiveness andeconomic benefits. (L5-26, A5,4.3)

q are reviewed by the managersof the affected groups and thegroup responsible fortechnology changemanagement activities. (L5-26,A5, 4.4)

Potential areas forapplying newtechnology

are explored (with coordination andhelp from the group responsible forthe organization's technologychange management activities).(L5-20, Ab1, 2.1)

Priority of thecandidate newtechnologies

is determined by the groupresponsible for the organization'stechnology change management.(L5-26, A4, 6)

Problems (withtechnology)

are communicated to the technologysuppliers (with coordination andhelp from the group responsible forthe organization's technologychange management activities).(L5-21, Ab1, 2.5)

Problemsencountered duringthe (pilot) effort


Projects' definedsoftware processes

have incorporated appropriate newtechnologies according to adocumented procedure. (L5-28, A8)


Relationship of theidentified technologyto the organization'sstandard softwareprocess

is defined by the group responsiblefor the organization's technologychange management. (L5-25, A4,3)







Requests for theacquisition of newtechnologies


Requirements for theselected technologychanges



q are reviewed by the managersof the affected groups and thegroup responsible fortechnology changemanagement activities. (L5-26,A5, 4.4)

Results (of thesoftware qualityassurance groupreviews and/or auditsof the activities andwork products fortechnology changemanagement)


Results of theanalysis activities(from the systematicanalysis of theorganization'sstandard softwareprocess to identifyareas that need orcould benefit fromnew technology)

are documented by the groupresponsible for the organization'stechnology change management.(L5-26, A4, 7)

Results of the piloteffort (for improvingtechnology)

q are collected. (L5-27, A6, 6)



Strategies fortechnology changemanagement

are related to organizationalstrategies and objectives (withsenior management’s help). (L5-20, C3, 3)







Strategy thataddresses thecustomer's and endusers' needs anddesires

is defined (with seniormanagement’s help), as appropriate.(L5-19, C2, 2)

Strategy thataddresses theorganization's goalsfor product quality,productivity, andcycle time forproduct development

is defined (with seniormanagement’s help). (L5-19, C2,1)

Technologies q are selected for the organizationand software projects accordingto a documented procedure. (L5-26, A5)

q are acquired for the organizationand software projects accordingto a documented procedure. (L5-26, A5)

Technologies withprojected expensesabove a predefinedlevel

have management approval. (L5-26,A5, 1.1)

Technology changes are identified by the groupresponsible for the organization'stechnology change management.(L5-25, A4, 2)

Tradeoff studies (todetermine whetherthe technologyshould be developedinternally or procuredexternally)

q are documented, whereappropriate. (L5-26, A5, 4.2)

q are performed, whereappropriate. (L5-26, A5, 4.2)

q are reviewed, where appropriate.(L5-26, A5, 4.2)







Uncertainty in theestimates of benefitsof (a newtechnology’s) broaderuse in theorganization (basedon the results of thepilot efforts forimprovingtechnology)

is assessed. (L5-28, A6, 6.2)

Uncertainty in theestimates of impactsof (a newtechnology’s) broaderuse in theorganization (basedon the results of thepilot efforts forimprovingtechnology)

is assessed. (L5-28, A6, 6.2)

The CMM recommends that the conditions described in the table below besatisfied to exit the technology change management process.



Senior management allocates resources for technologychange management activities. (L5-19, C3, 2)

Senior management coordinates requirements and issuesfor technology change management at all appropriate levelsof the organization. (L5-20, C3, 4.1)

Senior management coordinates with the organization'smanagers to secure the managers' and staff's support andparticipation. (L5-20, C3, 4.2)





The CMM recommends that the conditions described in the table below besatisfied to exit the technology change management process, continued from theprevious page.


The group responsible for the organization's technologychange management activities coordinates and helps to(L5-20, Ab1, 2):

q explore potential areas for applying new technology;

q select and plan for new technologies;

q acquire, install, and customize new technologies;

q communicate and coordinate with related research anddevelopment activities within the organization; and

q communicate with the technology suppliers onproblems and enhancements.

The group responsible for the organization's technologychange management activities solicits suggestions fortechnology changes. (L5-24, A2, 1)

Systematic efforts are made to maintain awareness ofleading relevant technical work and trends of newtechnologies. (L5-25, A2, 2.2)

Systematic efforts are made to review the technologies usedexternally and to compare these technologies to those usedwithin the organization. (L5-25, A2, 2.3)

The group responsible for the organization's technologychange management activities evaluates new technologiesto determine their applicability to the organization's andprojects' current and future needs. (L5-25, A2, 3)

Software managers and technical staff are kept informed ofnew technologies. (L5-25, A3)

The group responsible for the organization's technologychange management systematically analyzes theorganization's standard software process to identify areasthat need or could benefit from new technology. (L5-25,A4)

q This group identifies helpful technology changes anddetermines the economics of those changes. (L5-25,A4, 2)

Preliminary cost/benefit analyses are performed for thepotential technology changes. (L5-26, A5, 2)





The CMM recommends that the conditions described in the table below besatisfied to exit the technology change management process, continued from theprevious page.


Predefined and approved selection criteria are used toidentify the highest potential benefits (when selecting andacquiring technologies). (L5-26, A5, 3)

Pilot efforts for improving technology are conducted, whereappropriate, before a new technology is introduced intonormal practice. (L5-27, A6)

q These pilot efforts are conducted to determine thefeasibility and economics of untried or advancedtechnologies. (L5-27, A6, 1)

q The group responsible for technology changemanagement activities provides consultation andassistance to the project implementing the pilot effort.(L5-27, A6, 4)

q The pilot effort is performed in an environment that isrelevant to the development or maintenanceenvironment. (L5-27, A6, 5)

The organization's activities for technology changemanagement are reviewed with senior management on aperiodic basis. (L5-29, V1)

The software quality assurance group reviews and/oraudits the activities and work products for technologychange management and reports the results. (L5-29, V2)


TCM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the technologychange management process.


References

Senior management helps to establishpolicies for technology changemanagement and reviews and approvesthese policies. (L5-19, C3, 1)

Seniormanagement

The organizational plan for technologychange management undergoes peerreview. (L5-24, A1, 5)

Not specifiedin CMM

The organizational plan for technologychange management is reviewed by theaffected managers. (L5-24, A1, 6)

Affectedmanagers

Systematic efforts are made to review thetechnologies used externally and tocompare these technologies to those usedwithin the organization. (L5-25, A2, 2.3)


Areas where new technologies have beenused successfully are identified, and dataand documentation of experience withusing them are collected and reviewed.(L5-25, A2, 2.4)


Where appropriate, tradeoff studies areperformed, reviewed, and documented todetermine whether the technology shouldbe developed internally or procuredexternally. (L5-26, A5, 4.2)

Not specifiedin CMM

The requirements and plans (for selectedtechnology changes) are reviewed by themanagers of the affected groups and thegroup responsible for technologychange management activities. (L5-26,A5, 4.4)


Groupresponsiblefor technologychangemanagementactivities


TCM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the technologychange management process, continued from the previous page.


References

The plan for conducting the pilot effort isreviewed and approved by the managersof the affected groups. (L5-27, A6, 3)


The organization's activities for technologychange management are reviewed withsenior management on a periodic basis.(L5-29, V1)

These reviews:

q Summarize the activities fortechnology change management.

q Identify needed strategy changes.

q Result in the resolution of issues.

q Result in the approval of revisions tothe plans for technology changemanagement, as appropriate.

Seniormanagement

The software quality assurance groupreviews and/or audits the activities andwork products for technology changemanagement and reports the results. (L5-29, V2)


q The plans for technology changemanagement.

q The process for selecting, procuring,and installing new technologies.



TCM Process - Work Products Managed andContro l led


There are no work products that are recommended to be managed and controlledduring the technology change management process.


TCM Process - Measurements

Measurements The table below lists the measurements recommended for the technology changemanagement process.


Data of experience with using (new technologies that havebeen used successfully). (L5-25, A2, 2.4)

Measurements to determine the status of the organization'sactivities for technology change management. (L5-28, M1)


q The overall technology change activity, includingnumber, type, and size of changes.

q The effect of implementing the technology change,compared to the goals.


TCM Process - Documented Procedures


The table below lists the activities in the technology change management processrecommended to be performed according to a documented procedure.


Technologies are selected and acquired for the organizationand software projects according to a documented procedure.(L5-26, A5)


Appropriate new technologies are incorporated into theorganization's standard software process according to adocumented procedure. (L5-28, A7)

Appropriate new technologies are incorporated into theprojects' defined software processes according to adocumented procedure. (L5-28, A8)


T C M P r o c e s s - T r a i n i n g

Training The table below lists the training recommended for the technology changemanagement process.

Training References

Members of the group responsible for the organization'stechnology change management activities receiverequired training to perform these activities. (L5-23, Ab5)


T C M P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the technology changemanagement process.

Tools References

Tools to support technology change management are madeavailable. (L5-21, Ab2, 2)


q workstations,


q subscriptions to on-line technology databases.


Process Change Management (PCM) Process

P C M P r o c e s s - O v e r v i e w

The purpose of Process Change Management is to continually improve thesoftware processes used in the organization with the intent of improving softwarequality, increasing productivity, and decreasing the cycle time for productdevelopment. (L5-31)

PCM processpurpose

Process Change Management involves defining process improvement goals and,with senior management sponsorship, proactively and systematically identifying,evaluating, and implementing improvements to the organization's standardsoftware process and the projects' defined software processes on a continuousbasis.

Training and incentive programs are established to enable and encourageeveryone in the organization to participate in process improvement activities.Improvement opportunities are identified and evaluated for potential payback tothe organization. Pilot efforts are performed to assess process changes before theyare incorporated into normal practice.

When software process improvements are approved for normal practice, theorganization's standard software process and the projects' defined softwareprocesses are revised as appropriate. The practices for revising the organization'sstandard software process are found in the Organization Process Definition keyprocess area, and the practices for revising the projects' defined softwareprocesses are found in the Integrated Software Management key process area.(L5-31)

PCM processdescription



P C M P r o c e s s - O v e r v i e w , Continued

Sectionoverview




L5-Process-79



L5-Process-87


L5-Process-88


L5-Process-91


L5-Process-95

Reviews andAudits




L5-Process-107




L5-Process-109




PCM Process - Ro les

Roles The table below lists the roles and the activities in which they participate in theprocess change management process.


Administrative personnel

Administrative personnel are included inoversight and review of the softwareprocess improvement activities. (L5-38,A4, 6.2)

Experiencedindividualswho haveexpertise indefining andanalyzingsoftwareprocesses

Experienced individuals who haveexpertise in defining and analyzingsoftware processes are available to helpthe organization in its processimprovement activities. (L5-34, Ab1, 2)



P C M P r o c e s s - R o l e s , Continued

Roles,continued

The table below lists the roles and the activities in which they participate in theprocess change management process, continued from the previous page.




q The group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) coordinates thesoftware process improvementactivities. (L5-36, A2)

q The group responsible for theorganization's software processactivities (e.g., softwareengineering process group):

q Defines organizational goalsand measurement plans forsoftware process performance.

q Reviews the organizationalgoals for process performancewith senior management fortheir endorsement.

q Participates in the effort todefine the organization'straining needs for processimprovement and supports thedevelopment and presentationof training course materials.

q Defines and maintains theprocedures for handling processimprovement proposals.

q Reviews software processimprovement proposals andcoordinates the actions forthese proposals.

q Tracks status,accomplishments, andparticipation in the processimprovement activities andperiodically reports the resultsto senior management.

q Coordinates and tracks changesto the organization's standardsoftware process.

q Defines, establishes, andmaintains the processimprovement records.




Roles,continued



Group thatdefines andmaintains theaffectedprocessdescriptions

The plans (for process improvement teamactivities) are approved by the managers ofthe affected groups and the group thatdefines and maintains the affectedprocess descriptions. (L5-41, A6, 3)

Individualsresponsibleforimplementingthe softwareprocesses

The strategy for collecting data to measureand track the change in software processperformance is agreed to by theindividuals responsible forimplementing the software processesaffected by the change. (L5-43, A8, 2.1)

Management Software process changes that are judgedto have a major impact on product qualityor productivity or that will significantlyalter satisfaction of the customer and endusers are reviewed and approved byappropriate management before they areimplemented. (L5-41, A5, 9)

Managers q All of the organization's staff andmanagers are expected to participatein improving the software processes.(L5-32, C1, 3)

q The software process improvement planis reviewed by the affected managers.(L5-37, A3, 3)

q The plans (for process improvementteam activities) are approved by themanagers of the affected groups andthe group that defines and maintainsthe affected process descriptions. (L5-41, A6, 3)

Managers ofsoftware-relatedgroups

The managers and technical staff of thesoftware engineering group and othersoftware-related groups receive requiredtraining in software process improvement.(L5-34, Ab3)


Managers ofthe softwareengineeringgroup





Roles,continued



Members oftheorganization

q A software process improvementprogram is established which empowersthe members of the organization toimprove the processes of theorganization. (L5-35, A1)

q Members of the organizationactively participate in teams todevelop software process improvementsfor assigned process areas. (L5-41, A6)

Seniormanagement

q Senior management sponsors theorganization's activities for softwareprocess improvement. (L5-32, C2)

q Senior management:

q Establishes the organization'slong-term goals and plans forprocess improvement.

q Allocates resources for processimprovement activities.

q Coordinates with the softwaremanagers to ensure they havereasonable, yet aggressive,process improvement goals andeffective process improvementplans to meet these goals.

q Monitors process improvementperformance against goals.

q Maintains a consistent priorityfocus on process improvementin the face of product crises.

q Ensures that processimprovement issues arepromptly resolved.

q Rewards employeeparticipation in the processimprovement activities.

q Senior management receives requiredtraining in software processimprovement. (L5-35, Ab4)




Roles,continued




q The group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) reviews theorganizational goals for processperformance with senior managementfor their endorsement. (L5-36, A2, 2)

q The group responsible for theorganization's software processactivities (e.g., software engineeringprocess group) tracks status,accomplishments, and participation inthe process improvement activities andperiodically reports the results tosenior management. (L5-36, A2, 6)

q The activities for software processimprovement are reviewed with seniormanagement on a periodic basis. (L5-46, V1)

Softwaremanagers

q Senior management coordinates withthe software managers to ensure theyhave reasonable, yet aggressive,process improvement goals andeffective process improvement plans tomeet these goals. (L5-33, C2, 3)

q Software managers receive requiredtraining in software processimprovement. (L5-34, Ab2)

q Software managers and technical staffreceive feedback on the status andresults of the software processimprovement activities on an event-driven basis. (L5-44, A10)


The software quality assurance groupreviews and/or audits the activities andwork products for software processimprovement and reports the results. (L5-46, V2)




Roles,continued



Staff q All of the organization's staff andmanagers are expected to participate inimproving the software processes. (L5-32, C1, 3)

q Software managers and technical staffreceive feedback on the status andresults of the software processimprovement activities on an event-driven basis. (L5-44, A10)

Submitters ofthe softwareprocessimprovementproposals

Submitters of the software processimprovement proposals receive: (L5-41,A5, 11)

q Prompt acknowledgment of theirproposals.

q Notification of the disposition of theirproposals.

Teamresponsibleforimplementa-tion (ofsoftwareprocessimprovementactions)

Software process improvement actions thatrequire a substantial effort are assigned toa team responsible for implementation.(L5-40, A5, 6)

Technicalstaff ofsoftware-relatedgroups


Technicalstaff of thesoftwareengineeringgroup



PCM Process - Ent ry Cr i ter ia


The CMM recommends that inputs satisfy the states described in the table belowbefore entering the process change management process.


Organizational goalsfor software processimprovement

q are quantitative. (L5-32, C1, 1)

q are measurable. (L5-32, C1, 1)

Software processimprovementproposal

is submitted. (L5-39, A5, 1)

The CMM recommends that the conditions described in the table below besatisfied before entering the process change management process.



The organization follows a written policy for implementingsoftware process improvements. (L5-32, C1)

[Refer to Level 5 Policies for additional informationregarding PCM policy.]

Senior management sponsors the organization's activitiesfor software process improvement. (L5-32, C2)

Adequate resources and funding are provided for softwareprocess improvement activities. (L5-33, Ab1)

Resources are allocated to: (L5-33, Ab1, 1)

q Lead, guide, and support the process improvementactivities.

q Maintain the process improvement records.

q Develop, control, and disseminate process changes.

q Establish and operate the administrative and humanresources functions to conduct the communications,motivation, and recognition activities needed tomaintain a high level of employee participation.

Experienced individuals who have expertise in definingand analyzing software processes are available to help theorganization in its process improvement activities. (L5-34,Ab1, 2)

Tools to support process improvement are made available.(L5-34, Ab1, 3)

Software managers receive required training in softwareprocess improvement. (L5-34, Ab2)


PCM Process - Ent ry Cr i te r ia , Continued


The CMM recommends that the conditions described in the table below besatisfied before entering the process change management process, continued fromthe previous page.


The managers and technical staff of the softwareengineering group and other software-related groupsreceive required training in software process improvement.(L5-34, Ab3)

Senior management receives required training in softwareprocess improvement. (L5-35, Ab4)


PCM Process - Inputs

Inputs The table below lists the inputs to the process change management process.


Customer satisfaction indicators. (L5-37,A3, 1.2)

Expected needs. (L5-43, A8, 4)

Long-term goals for software processimprovement. (L5-38, A4, 3)

Long-term goals for software processperformance. (L5-38, A4, 3)

Organization's business plans. (L5-37, A3,1.1)

Organization's strategic operating plans.(L5-37, A3, 1.1)

Organizational goals for software processimprovement. (L5-32, C1, 1)

Plan for software process improvement.(L5-37, A3)


Process improvement goals. (L5-33, C2,4)

Process improvement records. (L5, 33,Ab1, 1.2)

Short-term goals for software processimprovement. (L5-38, A4, 3)

Short-term goals for software processperformance. (L5-38, A4, 3)

Software process improvement issues.(L5-33, C2, 6)

Software process improvement proposal.(L5-36, A2, 4)


PCM Process - Act iv i t ies

Activities The table below lists the recommended activities for the process changemanagement process.


A software process improvement program is establishedwhich empowers the members of the organization toimprove the processes of the organization. (L5-35, A1)

The group responsible for the organization's softwareprocess activities (e.g., software engineering processgroup) coordinates the software process improvementactivities. (L5-36, A2)

The organization develops and maintains a plan for softwareprocess improvement according to a documented procedure.(L5-37, A3)


The software process improvement activities are performedin accordance with the software process improvement plan.(L5-38, A4)

Software process improvement proposals are handledaccording to a documented procedure. (L5-39, A5)


Members of the organization actively participate in teamsto develop software process improvements for assignedprocess areas. (L5-41, A6)

q Each of these process improvement teams is funded andthe activities are planned and scheduled.

q Goals are established for each process improvementeffort; where possible, these goals are definedquantitatively.

q The plans are approved by the managers of theaffected groups and the group that defines andmaintains the affected process descriptions.



PCM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the process changemanagement process, continued from the previous page.


Where appropriate, the software process improvements areinstalled on a pilot basis to determine their benefits andeffectiveness before they are introduced into normalpractice. (L5-42, A7)

q Adjustments to the proposed process improvement aremade and documented during the pilot effort to optimizeits implementation.

q Lessons learned and problems encountered aredocumented.

q The benefits, risks, and impacts of the processimprovement's broader use in the organization areestimated, and the uncertainty in these estimates isassessed.

q A decision is made whether to terminate the effort,proceed with broad-scale implementation of theimprovement, or replan and continue the pilot effort.

When the decision is made to transfer a software processimprovement into normal practice, the improvement isimplemented according to a documented procedure. (L5-42,A8)


Records of software process improvement activities aremaintained. (L5-43, A9)

q Information about the initiation, status, andimplementation of software process improvementproposals is maintained.

q Ready access is provided to the software processimprovement records.

q Historical data are maintained and reports are producedon software process improvements.

Software managers and technical staff receive feedbackon the status and results of the software processimprovement activities on an event-driven basis. (L5-44,A10)

Measurements are made and used to determine the status ofthe software process improvement activities. (L5-45, M1)



PCM Process - Act iv i t ies , Continued


The table below lists the recommended activities for the process changemanagement process, continued from the previous page.


The activities for software process improvement arereviewed with senior management on a periodic basis.(L5-46, V1)

[Refer to PCM Process Reviews and Audits for additionalinformation.]

The software quality assurance group reviews and/or auditsthe activities and work products for software processimprovement and reports the results. (L5-46, V2)

[Refer to PCM Process Reviews and Audits for additionalinformation.]


PCM Process - Outputs

Outputs The table below lists the recommended outputs produced by the process changemanagement process.


Accomplishments of the processimprovement activities. (L5-36, A2, 6)

Adjustments to the proposed processimprovement. (L5-42, A7, 1)

Benefits of each software processimprovement. (L5-40, A5, 3)

Change in software process performance.(L5-43, A8, 2)

Changes to the organization's standardsoftware process. (L5-36, A2, 7)

Changes to the projects' defined softwareprocesses. (L5-47, V2, 4)

Decision rationale (for deciding whether toimplement the software processimprovement proposal). (L5-39, A5, 2)

Decision to transfer a software processimprovement into normal practice. (L5-42,A8)

Decision whether to implement eachsoftware process improvement proposal.(L5-39, A5, 2)

Decision whether to terminate the (pilot)effort, proceed with broad-scaleimplementation of the improvement, orreplan and continue the pilot effort. (L5-42, A7, 4)

Expected benefits of each software processimprovement proposal. (L5-40, A5, 3)

Feedback on the status and results of thesoftware process improvement activities.(L5-44, A10)

Focus on high-priority software processimprovement proposals. (L5-40, A5, 4.1)

Goals for each process improvement effort.(L5-41, A6, 2)

Highest priority process areas forimprovement. (L5-38, A4, 2)


PCM Process - Outputs , Continued

Outputs,continued

The table below lists the recommended outputs produced by the process changemanagement process, continued from the previous page.


Historical data on software processimprovements. (L5-44, A9, 3)

Impacts of each software processimprovement. (L5-42, A7, 3)

Information about the implementation ofsoftware process improvement proposals.(L5-44, A9, 1)

Information about the initiation of softwareprocess improvement proposals. (L5-44,A9, 1)

Information about the status of softwareprocess improvement proposals. (L5-44,A9, 1)

Lessons learned (from piloting softwareprocess improvements). (L5-42, A7, 2)

Measurement plans for software processperformance. (L5-36, A2, 1)

Measurements (to determine the status ofthe software process improvementactivities). (L5-45, M1)

Needed goal changes. (L5-46, V1, 3)

Notification of the disposition of softwareprocess improvement proposals. (L5-41,A5, 11.2)

Organization's long-term goals for processimprovement. (L5-33, C2, 1)

Organization's long-term plans for processimprovement. (L5-33, C2, 1)

Organization's training needs for processimprovement. (L5-36, A2, 3)

Organizational goals for software processperformance. (L5-36, A2, 1)

Organizational plan for software processimprovement. (L5-37, A3)

Plans for process improvement teamactivities. (L5-41, A6, 1)



Outputs,continued



Priority of software process improvementproposals selected for implementation.(L5-40, A5, 4)

Problems encountered (when pilot testingsoftware process improvements). (L5-42,A7, 2)

Process changes. (L5-33, Ab1, 1.3)

Process improvement goals. (L5-33, C2,3)

Process improvement plans to meet these(process improvement) goals. (L5-33, C2,3)

Process measurements. (L5-47, V2, 3)

Prompt acknowledgment of submittedsoftware process improvement proposals.(L5-41, A5, 11.1)

Records of software process improvement.(L5-36, A2, 8)

Reports on software process improvements.(L5-44, A9, 3)

Results (of software quality assurancegroup reviews and/or audits of theactivities and work products for softwareprocess improvement). (L5-46, V2)

Results of tracking status,accomplishments, and participation in theprocess improvement activities (from thegroup responsible for the organization'ssoftware process activities, e.g., softwareengineering process group). (L5-36, A2,6)

Revisions to the plan for software processimprovement. (L5-46, V1, 5)

Risks of each software processimprovement. (L5-42, A7, 3)

Software process improvement. (L5-42,A8)



Outputs,continued



Status of each software processimprovement proposal. (L5-41, A5, 7)

Status of the process improvementactivities. (L5-36, A2, 6)

Strategy for collecting data to measure andtrack the change in software processperformance. (L5-43, A8, 2)

Summary of the major software processimprovement activities. (L5-44, A10, 1)

Summary status of the software processimprovement proposals that are submitted,open, and completed. (L5-44, A10, 3)

Training course materials. (L5-36, A2, 3)

Training courses. (L5-43, A8, 3)

Uncertainty in the estimate of the benefitsof each software process improvementproposal. (L5-42, A7, 3)

Uncertainty in the estimate of the impactsof each software process improvementproposal. (L5-42, A7, 3)

Uncertainty in the estimate of the risks ofeach software process improvementproposal. (L5-42, A7, 3)


PCM Process - Ex i t Cr i ter ia


The CMM recommends that outputs satisfy the states described in the table belowto exit the process change management process.


Accomplishments ofthe processimprovementactivities

are tracked by the groupresponsible for the organization'ssoftware process activities, e.g.,software engineering processgroup. (L5-36, A2, 6)

Adjustments to theproposed processimprovement

q are made during the pilot effortto optimize its implementation.(L5-42, A7, 1)

q are documented during the piloteffort to optimize itsimplementation. (L5-42, A7, 1)

Benefits of eachsoftware processimprovement

q are determined, whereappropriate, (by installing theimprovements) on a pilot basisbefore they are introduced intonormal practice. (L5-42, A7)

q are estimated (for broader use inthe organization based on pilottesting). (L5-42, A7, 3)



PCM Process - Ex i t Cr i te r ia , Continued


The CMM recommends that outputs satisfy the states described in the table belowto exit the process change management process, continued from the previouspage.


Changes to theorganization'sstandard softwareprocess or softwareprocess changes

q are coordinated by the groupresponsible for theorganization's software processactivities, e.g., softwareengineering process group.(L5-36, A2, 7)

q are tracked by the groupresponsible for theorganization's software processactivities, e.g., softwareengineering process group.L5-36, A2, 7)

q that are judged to have a majorimpact on product quality orproductivity or that willsignificantly alter satisfaction ofthe customer and end users arereviewed and approved byappropriate management beforethey are implemented. (L5-41,A5, 9)

q are incorporated into theorganization's standard softwareprocess. (L5-43, A8, 5)

q are incorporated into theprojects' defined softwareprocesses. (L5-43, A8, 6)

Decision rationale(for deciding whetherto implement thesoftware processimprovementproposal)

is documented. (L5-39, A5, 2)

Decision whether toimplement eachsoftware processimprovementproposal

is made. (L5-39, A5, 2)







Decision whether toterminate the (pilot)effort, proceed withbroad-scaleimplementation ofthe improvement, orreplan and continuethe pilot effort

is made. (L5-42, A7, 4)

Expected benefits ofeach softwareprocess improvementproposal

are determined. (L5-40, A5, 3)

Feedback on thestatus and results ofthe software processimprovementactivities

q is received by softwaremanagers and technical staff onan event-driven basis. (L5-44,A10)

q provides a summary of the majorsoftware process improvementactivities. (L5-44, A10, 1)

q provides significant innovationsand actions taken to addresssoftware process improvement.(L5-44, A10, 2)

q provides a summary status of thesoftware process improvementproposals that are submitted,open, and completed. (L5-44,A10, 3)

Focus on high-priority softwareprocess improvementproposals

is maintained. (L5-40, A5, 4.1)

Goals for eachprocess improvementeffort


q are defined quantitatively, wherepossible. (L5-41, A6, 2)

Historical data onsoftware processimprovements

are maintained. (L5-44, A9, 3)






Impacts of eachsoftware processimprovement

are estimated (for broader use in theorganization based on pilot testing).(L5-42, A7, 3).

Information about theimplementation ofsoftware processimprovementproposals


Information about theinitiation of softwareprocess improvementproposals


Information about thestatus of softwareprocess improvementproposals


Lessons learned(from pilotingsoftware processimprovements)


Measurement plansfor software processperformance

are defined by the groupresponsible for the organization'ssoftware process activities (e.g.,software engineering processgroup). (L5-36, A2, 1)

Measurements (todetermine the statusof the softwareprocess improvementactivities)

are made. (L5-45, M1)

are used. (L5-45, M1)

Needed goal changes are identified (during periodic seniormanagement reviews of theactivities for software processimprovement). (L5-46, V1, 3)







Notification of thedisposition ofsoftware processimprovementproposals

is received by submitters of thesoftware process improvementproposals. (L5-41, A5, 11.2)

Organization's long-term goals forprocess improvement


Organization's long-term plans forprocess improvement


Organization'straining needs forprocess improvement

are defined with the participation ofthe group responsible for theorganization's software processactivities (e.g., softwareengineering process group). (L5-36, A2, 3)

Organizational goalsfor software processperformance

q are defined by the groupresponsible for theorganization's software processactivities (e.g., softwareengineering process group).(L5-36, A2, 1)

q are reviewed with seniormanagement for theirendorsement. (L5-36, A2, 2)

Organizational planfor software processimprovement




q is reviewed by the affectedmanagers. (L5-37, A3, 3)







Plans for processimprovement teamactivities

are approved by the managers ofthe affected groups and the groupthat defines and maintains theaffected process descriptions. (L5-41, A6, 3)

Priority of softwareprocess improvementproposals selected forimplementation

is determined. (L5-40, A5, 4)

Problemsencountered (whenpilot testing softwareprocessimprovements)


Process improvementgoals

are reasonable, yet aggressive. (L5-33, C2, 3)

Process improvementplans to meet these(processimprovement) goals

are effective. (L5-33, C2, 3)

Promptacknowledgment ofsubmitted softwareprocess improvementproposals

is received by submitters of thesoftware process improvementproposals. (L5-41, A5, 11.1)

Records of softwareprocess improvement

q are defined,

q are established, and

q are maintained

by the group responsible for theorganization's software processactivities, e.g., softwareengineering process group. (L5-36, A2, 8)

q are readily accessible. (L5-44,A9, 2)

Reports on softwareprocessimprovements

are produced. (L5-44, A9, 3)






Results (of softwarequality assurancegroup reviews and/oraudits of theactivities and workproducts for softwareprocessimprovement)


Results of trackingstatus,accomplishments,and participation inthe processimprovementactivities

are periodically reported to seniormanagement (by the groupresponsible for the organization'ssoftware process activities e.g.,software engineering processgroup). (L5-36, A2, 6)

Revisions to the planfor software processimprovement

are approved (during periodic seniormanagement reviews of theactivities for software processimprovement), as appropriate. (L5-46, V1, 5)

Risks of eachsoftware processimprovement

are estimated (for broader use in theorganization based on pilot testing).(L5-42, A7, 3)

Software processimprovement

is implemented according to adocumented procedure. (L5-42, A8)

Status of eachsoftware processimprovementproposal

is tracked. (L5-41, A5, 7)

Status of the processimprovementactivities

is tracked by the group responsiblefor the organization's softwareprocess activities, e.g., softwareengineering process group. (L5-36, A2, 6)







Strategy forcollecting data tomeasure and trackthe change insoftware processperformance (fromtransferring asoftware processimprovement intonormal practice)



q is agreed to by the individualsresponsible for implementingthe software processes affectedby the change. (L5-43, A8, 2.1)

Training coursematerials

q development is supported by thegroup responsible for theorganization's software processactivities (e.g., softwareengineering process group).(L5-36, A2, 3)

q presentation is supported by thegroup responsible for theorganization's software processactivities (e.g., softwareengineering process group).(L5-36, A2, 3)

Training courses are updated to reflect the currentsoftware process. (L5-43, A8, 3)

Uncertainty in theestimate of thebenefits of eachsoftware processimprovementproposal


Uncertainty in theestimate of theimpacts of eachsoftware processimprovementproposal


Uncertainty in theestimate of the risksof each softwareprocess improvementproposal





The CMM recommends that the conditions described in the table below besatisfied to exit the process change management process.


The organization has quantitative, measurable goals forsoftware process improvement and tracks performanceagainst these goals. (L5-32, C1, 1)

A software process improvement program is establishedwhich empowers the members of the organization toimprove the processes of the organization. (L5-35, A1)

The group responsible for the organization's softwareprocess activities (e.g., software engineering processgroup) coordinates the software process improvementactivities. (L5-36, A2)

The software process improvement activities are performedin accordance with the software process improvement plan.(L5-38, A4)


Each software process improvement proposal is evaluated; adecision is made whether to implement the proposal, andthe decision rationale is documented. (L5-39, A5, 2)

Software process improvement proposals for which theresponse has been unusually long are identified and actedupon. (L5-41, A5, 8)

Each of the process improvement teams is funded and theactivities are planned and scheduled. (L5-41, A6, 1)

Training courses are updated to reflect the current softwareprocess, and training is provided before installing theprocess change for general use. (L5-43, A8, 3)

Consultation support, appropriate to the expected needs, isestablished before installing the process change for broad-scale use and is continued as needed. (L5-43, A8, 4)


PCM Process - Rev iews and Audi ts

Reviews andaudits

The table below lists the recommended reviews and audits for the process changemanagement process.


References

The group responsible for theorganization's software process activities(e.g., software engineering processgroup) reviews the organizational goalsfor process performance with seniormanagement for their endorsement. (L5-36, A2, 2)


Seniormanagement

The group responsible for theorganization's software process activities(e.g., software engineering processgroup) reviews software processimprovement proposals and coordinates theactions for these proposals. (L5-36, A2, 5)


The software process improvement planundergoes peer review. (L5-37, A3, 2)


The software process improvement plan isreviewed by the affected managers. (L5-37, A3, 3)

Affectedmanagers

Software process changes that are judgedto have a major impact on product qualityor productivity or that will significantlyalter satisfaction of the customer and endusers are reviewed and approved byappropriate management before they areimplemented. (L5-41, A5, 9)

Management

Completed software process improvementactions are reviewed, verified, andapproved before they are closed. (L5-41,A5, 10)



The strategy for collecting data to measureand track the change in software processperformance is documented, reviewed, andagreed to. (L5-43, A8, 2)




PCM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the process changemanagement process, continued from the previous page.


References

The activities for software processimprovement are reviewed with seniormanagement on a periodic basis. (L5-46,V1)

These reviews are held to:

q Summarize participation in the processimprovement activities.

q Assess process performance.

q Identify needed goal changes.

q Resolve issues.

q Approve revisions to the softwareprocess improvement plan asappropriate.

Seniormanagement



PCM Process - Rev iews and Audi ts , Continued


The table below lists the recommended reviews and audits for the process changemanagement process, continued from the previous page.


References

The software quality assurance groupreviews and/or audits the activities andwork products for software processimprovement and reports the results. (L5-46, V2)


q The preparation of the organization'ssoftware process improvement plan.

q The process of initiating, submitting,reviewing, approving, and planningimplementation of software processimprovement proposals.

q The degree to which the processmeasurements conform to the softwareprocess descriptions and reflect actualperformance.

q The process for documenting,reviewing, approving, controlling, anddisseminating changes to theorganization's standard softwareprocess and projects' defined softwareprocesses.

q The degree to which software processimprovement activities are consistentlymeasured and tracked.

q The degree to which actual softwareprocess improvement performanceachieves the plans and goals.



PCM Process - Work Products Managed andContro l led


The table below lists the work products recommended to be managed andcontrolled during the process change management process.


Software process improvement plan. (L5-37, A3, 4)


PCM Process - Measurements

Measurements The table below lists the measurements recommended for the process changemanagement process.


Measurements to determine the status of the softwareprocess improvement activities. (L5-45, M1)


q The number of software process improvement proposalssubmitted and implemented for each process area.

q The number of software process improvement proposalssubmitted by each of the projects, groups, anddepartments.

q The number and types of awards and recognitionsreceived by each of the projects, groups, anddepartments.

q The response time for handling software processimprovement proposals.

q The percentage of software process improvementproposals accepted per reporting period.

q The overall change activity, including number, type,and size of changes.

q The effect of implementing each process improvementcompared to its defined goals.

q Overall performance of the organization’s and project’sprocesses, including effectiveness, quality, andproductivity compared to their defined goals.

q Overall productivity and software quality trends for eachproject.

q Process measurements that relate to the indicators ofthe customer’s satisfaction.


PCM Process - Documented Procedures


The table below lists activities in the process change management processrecommended to be performed according to a documented procedure.


The organization develops and maintains a plan for softwareprocess improvement according to a documented procedure.(L5-37, A3)




When the decision is made to transfer a software processimprovement into normal practice, the improvement isimplemented according to a documented procedure. (L5-42,A8)



PCM Process - T ra in ing

Training The table below lists the training recommended for the process changemanagement process.

Training References

Software managers receive required training in softwareprocess improvement. (L5-34, Ab2)

The managers and technical staff of the softwareengineering group and other software-related groupsreceive required training in software process improvement.(L5-34, Ab3)

Senior management receives required training in softwareprocess improvement. (L5-35, Ab4)

Training courses are updated to reflect the current softwareprocess, and training is provided before installing theprocess change for general use. (L5-43, A8, 3)


P C M P r o c e s s - T o o l s

Tools The table below lists the tools recommended for the process change managementprocess.

Tools References

Tools to support process improvement. (L5-34, Ab1, 3)


q statistical analysis tools,

q database systems,

q process automation tools, and


Support tools to record the desired data (to measure andtrack the change in software process performance). (L5-43,A8, 2.2)


Append ices

O v e r v i e w

The appendices and their descriptions are provided in the table below.Appendixcontents

Appendix Title Page

A List of Acronyms Appendix-3

B Glossary of Terms Appendix-5

C Role Translation Table Appendix-21

D General Term Translation Table Appendix-38

E References Appendix-40

CMU/SEI-94-HB-1 Appendix-1

Appendix-2 CMU/SEI-94-HB-1

Appendix A: L ist of Acronyms

List ofacronyms

The table below lists the acronyms in the software process framework and theirmeaning.

Acronym Meaning

CMM Capability maturity model

DP Defect prevention

IC Intergroup coordination

ISM Integrated software management

KPA Key process area

OPD Organization process definition

OPF Organization process focus

PAT Process action team

PCM Process change management

PR Peer reviews

QPM Quantitative process management

RM Requirements management

SCM Software configuration management

SEI Software Engineering Institute

SEPG Software engineering process group

SPE Software product engineering

SPF Software process framework

SPP Software project planning

SPTO Software project tracking and oversight

SQA Software quality assurance

SQM Software quality management

SSM Software subcontract management

TCM Technology change management

TP Training program


Appendix B: Glossary of Terms 1

A

ability to perform (See common features.)

acceptance criteria The criteria that a system or component must satisfy in order to beaccepted by a user, customer, or other authorized entity. [IEEE-STD-610]

acceptance testing Formal testing conducted to determine whether or not a systemsatisfies its acceptance criteria and to enable the customer todetermine whether or not to accept the system. [IEEE-STD-610]

activity Any step taken or function performed, both mental and physical,toward achieving some objective. Activities include all the workthe managers and technical staff do to perform the tasks of theproject and organization. (See task for contrast.)

activities performed (See common features.)

action item (1) A unit in a list that has been assigned to an individual or groupfor disposition. (2) An action proposal that has been accepted.

action proposal A documented suggestion for change to a process or process-relateditem that will prevent the future occurrence of defects identified asa result of defect prevention activities. (See also software processimprovement proposal.)

agent* (See role.)

allocated requirements (See system requirements allocated to software.)

application domain A bounded set of related systems (i.e., systems that address aparticular type of problem). Development and maintenance in anapplication domain usually requires special skills and/or resources.Examples include payroll and personnel systems, command andcontrol systems, compilers, and expert systems.

assessment (See software process assessment.)

audit An independent examination of a work product or set of workproducts to assess compliance with specifications, standards,contractual agreements, or other criteria. [IEEE-STD-610]

B

baseline A specification or product that has been formally reviewed andagreed upon, that thereafter serves as the basis for furtherdevelopment, and that can be changed only through formal changecontrol procedures. [IEEE-STD-610]

baseline configurationmanagement

The establishment of baselines that are formally reviewed andagreed on and serve as the basis for further development. Somesoftware work products, e.g., the software design and the code,should have baselines established at predetermined points, and arigorous change control process should be applied to these items.These baselines provide control and stability when interacting withthe customer. (See also baseline management.)

1 Unless denoted by an asterisk, all terms are as defined in [Paulk93b].


baseline management In configuration management, the application of technical andadministrative direction to designate the documents and changes tothose documents that formally identify and establish baselines atspecific times during the life cycle of a configuration item. [IEEE-STD-610]

benchmark A standard against which measurements or comparisons can bemade. [IEEE-STD-610]

bidder An individual, partnership, corporation, or association that hassubmitted a proposal and is a candidate to be awarded a contract todesign, develop, and/or manufacture one or more products.

C

capability maturity model A description of the stages through which software organizationsevolve as they define, implement, measure, control, and improvetheir software processes. This model provides a guide for selectingprocess improvement strategies by facilitating the determination ofcurrent process capabilities and the identification of the issues mostcritical to software quality and process improvement.

causal analysis The analysis of defects to determine their underlying root cause.

causal analysis meeting A meeting, conducted after completing a specific task, to analyzedefects uncovered during the performance of that task.

commitment A pact that is freely assumed, visible, and expected to be kept byall parties.

commitment to perform (See common features.)

common cause (of a defect) A cause of a defect that is inherently part of a process or system.Common causes affect every outcome of the process and everyoneworking in the process. (See special cause for contrast.)

common features The subdivision categories of the CMM key process areas. Thecommon features are attributes that indicate whether theimplementation and institutionalization of a key process area iseffective, repeatable, and lasting. The CMM common features arethe following:

q commitment to perform: The actions the organization musttake to ensure that the process is established and will endure.Commitment to Perform typically involves establishingorganizational policies and senior management sponsorship.

q ability to perform: The preconditions that must exist in theproject or organization to implement the software processcompetently. Ability to Perform typically involves resources,organizational structures, and training.

q activities performed: A description of the roles and proceduresnecessary to implement a key process area. ActivitiesPerformed typically involve establishing plans and procedures,performing the work, tracking it, and taking corrective actionsas necessary.

Definition continued on next page


common features, continued q measurement and analysis : A description of the need tomeasure the process and analyze the measurements.Measurement and Analysis typically includes examples of themeasurements that could be taken to determine the status andeffectiveness of the Activities Performed.

q verifying implementation: The steps to ensure that the activitiesare performed in compliance with the process that has beenestablished. Verification typically encompasses reviews andaudits by management and software quality assurance.

configuration In configuration management, the functional and physicalcharacteristics of hardware or software as set forth in technicaldocumentation or achieved in a product. [IEEE-STD-610]

configuration control An element of configuration management, consisting of theevaluation, coordination, approval or disapproval, andimplementation of changes to configuration items after formalestablishment of their configuration identification. [IEEE-STD-610]

configuration identification An element of configuration management, consisting of selectingthe configuration items for a system and recording their functionaland physical characteristics in technical documentation. [IEEE-STD-610]

configuration item An aggregation of hardware, software, or both, that is designated forconfiguration management and treated as a single entity in theconfiguration management process. [IEEE-STD-610]

configuration management A discipline applying technical and administrative direction andsurveillance to identify and document the functional and physicalcharacteristics of a configuration item, control changes to thosecharacteristics, record and report change processing andimplementation status, and verify compliance with specifiedrequirements. [IEEE-STD-610]

configuration managementlibrary system

The tools and procedures to access the contents of the softwarebaseline library.

configuration unit The lowest level entity of a configuration item or component thatcan be placed into, and retrieved from, a configuration managementlibrary system.

consistency The degree of uniformity, standardization, and freedom fromcontradiction among the documents or parts of system orcomponent. [IEEE-STD-610]

contingency factor An adjustment (increase) of a size, cost, or schedule plan toaccount for likely underestimates of these parameters due toincomplete specification, inexperience in estimating theapplication domain, etc.

contract terms and conditions The stated legal, financial, and administrative aspects of a contract.

critical computer resource The parameters of the computing resources deemed to be a sourceof risk to the project because the potential need for those resourcesmay exceed the amount that is available. Examples include targetcomputer memory and host computer disk space.

critical path A series of dependent tasks for a project that must be completed asplanned to keep the entire project on schedule.


customer The individual or organization that is responsible for accepting theproduct and authorizing payment to the developing organization.


D

defect A flaw in a system or system component that causes the system orcomponent to fail to perform its required function. A defect, ifencountered during execution, may cause a failure of the system.

defect density The number of defects identified in a product divided by the size ofthe product component (expressed in standard measurement termsfor that product).

defect prevention The activities involved in identifying defects or potential defectsand preventing them from being introduced into a product.

defect root cause The underlying reason (e.g., process deficiency) that allowed adefect to be introduced.

defined level (See maturity level.)

defined software process (See project's defined software process.)

dependency item A product, action, piece of information, etc., that must be providedby one individual or group to a second individual or group so thatthe second individual or group can perform a planned task.

developmental configurationmanagement

The application of technical and administrative direction todesignate and control software and associated technicaldocumentation that define the evolving configuration of a softwarework product during development. Developmental configurationmanagement is under the direct control of the developer. Itemsunder developmental configuration management are not baselines,although they may be baselined and placed under baselineconfiguration management at some point in their development.

deviation A noticeable or marked departure from the appropriate norm, plan,standard, procedure, or variable being reviewed.

documented procedure (See procedure.)

E

effective process A process that can be characterized as practiced, documented,enforced, trained, measured, and able to improve. (See also well-defined process.)

end user The individual or group who will use the system for its intendedoperational use when it is deployed in its environment.

end user representatives A selected sample of end users who represent the total populationof end users.

engineering group A collection of individuals (both managers and technical staff)representing an engineering discipline. Examples of engineeringdisciplines include systems engineering, hardware engineering,system test, software engineering, software configurationmanagement, and software quality assurance.

entry criteria* The conditions under which an activity can be started. Entrycriteria often take the form of a simple or compound predicateabout the state of a work product, role, or activity.

exit criteria* The conditions under which an activity can be declared complete.Exit criteria often take the form of a simple or compound predicateabout the state of an artifact, role, or activity.


evaluation (See software capability evaluation.)

event-driven review/activity A review or activity that is performed based on the occurrence of anevent within the project (e.g., a formal review or the completion ofa life cycle stage). (See periodic review/activity for contrast.)

F

findings The conclusions of an assessment, evaluation, audit, or review thatidentify the most important issues, problems, or opportunities withinthe area of investigation.

first-line software manager A manager who has direct management responsibility (includingproviding technical direction and administering the personnel andsalary functions) for the staffing and activities of a singleorganizational unit (e.g., a department or project team) of softwareengineers and other related staff.

formal review A formal meeting at which a product is presented to the end user,customer, or other interested parties for comment and approval. Itcan also be a review of the management and technical activitiesand of the progress of the project.

function A set of related actions, undertaken by individuals or tools that arespecifically assigned or fitted for their roles, to accomplish a setpurpose or end.

G

goals A summary of the key practices of a key process area that can beused to determine whether an organization or project has effectivelyimplemented the key process area. The goals signify the scope,boundaries, and intent of each key process area.

group The collection of departments, managers, and individuals who haveresponsibility for a set of tasks or activities. A group could varyfrom a single individual assigned part time, to several part-timeindividuals assigned from different departments, to severalindividuals dedicated full time.

H

host computer A computer used to develop software. (See target computer forcontrast.)

I

initial level (See maturity level.)

input* The relationship or link between an activity and a work product.Inputs are the results produced by a prior activity and used by thecurrent activity and may be qualified by the state of a work product.

institutionalization The building of infrastructure and corporate culture that supportmethods, practices, and procedures so that they are the ongoingway of doing business, even after those who originally defined themare gone.


integrated softwaremanagement

The unification and integration of the software engineering andmanagement activities into a coherent defined software processbased on the organization's standard software process and relatedprocess assets.

integration (See software integration.)


K

key practices The infrastructures and activities that contribute most to theeffective implementation and institutionalization of a key processarea.

key process area A cluster of related activities that, when performed collectively,achieve a set of goals considered important for establishing processcapability. The key process areas have been defined to reside at asingle maturity level. They are the areas identified by the SEI to bethe principal building blocks to help determine the software processcapability of an organization and understand the improvementsneeded to advance to higher maturity levels. The level 2 keyprocess areas in the CMM are Requirements Management,Software Project Planning, Software Project Tracking andOversight, Software Subcontract Management, Software QualityAssurance, and Software Configuration Management. The level 3key process areas in the CMM are Organization Process Focus,Organization Process Definition, Training Program, IntegratedSoftware Management, Software Product Engineering, IntergroupCoordination, and Peer Reviews. The level 4 key process areas areQuantitative Process Management and Software QualityManagement. The level 5 key process areas are Defect Prevention,Technology Change Management, and Process ChangeManagement.

L

life cycle (See software life cycle.)

M

maintenance The process of modifying a software system or component afterdelivery to correct faults, improve performance or other attributes,or adapt to a changed environment. [IEEE-STD-610]

managed and controlled The process of identifying and defining software work products thatare not part of a baseline and, therefore, are not placed underconfiguration management but that must be controlled for theproject to proceed in a disciplined manner. "Managed andcontrolled" implies that the version of the work product in use at agiven time (past or present) is known (i.e., version control), andchanges are incorporated in a controlled manner (i.e., changecontrol).

managed level (See maturity level.)

manager A role that encompasses providing technical and administrativedirection and control to individuals performing tasks or activitieswithin the manager's area of responsibility. The traditionalfunctions of a manager include planning, resourcing, organizing,directing, and controlling work within an area of responsibility.


maturity level A well-defined evolutionary plateau toward achieving a maturesoftware process. The five maturity levels in the SEI's CapabilityMaturity Model are:

q initial: The software process is characterized as ad hoc, andoccasionally even chaotic. Few processes are defined, andsuccess depends on individual effort.


maturity level, continued q repeatable: Basic project management processes areestablished to track cost, schedule, and functionality. Thenecessary process discipline is in place to repeat earliersuccesses on projects with similar applications.

q defined: The software process for both management andengineering activities is documented, standardized, andintegrated into a standard software process for the organization.All projects use an approved, tailored version of theorganization's standard software process for developing andmaintaining software.

q managed: Detailed measures of the software process andproduct quality are collected. Both the software process andproducts are quantitatively understood and controlled.

q optimizing: Continuous process improvement is enabled byquantitative feedback from the process and from pilotinginnovative ideas and technologies.

maturity questionnaire A set of questions about the software process that sample the keypractices in each key process area of the CMM. The maturityquestionnaire is used as a springboard to appraise the capability ofan organization or project to execute a software process reliably.

measure A unit of measurement (such as source lines of code or documentpages of design).

measurement The dimension, capacity, quantity, or amount of something (e.g.,300 source lines of code or 7 document pages of design).

method A reasonably complete set of rules and criteria that establish aprecise and repeatable way of performing a task and arriving at adesired result.

methodology A collection of methods, procedures, and standards that defines anintegrated synthesis of engineering approaches to the developmentof a product.

milestone A scheduled event for which some individual is accountable andthat is used to measure progress.

N

nontechnical requirements Agreements, conditions, and/or contractual terms that affect anddetermine the management activities of a software project.

O

operational software The software that is intended to be used and operated in a systemwhen it is delivered to its customer and deployed in its intendedenvironment.


optimizing level (See maturity level.)

organization A unit within a company or other entity (e.g., government agency orbranch of service) within which many projects are managed as awhole. All projects within an organization share a common top-level manager and common policies.

organization's measurementprogram

The set of related elements for addressing an organization'smeasurement needs. It includes the definition of organization-widemeasurements, methods and practices for collecting organizationalmeasurement data, methods and practices for analyzingorganizational measurement data, and measurement goals for theorganization.

organization's softwareprocess assets

A collection of entities, maintained by an organization, for use byprojects in developing, tailoring, maintaining, and implementingtheir software processes. These software process assets typicallyinclude:

q the organization's standard software process,

q descriptions of the software life cycles approved for use,

q the guidelines and criteria for tailoring the organization'sstandard software process,

q the organization's software process database, and

q a library of software process-related documentation.

Any entity that the organization considers useful in performing theactivities of process definition and maintenance could be includedas a process asset.

organization's softwareprocess database

A database established to collect and make available data on thesoftware processes and resulting software work products,particularly as they relate to the organization's standard softwareprocess. The database contains or references both the actualmeasurement data and the related information needed tounderstand the measurement data and assess it for reasonablenessand applicability. Examples of process and work product datainclude estimates of software size, effort, and cost; actual data onsoftware size, effort, and cost; productivity data; peer reviewcoverage and efficiency; and number and severity of defectsfound in the software code.

organization's standardsoftware process

The operational definition of the basic process that guides theestablishment of a common software process across the softwareprojects in an organization. It describes the fundamental softwareprocess elements that each software project is expected toincorporate into its defined software process. It also describes therelationships (e.g., ordering and interfaces) between these softwareprocess elements.

orientation An overview or introduction to a topic for those overseeing orinterfacing with the individuals responsible for performing in thetopic area. (See train for contrast.)


output* The relationship or link between an activity and a work product.Outputs are the results produced by the current activity and used bya subsequent activity and may be qualified by the state of a workproduct.

P

Pareto analysis The analysis of defects by ranking causes from most significant toleast significant. Pareto analysis is based on the principle, namedafter the 19th-century economist Vilfredo Pareto, that most effectscome from relatively few causes, i.e., 80% of the effects come from20% of the possible causes.

peer review A review of a software work product, following defined procedures,by peers of the producers of the product for the purpose ofidentifying defects and improvements.

peer review leader An individual specifically trained and qualified to plan, organize,and lead a peer review.

periodic review/activity A review or activity that occurs at specified regular time intervals.(See event-driven review/activity for contrast.)

policy A guiding principle, typically established by senior management,which is adopted by an organization or project to influence anddetermine decisions.

prime contractor An individual, partnership, corporation, or association thatadministers a subcontract to design, develop, and/or manufactureone or more products.

procedure A written description of a course of action to be taken to perform agiven task. [IEEE-STD-610]

process A sequence of steps performed for a given purpose; for example, thesoftware development process. [IEEE-STD-610]

process capability The range of expected results that can be achieved by following aprocess. (See process performance for contrast.)

process capability baseline A documented characterization of the range of expected results thatwould normally be achieved by following a specific process undertypical circumstances. A process capability baseline is typicallyestablished at an organizational level. (See process performancebaseline for contrast.)

process database (See organization's software process database.)

process description The operational definition of the major components of a process.Documentation that specifies, in a complete, precise, verifiablemanner, the requirements, design, behavior, or other characteristicsof a process. It may also include the procedures for determiningwhether these provisions have been satisfied. Process descriptionsmay be found at the task, project, or organizational level.

process development The act of defining and describing a process. It may includeplanning, architecture, design, implementation, and validation.

process measurement The set of definitions, methods, and activities used to takemeasurements of a process and its resulting products for the purposeof characterizing and understanding the process.


process performance A measure of the actual results achieved by following a process.(See process capability for contrast.)

process performance baseline A documented characterization of the actual results achieved byfollowing a process, which is used as a benchmark for comparingactual process performance against expected process performance.A process performance baseline is typically established at theproject level, although the initial process performance baseline willusually be derived from the process capability baseline. (Seeprocess capability baseline for contrast.)

process tailoring The activity of creating a process description by elaborating,adapting, and/or completing the details of process elements or otherincomplete specifications of a process. Specific business needs fora project will usually be addressed during process tailoring.

product (See software product and software work product.)

profile A comparison, usually in graphical form, of plans or projectionsversus actuals, typically over time.

project An undertaking requiring concerted effort, which is focused ondeveloping and/or maintaining a specific product. The product mayinclude hardware, software, and other components. Typically aproject has its own funding, cost accounting, and delivery schedule.

project's defined softwareprocess

The operational definition of the software process used by a project.The project's defined software process is a well-characterized andunderstood software process, described in terms of softwarestandards, procedures, tools, and methods. It is developed bytailoring the organization's standard software process to fit thespecific characteristics of the project. (See also organization'sstandard software process, effective process, and well-definedprocess.)

project manager The role with total business responsibility for an entire project; theindividual who directs, controls, administers, and regulates aproject building a software or hardware/software system. Theproject manager is the individual ultimately responsible to thecustomer.

project software manager The role with total responsibility for all the software activities for aproject. The project software manager is the individual the projectmanager deals with in terms of software commitments and whocontrols all the software resources for a project.

Q

quality (1) The degree to which a system, component, or process meetsspecified requirements. (2) The degree to which a system,component, or process meets customer or user needs orexpectations. [IEEE-STD-610]

quality assurance (See software quality assurance.)

quantitative control Any quantitative or statistically-based technique appropriate toanalyze a software process, identify special causes of variations inthe performance of the software process, and bring the performanceof the software process within well-defined limits.

R


repeatable level (See maturity level.)

required training Training designated by an organization to be required to perform aspecific role.

risk Possibility of suffering loss.

risk management An approach to problem analysis which weighs risk in a situation byusing risk probabilities to give a more accurate understanding of therisks involved. Risk management includes risk identification,analysis, prioritization, and control.

risk management plan The collection of plans that describe the risk management activitiesto be performed on a project.

role A unit of defined responsibilities that may be assumed by one ormore individuals.

S

senior manager A management role at a high enough level in an organization thatthe primary focus is the long-term vitality of the organization, ratherthan short-term project and contractual concerns and pressures. Ingeneral, a senior manager for engineering would have responsibilityfor multiple projects.

software architecture The organizational structure of the software or module. [IEEE-STD-610]

software baseline audit An examination of the structure, contents, and facilities of thesoftware baseline library to verify that baselines conform to thedocumentation that describes the baselines.

software baseline library The contents of a repository for storing configuration items andthe associated records.

software build An operational version of a software system or component thatincorporates a specified subset of the capabilities the final softwaresystem or component will provide. [IEEE-STD-610]

software capability evaluation An appraisal by a trained team of professionals to identifycontractors who are qualified to perform the software work or tomonitor the state of the software process used on an existingsoftware effort.

software configuration controlboard

A group responsible for evaluating and approving or disapprovingproposed changes to configuration items, and for ensuringimplementation of approved changes.

software development plan The collection of plans that describe the activities to be performedfor the software project. It governs the management of theactivities performed by the software engineering group for asoftware project. It is not limited to the scope of any particularplanning standard, such as DOD-STD-2167A and IEEE-STD-1058,which may use similar terminology.


software engineering group The collection of individuals (both managers and technical staff)who have responsibility for software development and maintenanceactivities (i.e., requirements analysis, design, code, and test) for aproject. Groups performing software-related work, such as thesoftware quality assurance group, the software configurationmanagement group, and the software engineering process group, arenot included in the software engineering group.

software engineering processgroup

A group of specialists who facilitate the definition, maintenance,and improvement of the software process used by the organization.In the key practices, this group is generically referred to as "thegroup responsible for the organization's software process activities."

software engineering staff The software technical people (e.g., analysts, programmers, andengineers), including software task leaders, who perform thesoftware development and maintenance activities for the project,but who are not managers.

software integration A process of putting together selected software components toprovide the set or specified subset of the capabilities the finalsoftware system will provide.

software life cycle The period of time that begins when a software product isconceived and ends when the software is no longer available foruse. The software life cycle typically includes a concept phase,requirements phase, design phase, implementation phase, testphase, installation and checkout phase, operation and maintenancephase, and, sometimes, retirement phase. [IEEE-STD-610]

software manager Any manager, at a project or organizational level, who has directresponsibility for software development and/or maintenance.

software plans The collection of plans, both formal and informal, used to expresshow software development and/or maintenance activities will beperformed. Examples of plans that could be included: softwaredevelopment plan, software quality assurance plan, softwareconfiguration management plan, software test plan, riskmanagement plan, and process improvement plan.

software process A set of activities, methods, practices, and transformations thatpeople use to develop and maintain software and the associatedproducts (e.g., project plans, design documents, code, test cases,and user manuals).

software process assessment An appraisal by a trained team of software professionals todetermine the state of an organization's current software process, todetermine the high-priority software process-related issues facing anorganization, and to obtain the organizational support for softwareprocess improvement.

software process assets (See organization's software process assets.)

software process capability (See process capability.)

software process description The operational definition of a major software process componentidentified in the project's defined software process or theorganization's standard software process. It documents, in acomplete, precise, verifiable manner, the requirements, design,behavior, or other characteristics of a software process. (See alsoprocess description.)


software process element A constituent element of a software process description. Eachprocess element covers a well-defined, bounded, closely related setof tasks (e.g., software estimating element, software designelement, coding element, and peer review element). Thedescriptions of the process elements may be templates to be filledin, fragments to be completed, abstractions to be refined, orcomplete descriptions to be modified or used unmodified.

software process improvementplan

A plan, derived from the recommendations of a software processassessment, that identifies the specific actions that will be taken toimprove the software process and outlines the plans forimplementing those actions. Sometimes referred to as an actionplan.

software process improvementproposal

A documented suggestion for change to a process or process-relateditem that will improve software process capability and performance.(See also action proposal.)

software process maturity The extent to which a specific process is explicitly defined,managed, measured, controlled, and effective. Maturity implies apotential for growth in capability and indicates both the richness ofan organization's software process and the consistency with which itis applied in projects throughout the organization.

software process performance (See process performance.)

software process-relateddocumentation

Example documents and document fragments, which are expectedto be of use to future projects when they are tailoring theorganization's standard software process. The examples may coversubjects such as a project's defined software process, standards,procedures, software development plans, measurement plans, andprocess training materials.

software product The complete set, or any of the individual items of the set, ofcomputer programs, procedures, and associated documentation anddata designated for delivery to a customer or end user. [IEEE-STD-610] (See software work product for contrast.)

software project An undertaking requiring concerted effort, which is focused onanalyzing, specifying, designing, developing, testing, and/ormaintaining the software components and associated documentationof a system. A software project may be part of a project building ahardware/software system.

software quality assurance (1) A planned and systematic pattern of all actions necessary toprovide adequate confidence that a software work product conformsto established technical requirements. (2) A set of activitiesdesigned to evaluate the process by which software work productsare developed and/or maintained.

software quality goal Quantitative quality objectives defined for a software work product.

software quality management The process of defining quality goals for a software product,establishing plans to achieve these goals, and monitoring andadjusting the software plans, software work products, activities, andquality goals to satisfy the needs and desires of the customer andend users.


software-related group A collection of individuals (both managers and technical staff)representing a software engineering discipline that supports, but isnot directly responsible for, software development and/ormaintenance. Examples of software engineering disciplines includesoftware quality assurance and software configuration management.

software requirement A condition or capability that must be met by software needed by auser to solve a problem or achieve an objective. [IEEE-STD-610]

software work product Any artifact created as part of defining, maintaining, or using asoftware process, including process descriptions, plans, procedures,computer programs, and associated documentation, which may ormay not be intended for delivery to a customer or end user. (Seesoftware product for contrast.)

special cause (of a defect) A cause of a defect that is specific to some transient circumstanceand not an inherent part of a process. Special causes providerandom variation (noise) in process performance. (See commoncause for contrast.)

staff The individuals, including task leaders, who are responsible foraccomplishing an assigned function, such as software developmentor software configuration management, but who are not managers.

stage A partition of the software effort that is of a manageable size andthat represents a meaningful and measurable set of related taskswhich are performed by the project. A stage is usually considered asubdivision of a software life cycle and is often ended with a formalreview prior to the onset of the following stage.

standard Mandatory requirements employed and enforced to prescribe adisciplined uniform approach to software development.

standard software process (See organization's standard software process.)

statement of work A description of all the work required to complete a project, whichis provided by the customer.

subcontract manager A manager in the prime contractor's organization who has directresponsibility for administering and managing one or moresubcontracts.

subcontractor An individual, partnership, corporation, or association that contractswith an organization (i.e., the prime contractor) to design, develop,and/or manufacture one or more products.

system A collection of components organized to accomplish a specificfunction or set of functions. [IEEE-STD-610]

system engineering group The collection of individuals (both managers and technical staff)who have responsibility for specifying the system requirements;allocating the system requirements to the hardware, software, andother components; specifying the interfaces between the hardware,software, and other components; and monitoring the design anddevelopment of these components to ensure conformance with theirspecifications.

system requirement A condition or capability that must be met or possessed by a systemor system component to satisfy a condition or capability needed bya user to solve a problem. [IEEE-STD-610]


system requirementsallocated to software

The subset of the system requirements that are to be implementedin the software components of the system. The allocatedrequirements are a primary input to the software development plan.Software requirements analysis elaborates and refines the allocatedrequirements and results in software requirements which aredocumented.

T

tailor To modify a process, standard, or procedure to better match processor product requirements.

target computer The computer on which delivered software is intended to operate.(See host computer for contrast.)

task (1) A sequence of instructions treated as a basic unit of work.[IEEE-STD-610] (2) A well-defined unit of work in the softwareprocess that provides management with a visible checkpoint intothe status of the project. Tasks have readiness criteria(preconditions) and completion criteria (postconditions). (Seeactivity for contrast.)

task kick-off meeting A meeting held at the beginning of a task of a project for thepurpose of preparing the individuals involved to perform theactivities of that task effectively.

task leader The leader of a technical team for a specific task, who hastechnical responsibility and provides technical direction to the staffworking on the task.

team A collection of people, often drawn from diverse but related groups,assigned to perform a well-defined function for an organization or aproject. Team members may be part-time participants of the teamand have other primary responsibilities.

testability (1) The degree to which a system or component facilitates theestablishment of test criteria and the performance of tests todetermine whether those criteria have been met. (2) The degree towhich a requirement is stated in terms that permit establishment oftest criteria and performance of tests to determine whether thosecriteria have been met. [IEEE-STD-610]

technical requirements Those requirements that describe what the software must do and itsoperational constraints. Examples of technical requirementsinclude functional, performance, interface, and qualityrequirements.

technology The application of science and/or engineering in accomplishingsome particular result.

tool* A mechanism that provides the needed support for organizationalpolicies, standards, processes, procedures, and training in order tobuild software products.

traceability The degree to which a relationship can be established between twoor more products of the development process, especially productshaving a predecessor-successor or master-subordinate relationship toone another. [IEEE-STD-610]

train To make proficient with specialized instruction and practice. (Seealso orientation.)


training group The collection of individuals (both managers and staff) who areresponsible for coordinating and arranging the training activities foran organization. This group typically prepares and conducts most ofthe training courses and coordinates use of other training vehicles.

training program The set of related elements that focus on addressing anorganization's training needs. It includes an organization's trainingplan, training materials, development of training, conduct oftraining, training facilities, evaluation of training, and maintenanceof training records.

training waiver A written approval exempting an individual from training that hasbeen designated as required for a specific role. The exemption isgranted because it has been objectively determined that theindividual already possesses the needed skills to perform the role.

U

unit (1) A separately testable element specified in the design of acomputer software component. (2) A logically separable part of acomputer program. (3) A software component that is not subdividedinto other components. [IEEE-STD-610]

user (See end user.)

V

validation The process of evaluating software during or at the end of thedevelopment process to determine whether it satisfies specifiedrequirements. [IEEE-STD-610]

verification The process of evaluating software to determine whether theproducts of a given development phase satisfy the conditionsimposed at the start of that phase. [IEEE-STD-610]

verifying implementation (See common features.)

W

waiver (See training waiver).

well-defined process A process that includes readiness criteria, inputs, standards andprocedures for performing the work, verification mechanisms (suchas peer reviews), outputs, and completion criteria. (See alsoeffective process.)

work product* Any final or intermediate product, service, or result of a process oractivity.


Appendix C: Ro le Trans la t ion Table

This section provides definitions of the major roles that occur in the CMM andblank role translation tables.

Introduction

Reference Refer to Chapter 2, “Features of the Software Process Framework” for additionalinformation regarding role translation tables.

This appendix contains the following sections:In thisappendix

Section Page

Definitions of frequently used roles Appendix-22

Role/KPA matrix Appendix-26

Role translation table Appendix-33


Def in i t ions of Frequent ly Used Roles

Definitions:Major roles

The following describes roles that are frequently referenced in the key practices:

Manager A manager fulfills a role that encompasses providingtechnical and administrative direction and control toindividuals performing tasks or activities within the manager'sarea of responsibility. The traditional functions of a managerinclude planning, resourcing, organizing, directing, andcontrolling work within an area of responsibility.

Senior manager A senior manager fulfills a management role at a high enoughlevel in an organization that the primary focus is the long-term vitality of the organization, rather than short-term projectand contractual concerns and pressures. In general, a seniormanager for engineering would have responsibility formultiple projects. A senior manager also provides and protectsresources for long-term improvement of the software process(e.g., a software engineering process group).

Senior management, as used in the CMM, can denote anymanager who satisfies the above description, up to andincluding the head of the whole organization. As used in thekey practices, the term senior management should beinterpreted in the context of the key process area and theprojects and organization under consideration. The intent is toinclude specifically those senior managers who are needed tofulfill the leadership and oversight roles essential to achievingthe goals of the key process area.

Project manager A project manager fulfills the role with total businessresponsibility for an entire project; the project manager is theindividual who directs, controls, administers, and regulates aproject building a software or hardware/software system. Theproject manager is the individual ultimately responsible to thecustomer.

In a project-oriented organizational structure, most of thepeople working on a project would report to the projectmanager, although some disciplines might have a matrixedreporting relationship. In a matrixed organizational structure,it may be only the business staff who reports to the projectmanager. The engineering groups would then have a matrixedreporting relationship.


Project softwaremanager

A project software manager fulfills the role with totalresponsibility for all the software activities for a project. Theproject software manager is the individual the projectmanager deals with in terms of software commitments andwho controls all the software resources for a project.

The software engineering groups on a project would report tothe project software manager, although some activities suchas tools development might have a matrixed reportingrelationship.




Def in i t ions of Frequent ly Used Roles , Continued

Definitions:Major roles,continued

The following describes roles that are frequently referenced in the key practices,continued from the previous page:

Project softwaremanager,continued

In a large project, the project software manager is likely to bea second-, third-, or fourth-line manager. In a small project ordepartment with a single project, the project softwaremanager might be the first-line software manager or might beat a higher level.

First-linesoftware manager

A first-line software manager fulfills the role with directmanagement responsibility (including providing technicaldirection and administering the personnel and salaryfunctions) for the staffing and activities of a singleorganizational unit (e.g., a department or project team) ofsoftware engineers and other related staff.

Software taskleader

A software task leader fulfills the role of leader of a technicalteam for a specific task. A software task leader has technicalresponsibility and provides technical direction to the staffworking on the task.

The software task leader usually reports to the same first-linesoftware manager as the other people who are working on thetask.

Staff, softwareengineering staff,individuals

Several terms are used in the CMM to denote the individualswho perform the various technical roles described in variouskey practices of the CMM. The staff are the individuals,including task leaders, who are responsible for accomplishingan assigned function, such as software development orsoftware configuration management, but who are notmanagers.

The software engineering staff are the software technicalpeople (e.g., analysts, programmers, and engineers), includingsoftware task leaders, who perform the software developmentand maintenance activities for the project, but who are notmanagers.

The term "individuals" as used in the key practices isqualified and bounded by the context in which the termappears (e.g., "the individual involved in managing thesoftware subcontract").



Definition:Concepts

The fundamental concepts of organization, project, and group must be understoodto interpret the key practices of the Capability Maturity Model properly. Thefollowing paragraphs define the use of these concepts in the CMM:

Organization An organization is a unit within a company or other entity(e.g., government agency or branch of service) within whichmany projects are managed as a whole. All projects within anorganization share a common top-level manager and commonpolicies.

Project A project is an undertaking requiring concerted effort, whichis focused on developing and/or maintaining a specificproduct. The product may include hardware, software, andother components. Typically a project has its own funding,cost accounting, and delivery schedule.

Group A group is the collection of departments, managers, andindividuals who have responsibility for a set of tasks oractivities. A group could vary from a single individualassigned part time, to several part-time individuals assignedfrom different departments, to several individuals dedicatedfull time.

Groups commonly referred to in the CMM are described below:Definitions:Groups

Softwareengineering group

The software engineering group is the collection of individuals(both managers and technical staff) who have responsibilityfor software development and maintenance activities (i.e.,requirements analysis, design, code, and test) for a project.

Groups performing software-related work, such as the softwarequality assurance group, the software configurationmanagement group, and the software engineering processgroup, are not included in the software engineering group.These groups are considered to be one of the "other software-related groups."


A software-related group is the collection of individuals (bothmanagers and technical staff) representing a softwareengineering discipline that supports, but is not directlyresponsible for, software development and/or maintenance.

Examples of software engineering disciplines include softwarequality assurance and software configuration management.

Softwareengineeringprocess group

The software engineering process group is the group ofspecialists who facilitate the definition, maintenance, andimprovement of the software process used by the organization.In the key practices, this group is generically referred to as"the group responsible for the organization's software processactivities."



Definitions:Groups,continued

Groups commonly referred to in the CMM are described below, continued fromthe previous page:

Systemengineering group

The system engineering group is the collection of individuals(both managers and technical staff) who have responsibilityfor specifying the system requirements; allocating the systemrequirements to the hardware, software, and othercomponents; specifying the interfaces between the hardware,software, and other components; and monitoring the designand development of these components to ensure conformancewith their specifications.

System test group The system test group is the collection of individuals (bothmanagers and technical staff) who have responsibility forplanning and performing the independent system testing of thesoftware to determine whether the software product satisfiesits requirements.

Software qualityassurance group

The software quality assurance group is the collection ofindividuals (both managers and technical staff) who plan andimplement the project's quality assurance activities to ensurethe software process steps and standards are followed.

Softwareconfigurationmanagementgroup

The software configuration management group is thecollection of individuals (both managers and technical staff)who have responsibility for planning, coordinating, andimplementing the formal configuration management activitiesfor the software project.

Training group The training group is the collection of individuals (bothmanagers and staff) who are responsible for coordinating andarranging the training activities for an organization. Thisgroup typically prepares and conducts most of the trainingcourses and coordinates use of other training vehicles.


R o l e / K P A M a t r i x

Purpose The purpose of the role/KPA matrix is to allow users to find the roles referenced ina KPA rapidly. A secondary purpose is to allow users to quickly identify theKPAs in which a role is referenced.

Expected use There will be cases in which an organization is focused on only a portion of theCMM, and thus interested in a few KPAs. In this case, the role/KPA matrix willallow the user to make only the neccessary translations.

The following matrix shows each CMM role and the KPA in which it appears.Role/KPAmatrix

L e v e l 2 L e v e l 3 L e v e l4

L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Administrativepersonnel

X

Affected groups X X X X X X X X X X X X

Affected individuals X X X X

Affected managers X

Customer X X X X X X X

Customer SQApersonnel

X

Documentationspecialist

X

End user X X X X X X

Engineering group X X

Experienced individualswho have expertise indefining and analyzingsoftware processes

X

Experts independent ofthe SQA group

X

First-line softwaremanagers

X

Group responsible foranalyzing and allocatingsystem requirements

X

Group responsible forcoordinating theorganization's softwareprocess activities (e.g.,SEPG)

X


R o l e / K P A M a t r i x , Continued

Role/KPAmatrix,continued

The following matrix shows each CMM role and the KPA in which it appears,continued from the previous page.


L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Group responsible forcoordinating thequantitative processmanagement activitiesfor the organization

X

Group responsible forproviding the criticaldependency item

X

Group responsible forsystem and acceptancetesting

X

Group responsible forthe organization’stechnology changemanagement activities

X

Group responsible forthe organization’ssoftware processactivities

X X X X

Group responsible forthe system requirements

X

Group that defines andmaintains the affectedprocess descriptions

X

Groups involved inimplementing thesoftware processes

X

Group that isindependent of thesoftware engineeringgroup

X

Individuals X X X X X X X

Individuals and groupsexternal to theorganization

X X X


Individualsimplementing andsupporting softwarequality management

X







L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Individualsimplementing orsupporting quantitativeprocess management

X

Individuals (involved incoding)

X

Individuals (involved indeveloping the softwarerequirements)

X

Individuals (involved insoftware design)

X

Individuals (responsiblefor the software design)

X

Individuals (responsiblefor the softwarerequirements)

X

Individuals responsiblefor developing theproject's definedsoftware process

X

Individuals responsiblefor implementing thesoftware processes

X

Individuals who developand maintain theorganization's standardsoftware process andrelated process assets

X

Management X X

Manager X X X X X X X

Managers of theaffected groups

X

Managers of thesoftware engineeringgroups

X X

Managers of software-related groups

X X


Members of theorganization

X







L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Organization’s managers X

Peer review checklistdevelopers’ peers

X

Peer review leader X

Peer review checklistpotential users

X

Person responsible foreach configurationitem/unit

X

Person trained inconducting casusalanalysis meetings

X

Prime contractor X

Prime contractor'smanagement

X

Prime contractor's SCMgroup

X

Prime contractor's SQAgroup

X

Producer X

Project

Project manager X X X X X X X X X X X X

Project software manger X X X

Receiving group of acritical dependencyitem

X

Representatives of theproject’s softwareengineering group

X

Representatives of theother engineering groups

X

Representatives of theproject engineeringgroups

X






L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Representatives of thereceiving group of acritical dependencyitem

X

Reviewer X

Senior management X X X X X X X X X X X X X X X X

Senior manager X X X

SCCB X

SCM group X

Software engineeringgroup

X X X X X X X X X X X

Software engineeringmanagers

X

Software engineeringtechnical staff

X

Software engineer X

Software maintainer X

Software manager X X X X X X X X X X X X

Software-related groups X X X X X X X X

Software subcontractor X

Software subcontractorgroups

X

Software subcontractor'smanagement

X

Software subcontractor'ssoftware engineeringgroup

X

Software task leader X X X

Specialty engineers inareas such as safety andreliabilty

X

SQA group X X X X X X X X X X X X X X X

Staff X X

Subcontract bidder X






L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Subcontract manager X

Subcontractor X

Submitters of the actionproposals

X

Submitters of thesoftware processimprovement proposals

X

System engineeringgroup

Task leaders X

Task leaders of othersoftware-related groups

X

Task leaders of thesoftware engineeringgroups

X

Team of peers andexperts

X

Team performing thesoftware task

X X

Team responsible forimplementation ofsoftware processimprovement actions

X

Teams assigned tocoordinate defectprevention activities

X

Teams at another levelin the organization

X

Technical staff X X

Technical staff of thesoftware-related groups

X

Technical staff of thesoftware engineeringgroup

X







L e v e l 5

RM

SPP

SPTO

SSM

SQA

SCM

OPF

OPD

TP

ISM

SPE

IC

PR

QPM

SQM

DP

TCM

PCM

Technology suppliers X

Test group X

Training group ` X X


Role Trans la t ion Table

Roletranslationtable

Fill in the equivalent role for your organization in the table below.

CMM Roles/Groups Your Organization’s Roles/Groups

Administrative personnel

Affected groups

Affected individuals

Affected managers

Customer

Customer SQA personnel

Documentation specialist

End user

Engineering group

Experienced individuals who haveexpertise in defining and analyzingsoftware processes

Experts independent of the SQA group

First-line software managers

Group responsible for analyzing andallocating system requirements

Group responsible for coordinating theorganization's software processactivities (e.g., SEPG)

Group responsible for coordinating thequantitative process managementactivities for the organization

Group responsible for providing thecritical dependency item

Group responsible for system andacceptance testing

Group responsible for the organiza-tion’s technology change managementactivities

Group responsible for the organiza-tion’s software process activities

Group responsible for the systemrequirements

Group that defines and maintains theaffected process descriptions


Role Trans la t ion Tab le , Continued

Roletranslationtable,continued

Fill in the equivalent role for your organization in the table below, continued fromthe previous page.


Groups involved in implementing thesoftware processes

Group that is independent of thesoftware engineering group

Individuals

Individuals and groups external to theorganization

Individuals implementing andsupporting software qualitymanagement

Individuals implementing or supportingquantitative process management

Individuals (involved in coding)

Individuals (involved in developingthe software requirements)

Individuals (involved in softwaredesign)

Individuals (responsible for thesoftware design)

Individuals (responsible for thesoftware requirements)

Individuals responsible for developingthe project's defined software process

Individuals responsible forimplementing the software processes

Individuals who develop and maintainthe organization's standard softwareprocess and related process assets

Management

Manager

Managers of the affected groups

Managers of the software engineeringgroups







Managers of software-related groups

Members of the organization

Organization’s managers

Peer review checklist developers’peers

Peer review leader

Peer review checklist potential users

Person responsible for eachconfiguration item/unit

Person trained in conducting casusalanalysis meetings

Prime contractor

Prime contractor's management

Prime contractor's SCM group

Prime contractor's SQA group

Producer

Project

Project manager

Project software manger

Receiving group of a criticaldependency item

Representatives of the project’ssoftware engineering group

Representatives of the otherengineering groups

Representatives of the projectengineering groups

Representatives of the receiving groupof a critical dependency item

Reviewer

Senior management

Senior manager

SCCB


SCM group

Software engineering group







Software engineering managers

Software engineering technical staff

Software engineer

Software maintainer

Software manager

Software-related groups

Software subcontractor

Software subcontractor groups

Software subcontractor's management

Software subcontractor's softwareengineering group

Software task leader

Specialty engineers in areas such assafety and reliabilty

SQA group

Staff

Subcontract bidder

Subcontract manager

Subcontractor

Submitters of the action proposals

Submitters of the software processimprovement proposals

System engineering group

Task leaders

Task leaders of other software-relatedgroups

Task leaders of the softwareengineering groups

Team of peers and experts

Team performing the software task

Team responsible for implementationof software process improvementactions




Fill in the equivalent role for your organization in the table below, continued fromthe previous page. Blank entries are provide for your use.


Teams assigned to coordinate defectprevention activities

Teams at another level in theorganization

Technical staff

Technical staff of the software-relatedgroups

Technical staff of the softwareengineering group

Technology suppliers

Test group

Training group


Appendix D: Genera l Term Trans la t ion Table

Reference Refer to Chapter 2, “Features of the Software Process Framework” for additionalinformation regarding general term translation tables.

General termtranslationtable

Fill in the equivalent term for your organization in the table below. Blank rowsare provided for additional terms.

CMM General Terms Your Organization’s Term

Organization

Product

Project

Software product

Software project

System


Appendix E : References

[Brooks75] Brooks, Frederick P. No Silver Bullet. Reading, MA: Addison-Wesley,1975.

[Covey89] Covey, Stephen R. The 7 Habits of Highly Effective People. NY, NY:Fireside, Simon & Schuster, 1989.

[Crosby79] Crosby, P. B. Quality is Free. New York, NY: McGraw-Hill, 1979.

[Curtis87] Curtis, Bill, Herb Krasner, Vincent Shen, and Neil Iscoe. "On BuildingSoftware Process Models Under the Lamppost," pp. 96-103. Proceeding of the NinthInternational Conference on Software Engineering, Monterey, CA: IEEE ComputerSociety, March 30 - April 2, 1987.

[Deming82a] Deming, W. E. Quality, Productivity, and Competitive Position.Cambridge, MA: Massachusetts Institute of Technology Center for AdvancedEngineering Study, 1982.

[Deming82b] Deming, W. Edward. Out of the Crisis. Cambridge, MA: MassachusettsInstitute of Technology Center for Advanced Engineering Study, 1982.

[Dion92] Dion, Raymond. "Elements of a Process Improvement Program." IEEESoftware, July 1992, pp. 83-85.

[Fowler90] Fowler, Priscilla, and Stan Rifkin. Software Engineering Process GroupGuide, (CMU/SEI-90-TR-24, ADA235784). Pittsburgh, PA: Software EngineeringInstitute, Carnegie Mellon University, September 1990.

[Humphrey87] Humphrey, W. S., and W. L. Sweet. A Method for Assessing SoftwareEngineering Capability of Contractors - Preliminary Technical Report (CMU/SEI-87-TR-23, ADA200542). Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, 1987.

[Humphrey88] Humphrey, Watts S. "Characterizing the Software Process: A MaturityFramework." IEEE Software 5, 2 (March 1988), pp. 73-79.

[Humphrey89a] Humphrey, W. S. Managing the Software Process. Reading, MA:Addison-Wesley Publishing Company, 1989.

[Humphrey89b] Humphrey, Watts S., David H. Kitson, and Tim C. Kasse. The Stateof Software Engineering Practice: A Preliminary Report (CMU/SEI-89-TR-1,ADA206573). Pittsburgh, PA: Software Engineering Institute, Carnegie MellonUniversity, February 1989.

[Humphrey91] Humphrey, Watts S., Terry R. Snyder, and Ronald R. Willis. "SoftwareProcess Improvement at Hughes Aircraft." IEEE Software, July 1991, pp. 11-23.

[IEEE-STD-610] ANSI/IEEE Std 610.12-1990, IEEE Standard Glossary of SoftwareEngineering Terminology February 1991.

[Ishikawa86] Ishikawa, K. Guide to Quality Control. Tokyo, Japan: Asian ProductivityOrganization, 1986.

[Juran89] Juran, Joseph M. Juran on Leadership for Quality: An ExecutivesHandbook. New York, NY: The Free Press, 1989.


[Juran88a] Juran, J. M. Juran on Planning for Quality. New York, NY: Macmillan,1988.

[Juran88b] Juran, J. M. Juran's Quality Control Handbook. Fourth Edition, New York,NY: McGraw Hill, 1988.

[Kitson92] Kitson, David, H., and Stephen Masters. An Analysis of SEI SoftwareProcess Assessment Results: 1987-1991, (CMU/SEI-92-TR-24). Pittsburgh, PA:Software Engineering Institute, Carnegie Mellon University, July 1992.

[Olson89] Olson, Timothy G., Watts Humphrey, and David Kitson. Conducting SEI-Assisted Software Process Assessments. (CMU/SEI-89-TR-7, ADA219065).Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1989.

[Paulk93a] Paulk, Mark C., Bill Curtis, and Mary Beth Chrissis. Capability MaturityModel for Software, Version 1.1 (CMU/SEI-93-TR-24, ADA263403). Pittsburgh, PA:Software Engineering Institute, Carnegie Mellon University, February 1993.

[Paulk93b] Paulk Mark, Charles Weber, Suzanne Garcia, Mary Beth Chrisis, andMarilyn Bush. Key Practices of the Capability Maturity Model , Version 1.1 (CMU/SEI-93-TR-25, ADA263432) Pittsburgh, PA: Software Engineering Institute, CarnegieMellon University, February 1993.

[Peters92] Peters, Tom. "First Word: To Win with Quality and Service, Focus onCulture, not on Rewards", from On Achieving Excellence, Volume 7, Issue #4, April1992, pp.1-12.

[Radice85] Radice, R. A., J. T. Harding, P. E. Munnis, and R. W. Phillips. "AProgramming Process Study." IBM Systems Journal 24, 2 (1985), pp. 91-101.

[Radice85] Radice, R. A., N. K. Roth Jr., A. C. O'Hara, and W. A. Ciargella. "AProgramming Process Architecture." IBM Systems Journal 24 , 2 (1985), pp. 79-90.

[Sirkin90] Sirkin, Harold and George Stalk, Jr. "Fix the Process, Not the Problem."Harvard Business Review 4, 904II (July-August 1990), pp. 3-8.
