Technical Report CMU/SEI-96-TR-023 ESC-TR-96-023...Cleanroom Software Engineering, by Richard C. Linger and Carmen J. Trammell. The book will be published by the Addison-Wesley Publishing

Technical ReportCMU/SEI-96-TR-023ESC-TR-96-023

Cleanroom Software EngineeringImplementation of the Capability Maturity Model(CMMsm) for Software

Richard C. Linger

Mark C. Paulk

Carmen J. Trammell

December 1996

Technical ReportCMU/SEI-96-TR-023

ESC-TR-96-023December 1996

Cleanroom Software Engineering Implementation of the Capability Maturity Model (CMMsm) for Software

Richard C. Linger

Mark C. Paulk

Software Engineering Institute

Carmen J. Trammell

University of Tennessee

Process Program

Unlimited distribution subject to the copyright

Software Engineering InstituteCarnegie Mellon University

Pittsburgh, PA 15213

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 the interestof 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 © 1996 by Carnegie Mellon University.

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

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

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ONAN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHEREXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FORPURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL.CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOMFROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

This work was created in the performance of Federal Government Contract Number F19628-95-C-0003 with CarnegieMellon University for the operation of the Software Engineering Institute, a federally funded research and developmentcenter. The Government of the United States has a royalty-free government-purpose license to use, duplicate, ordisclose the work, in whole or in part and in any manner, and to have or permit others to do so, for governmentpurposes 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 information onordering, please contact NTIS directly: National Technical Information Service, U.S. Department of Commerce,Springfield, VA 22161. Phone: (703) 487-4600.

This document is also available through the Defense Technical Information Center (DTIC). DTIC provides access to andtransfer of scientific and technical information for DoD personnel, DoD contractors and potential contractors, andother U.S. Government agency personnel and their contractors. To obtain a copy, please contact DTIC directly:Defense Technical Information Center / 8725 John J. Kingman Road / Suite 0944 / Ft. Belvoir, VA 22060-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.

CMU/SEI-96-TR-023 Cleanroom Implementation of the CMM for Software ■ i

Contents

Acknowledgments..................................................................................................................iii

1 Cleanroom and the CMM for Software ...........................................................................1

2 The Capability Maturity Model for Software..................................................................32.1 The Five Maturity Levels.....................................................................................32.2 The Key Process Areas ..........................................................................................42.3 Common Features and Key Practices ................................................................6

3 Cleanroom Software Engineering Processes....................................................................93.1 Cleanroom Management Processes...................................................................9

Project Planning Process..................................................................................9Project Management Process........................................................................10Performance Improvement Process ...........................................................10Engineering Change Process.........................................................................10

3.2 Cleanroom Specification Processes..................................................................11Requirements Analysis Process ..................................................................11Function Specification Process.....................................................................11Usage Specification Process...........................................................................11Architecture Specification Process ..............................................................11Increment Planning Process.........................................................................12

3.3 Cleanroom Development Processes................................................................12Software Reengineering Process..................................................................12Increment Design Process .............................................................................12Correctness Verification Process..................................................................13

3.4 Cleanroom Certification Processes...................................................................13Usage Modeling and Test Planning Process..............................................13Statistical Testing and Certification Process..............................................13

4 Cleanroom Implementation of the CMM for Software..............................................154.1 Cleanroom and the CMM...................................................................................15

4.1.1 Cleanroom/CMM Correspondences .................................................154.1.2 Summary of the Cleanroom/CMM Mapping.................................194.1.3 Interpreting the Cleanroom/CMM Mapping Tables .....................21

■ Cleanroom Implementation of the CMM for Software CMU/SEI-96-TR-023ii

4.2 Cleanroom Implementation of Level 2 KPAs...............................................234.2.1 Requirements Management...............................................................234.2.2 Software Project Planning...................................................................274.2.3 Software Project Tracking and Oversight........................................314.2.4 Software Subcontract Management..................................................364.2.5 Software Quality Assurance ...............................................................414.2.6 Software Configuration Management .............................................45

4.3 Cleanroom Implementation of Level 3 KPAs...............................................494.3.1 Organization Process Focus ................................................................494.3.2 Organization Process Definition........................................................534.3.3 Training Program .................................................................................564.3.4 Integrated Software Management.....................................................594.3.5 Software Product Engineering ...........................................................634.3.6 Intergroup Coordination.....................................................................684.3.7 Peer Reviews..........................................................................................72

4.4 Cleanroom Implementation of Level 4 KPAs...............................................754.4.1 Quantitative Process Management...................................................754.4.2 Software Quality Management..........................................................79

4.5 Cleanroom Implementation of Level 5 KPAs...............................................834.5.1 Defect Prevention .................................................................................834.5.2 Technology Change Management ....................................................884.5.3 Process Change Management.............................................................92

References.................................................................................................................................97

Portions of this Technical Report will appear as part of a book in the SEI Series in Software Engineering, entitledCleanroom Software Engineering, by Richard C. Linger and Carmen J. Trammell. The book will be published by theAddison-Wesley Publishing Company, Reading, Ma.

CMU/SEI-96-TR-023 Cleanroom Implementation of the CMM for Software ■ iii

Acknowledgments

The authors express appreciation to the many reviewers of this document fortheir careful review and excellent suggestions. The reviewers included PhilipHausler, Alan Hevner, David Kelly, Ara Kouchakdjian, Don O’Neill, RosePajerski, Jesse Poore, Ron Radice, Wayne Sherer, and Alan Spangler. Theauthors express special thanks to David Kelly and Wayne Sherer for theirextensive review and comments.

CMU/SEI-96-TR-023 Cleanroom Implementation of the CMM for Software ■ 1

1 Cleanroom and the CMM for Software

The Capability Maturity Modelsm for Software (CMM) [CMU 95] developed by theSoftware Engineering Institute, and Cleanroom Software Engineering [Mills 87,Linger 93, Linger 94] developed by Dr. Harlan Mills and his associates in IBM andother organizations, share a common concern with software quality and theeffectiveness of software development. The principal focus of the CMM is onprocess management maturity; the principal focus of Cleanroom is on rigorousengineering processes. The CMM management processes and the Cleanroomengineering processes are complementary and mutually reinforcing.

The Capability Maturity Model for Software describes the principles and practicesunderlying software process maturity. It is intended to help softwareorganizations improve the maturity of their software processes through anevolutionary path from ad hoc, chaotic processes to mature, disciplined softwareprocesses. The CMM is organized into five maturity levels. The maturity levelsare defined in terms of 18 key process areas (KPAs) that characterize projectperformance at each level.

Cleanroom software engineering is a theory-based engineering process fordevelopment and certification of high-reliability software systems understatistical quality control. Cleanroom is intended to help software organizationsimprove their ability to apply engineering discipline to software development. Cleanroom is defined in terms of 14 processes that implement the technologyand operations involved in Cleanroom software development.

This report defines the Cleanroom software engineering implementation of theCapability Maturity Model for Software. The definition is expressed in terms of amapping of the 14 Cleanroom processes into the 18 CMM key process areas. TheCMM key process areas and the Cleanroom processes are briefly summarized inthis report. They are defined in detail in the following references:

Carnegie Mellon University, Software Engineering Institute (PrincipalContributors and Editors: Mark C. Paulk, Charles V. Weber, Bill Curtis,and Mary Beth Chrissis), The Capability Maturity Model: Guidelines forImproving the Software Process, ISBN 0-201-54664-7, Addison-WesleyPublishing Company, Reading, Ma., 1995.

sm CMM and the Capability Maturity Model are service marks of Carnegie Mellon University.

2 ■ Cleanroom Implementation of the CMM for Software CMU/SEI-96-TR-023

Linger, Richard C. and Carmen J. Trammell, Cleanroom SoftwareEngineering Reference Model (CMU/SEI-96-TR-022). Pittsburgh, Pa.:Carnegie Mellon University, Software Engineering Institute, November1996.

The Cleanroom Software Engineering Reference Model is intended to be acompanion document in reading this technical report.


2 The Capability Maturity Model for Software

This section characterizes the objectives, organization, and content of theCapability Maturity Model for Software. The CMM is organized into fivematurity levels. A maturity level is a well-defined evolutionary plateau towardachieving a mature software process. Each maturity level provides a layer in thefoundation for continuous process improvement.

2.1 The Five Maturity Levels

The following characterizations of the five maturity levels highlight the primaryprocess changes made at each level.

1) Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

2) Repeatable Basic project management processes are established to track cost, schedule, andfunctionality. The necessary process discipline is in place to repeat earliersuccesses on projects with similar applications.

3) Defined The software processes for both management and engineering activities aredocumented, standardized, and integrated into a standard software process forthe organization. All projects use an approved, tailored version of theorganization's standard software process for developing and maintainingsoftware.

4) Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood andcontrolled.

5) Optimizing Continuous process improvement is enabled by quantitative feedback from theprocess and from piloting innovative ideas and technologies.


2.2 The Key Process Areas

Except for level 1, each maturity level is decomposed into several key processareas that indicate the areas an organization should focus on to improve itssoftware process. Key process areas identify the issues that must be addressed toachieve a maturity level. Each key process area identifies a cluster of relatedactivities that, when performed collectively, achieve a set of goals consideredimportant for enhancing process capability. The key process areas and theirpurposes are listed below. The name of each key process area is followed by itstwo-letter abbreviation.

By definition there are no key process areas for level 1.

The key process areas at level 2 focus on the software project's concerns related toestablishing basic project management controls, as summarized below:

Level 2

RequirementsManagement (RM)

Establish a common understanding between the customer and thesoftware project of the customer's requirements that will be addressed bythe software project.

Software ProjectPlanning (PP)

Establish reasonable plans for performing the software engineering andfor managing the software project.

Software ProjectTracking andOversight (PT)

Establish adequate visibility into actual progress so that managementcan take effective actions when the software project's performancedeviates significantly from the software plans.

Software SubcontractManagement (SM)

Select qualified software subcontractors and manage them effectively.

Software QualityAssurance (QA)

Provide management with appropriate visibility into the process beingused by the software project and of the products being built.

SoftwareConfigurationManagement (CM)

Establish and maintain the integrity of the products of the softwareproject throughout the project's software life-cycle.

The key process areas at level 3 address both project and organizational issues, asthe organization establishes an infrastructure that institutionalizes effectivesoftware engineering and management processes across all projects, assummarized below:


Level 3

Organization ProcessFocus (PF)

Establish the organizational responsibility for software processactivities that improve the organization's overall software processcapability.

Organization ProcessDefinition (PD)

Develop and maintain a usable set of software process assets thatimprove process performance across the projects and provide a basis forcumulative, long-term benefits to the organization.

Training Program (TP) Develop the skills and knowledge of individuals so they can performtheir roles effectively and efficiently.

Integrated SoftwareManagement (IM)

Integrate the software engineering and management activities into acoherent, defined project software process that is tailored from theorganization's standard software process and related process assets.

Software ProductEngineering (PE)

Consistently perform a well-defined engineering process that integratesall the software engineering activities to produce correct, consistentsoftware products effectively and efficiently.

Intergroup Coordination(IC)

Establish a means for the software engineering group to participateactively with the other engineering groups so the project is better ableto satisfy the customer's needs effectively and efficiently.

Peer Reviews (PR) Remove defects from the software work products early and efficiently. An important corollary effect is to develop a better understanding ofthe software work products and of the defects that can be prevented.

The key process areas at level 4 focus on establishing a quantitativeunderstanding of both the software process and the software work products beingbuilt, as summarized below:


Level 4

Quantitative ProcessManagement (QP)

Control the process performance of the software project quantitatively.

Software QualityManagement (QM)

Develop a quantitative understanding of the quality of the project'ssoftware products and achieve specific quality goals.

The key process areas at level 5 cover the issues that both the organization andthe projects must address to implement continuous and measurable softwareprocess improvement, as summarized below:

Level 5

Defect Prevention (DP) Identify the root causes of defects and prevent them from recurring.

Technology ChangeManagement (TM)

Identify beneficial new technologies (i.e., tools, methods, andprocesses) and transfer them into the organization in an orderly manner.

Process ChangeManagement (PC)

Continually improve the software processes used in the organizationwith the intent of improving software quality, increasing productivity,and decreasing the cycle time for product development.

2.3 Common Features and Key Practices

For convenience, each of the key process areas is organized by common features. The common features are attributes that indicate whether the implementationand institutionalization of a key process area is effective, repeatable, and lasting. The five common features, followed by their two-letter abbreviations, are listedbelow:

Commitment to Perform(CO)

Describes the actions the organization must take to ensure that theprocess is established and will endure. Includes practices on policy andleadership.

Ability to Perform (AB) Describes the preconditions that must exist in the project ororganization to implement the software process competently. Includespractices on resources, training, and tools.


Activities Performed(AC)

Describes the roles and procedures necessary to implement a key processarea. Includes practices on plans, procedures, work performed, tracking,and corrective action.

Measurement andAnalysis (ME)

Describes the need to measure the process and analyze themeasurements. Includes examples of measurements.

VerifyingImplementation (VE)

Describes the steps to ensure that the activities are performed incompliance with the process that has been established. Includespractices on management reviews and audits.

Each key process area is described in terms of the key practices that contribute tosatisfying its goals. The key practices characterize the infrastructure and activitiesthat contribute most to the effective implementation and institutionalization ofthe key process area and are described in [CMU 95].



3 Cleanroom Software Engineering Processes

Cleanroom software engineering is a software development and certificationprocess based on theoretical foundations in mathematical function theory and applied statistics [Mills, 87, Mills 92]. A principal objective of the Cleanroomprocess is development of software that exhibits zero failures in use. TheCleanroom name is borrowed from hardware Cleanrooms, with their emphasison rigorous engineering methods and focus on defect prevention rather thandefect removal. Cleanroom combines mathematics-based methods of softwarespecification [Mills 86], design, and correctness verification [Linger 79] withstatistical testing [Mills 92, Poore 95, Trammell 95, Walton 95] to certify softwarefitness for use. Cleanroom projects have reported substantial gains in qualityand productivity [Hausler 94, Linger 94, Sherer 96]. Key Cleanroom publicationsare collected in [Poore 96].

The practice of Cleanroom software engineering has been defined in a set of 14processes organized into management, specification, development, andcertification categories. This section provides a brief characterization of theprocesses in terms of tasks and principal work products. A complete descriptionof the processes and work products can be found in [Linger 96]. Work productnames are shown in italics.

3.1 Cleanroom Management Processes

Project Planning Process

Define and document plans for a Cleanroom project, and revise as necessary toaccommodate changes. Review plans with the project team, peer groups, and thecustomer for agreement.

Cleanroom Engineering Guide - Process documentation for a specificCleanroom project, including tailored Cleanroom processes, work productdefinitions, and local policies, protocols, and standards that define how theproject will be conducted.

Software Development Plan - A set of management plans for a specificCleanroom project: Project Mission Plan, Project Organization Plan, WorkProduct Plan, Schedule and Resource Plan, Measurement Plan, Reuse


Analysis Plan, Risk Analysis Plan, Standards Plan, Training Plan, andConfiguration Management Plan.

Project Management Process

Manage the Cleanroom incremental development and certification process todeliver software and associated work products on schedule and within budget. Manage customer interaction. Establish and train Cleanroom teams. Meetprocess performance standards and product quality objectives. Initiate andmonitor Cleanroom processes. Manage project risks and team performance. Usequantitative measurements of product and process performance produced bystatistical testing and certification of successive increments for objectivemanagement decision making.

Project Record - Documentation of actions, reviews, decisions, measures,and other events throughout a project.

Performance Improvement Process

Continually evaluate and improve Cleanroom team performance based onprocess control standards and causal analysis of software failures. Analyze andpilot prospective improvements in Cleanroom processes and tools, andintroduce them to the project as appropriate.

Performance Improvement Plan - Documentation of plans to refine thecurrent Cleanroom process and/or introduce new software processes andtools.

Engineering Change Process

Correct and change the evolving software and associated work products under aprotocol that preserves correctness and is consistent with the ConfigurationManagement Plan. Maintain configuration management discipline andimplement engineering change control for all changes.

Engineering Change Log - The record of engineering change proposals,evaluations, impacts, and status.


3.2 Cleanroom Specification Processes

Requirements Analysis Process

Analyze and define initial customer requirements for the software product, aswell as requirements changes arising from customer assessment of evolvingincrements. Express requirements in user terms and review with the customerfor agreement.

Software Requirements - The functional, usage, performance, andenvironment requirements for a software system to be developed underthe Cleanroom process.

Function Specification Process

Use mathematics-based methods to define the required external behavior of asoftware product in all possible circumstances of use based on the SoftwareRequirements. Express the specification in box structure form. Create complete,consistent and correct specifications, and review with the customer foragreement.

Function Specification - A complete representation of the external view ofa system, typically expressed in terms of the mapping of all possiblestimuli to their corresponding responses in all possible circumstances ofuse; the top-level black box in the box structure usage hierarchy.

Usage Specification Process

Define all classes of users, major patterns of usage, and usage environments for asoftware product based on the Software Requirements. Create complete,consistent, and correct usage specifications, and review with the customer foragreement.

Usage Specification - A description of the expected users, uses, andenvironments of the software. Usage is typically expressed in high-levelMarkov models.

Architecture Specification Process

Analyze architectural assets and define the architecture strategy for the softwareproduct, including major components, high-level structure, and software designstrategies and conventions. Review with the customer for agreement.


Software Architecture - The overall structure of the software, typicallyexpressed as a top-level state box and clear box in the box structure usagehierarchy, together with design strategies and conventions to be usedthroughout development.

Increment Planning Process

Create an incremental development and certification plan for the softwareproduct such that the increments implement user function, accumulate into thefinal system, execute in the system environment, and permit systematic feedbackon process control and product function and quality. Use increment planning tomanage risks and maintain intellectual control over the evolving software.

Increment Construction Plan - A plan that specifies the number ofincrements into which a software system will be divided, the functionsthat will be implemented in each increment, and the schedule andresources allocated for development and certification of each increment.

3.3 Cleanroom Development Processes

Software Reengineering Process

Evaluate and if necessary reengineer candidate reused software for incorporationinto a software product. Restructure reused software and document and verifyits functional semantics as necessary to maintain intellectual control and avoidfailures in execution. Determine the fitness for use of reused software asnecessary through statistical testing in order to achieve project certification goals.

Reengineering Plan - A technical plan for evaluation and possiblereengineering of candidate reused software.

Reengineered Software - Reused software that has been reengineered tomeet product function and quality requirements.

Increment Design Process

Specify, design, and code the increments for a software product through stepwisedecomposition of box structures, typically from stimulus-history-based black boxspecifications into state-based state box specifications, and then into procedure-


based clear box designs containing lower-level black boxes for further refinement. Prepare designs for correctness verification by embedding intended functiondefinitions that specify the effect on data of corresponding control structuredecompositions.

Increment Design - The complete specification, design, and code for asoftware increment, typically represented in black box, state box, and clearbox forms.

Correctness Verification Process

Carry out correctness verification of designs to identify and correct software faultsprior to first execution. Apply function-theoretic methods of correctnessverification in team reviews. Document all faults found and rereview theircorrections.

Increment Verification Report - The record of correctness verificationreviews, including staff members participating, time spent, identificationand classification of faults found, and any other information relevant toassessment of the correctness of the design and code.

3.4 Cleanroom Certification Processes

Usage Modeling and Test Planning Process

Create the usage models to be used for software testing and certification, typicallyexpressed in terms of Markov models defining software usage states andprobabilities of transitions between them. Develop models to satisfy projectobjectives, such as certification for expected operational use, and certification ofinfrequently used functions with high consequences of failure. Analyze usagemodel statistics to provide insight into the testing effort required to meetcertification goals. Develop a statistical test plan, prepare the test environment,and generate the statistical test cases.

Usage Models - The models to be used to generate test cases for softwarecertification.

Increment Test Plan - All information required for statistical testing,including schedules, staffing, training, hardware and softwareenvironment, test case evaluation procedures, certification goals, andstatistical models.


Statistical Test Cases - Test cases randomly generated from usage modelsfor use in statistical testing.

Statistical Testing and Certification Process

Demonstrate the fitness for use of the software in a formal statistical experiment.Execute statistical test cases under experimental control, evaluate results, andinitiate engineering change activity if failures are encountered. Compare thevalues of certification measures obtained in statistical testing to certification goalsto assess the software's fitness for use. Compare measures of testing progress toprocess control standards to assess the likelihood of reaching certification goalswith planned schedules and resources.

Executable System - The executable load modules for testing.

Statistical Testing Report - The record of statistical testing, including testcases executed, failures observed, and any other information relevant toassessing correctness of the software.

Increment Certification Report - The record of measures of product qualityand process control, plus assessments of the measures for testmanagement and product release decisions.


4 Cleanroom Implementation of the CMM forSoftware

4.1 Cleanroom and the CMM

This section discusses the overall mapping of the Cleanroom processes [Linger96] to the Capability Maturity Model for Software [CMU 95].

4.1.1 Cleanroom/CMM Correspondences

The CMM key process areas define required capabilities at each level of maturity.The general correspondence between the KPAs and the Cleanroom processes issummarized in the following tables:

CMM Level 2: Repeatable

Key Process Area Principal Cleanroom Processes

Requirements Management Project PlanningProject ManagementRequirements Analysis

Software Project Planning Project PlanningIncrement Planning

Software Project Tracking & Oversight Project Management

Software Subcontract Management Project PlanningProject ManagementIncrement Planning

Software Quality Assurance Project PlanningProject ManagementCorrectness VerificationStatistical Testing & Certification

Software Configuration Management Project PlanningProject ManagementEngineering Change


CMM Level 3: Defined


Organization Process Focus Project PlanningProject ManagementPerformance Improvement

Organization Process Definition Project PlanningProject ManagementPerformance Improvement

Training Program Project PlanningProject Management

Integrated Software Management Project PlanningProject ManagementIncrement Planning

Software Product Engineering Project PlanningProject ManagementEngineering ChangeRequirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationIncrement PlanningSoftware ReengineeringIncrement DesignCorrectness VerificationUsage Modeling & Test PlanningStatistical Testing & Certification

Intergroup Coordination Project PlanningProject Management

Peer Reviews Project PlanningProject ManagementRequirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationSoftware ReengineeringIncrement DesignCorrectness VerificationUsage Modeling & Test Planning


CMM Level 4: Managed


Quantitative Process Management Project PlanningProject ManagementPerformance ImprovementStatistical Testing & Certification

Software Quality Management Project PlanningProject ManagementPerformance ImprovementCorrectness VerificationStatistical Testing & Certification

CMM Level 5: Optimizing


Defect Prevention Requirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationSoftware ReengineeringIncrement DesignCorrectness VerificationUsage Modeling & Test PlanningPerformance Improvement

Technology Change Management Project ManagementPerformance Improvement

Process Change Management Project ManagementPerformance Improvement

The recurring process management attributes used in the KPAs are variouslycovered in the Cleanroom process definition sections (Objectives, Participants,Entry, Tasks, Verification, Measurement, and Exit) and in the Cleanroom workproducts, as summarized in the following table. The first column lists processmanagement attributes found in the KPAs, and the second column defines theirprincipal location in the Cleanroom processes, in terms of process names, processsections, and work products (shown in italics):


KPA Process Management Attribute Location in Cleanroom Processes

A written policy to do the work exists. Organization’s Cleanroom Engineering Guide

A documented procedure for doing the workexists.

Project Planning: Cleanroom Engineering Guidetailored to the specific project

Responsibility for doing the work has beenestablished.

Project Planning: Project Organization Plan

Affected groups agree to their roles. Project Planning: Verification section

Resources and funding for the work exists. Project Planning: Schedule and Resource PlanProject Management

People are trained to perform the work. Project Planning: Training PlanProject Management

Work products documenting the work arecreated.

Project Planning: Work Product PlanAll processes: Task sections

Baselines for work products are established. Project Planning: Configuration Management Plan

Changes to work products occur in a controlledfashion.

Project Planning: Configuration Management PlanProject ManagementEngineering Change

The status of work is measured. All processes: Measurement sections

The status of work is reviewed by seniormanagement.

All processes: Verification sections

The status of work is reviewed by the projectmanager.

All processes: Verification sections

The status of work is reviewed by the SQAgroup.

Intent is addressed to large degree by Verificationand Exit sections of all processes, and byindependent Statistical Testing & Certificationprocess.

In Sections 4.2 through 4.5 below, each key process area of the CMM is mapped toelements of the Cleanroom processes. KPA Goals, Commitments, Abilities toPerform, Activities, Measurements, and Verifications are listed, together withthe principal Cleanroom Process implementation and an assessment of thecorrespondence of Cleanroom to the KPA elements. Correspondence isevaluated according to the following categories:


Correspondence Category Keyword

The CMM element is consistent with Cleanroom processes, and implementationby Cleanroom processes is high.

High (H)

The CMM element is consistent with Cleanroom processes, and implementationby Cleanroom processes is partial.

Partial (P)

The CMM element is consistent with Cleanroom processes, and implementationby Cleanroom processes is low.

Low (L)

The CMM element is consistent with Cleanroom processes, but is notimplemented in the Cleanroom processes, or is implemented in an indirect way.

Consistent (C)

The CMM element is not included in Cleanroom processes, and an alternativeimplementation is defined by Cleanroom processes.

Alternative (A)

4.1.2 Summary of the Cleanroom/CMM Mapping

The following tables summarize the mapping of Cleanroom into the CMM KPAsin terms of the correspondence categories defined above. The mappings aredetailed in Sections 4.2 through 4.5. The first column in the tables lists the KPAs,the second column defines the overall mapping.

It should be noted that there is a scoping consideration in mapping Cleanroom tothe organizational KPAs (i.e., Organizational Process Focus, OrganizationalProcess Definition, Training Program, Technology Change Management, andProcess Change Management). If Cleanroom is the only process standardized bya software development organization, it might fully address the concerns of anorganizational KPA, and the correspondence would be rated as High. The case ismore likely to be, however, that multiple methodologies will be supported by anorganization, one of which is Cleanroom. In that case, the implementation ofthe organizational KPAs goes beyond the Cleanroom processes, and theCleanroom mapping cannot be more than Partial. This latter case is reflected inthe tables below.


Level 2 KPAs: Repeatable

Key Process Area Cleanroom Implementation

Requirements Management High

Software Project Planning High

Software Project Tracking & Oversight High

Software Subcontract Management Consistent

Software Quality Assurance Partial

Software Configuration Management Partial

Level 3 KPAs: Defined


Organization Process Focus Consistent

Organization Process Definition Partial

Training Program Partial

Integrated Software Management High

Software Product Engineering High

Intergroup Coordination High

Peer Reviews High

Level 4 KPAs: Managed


Quantitative Process Management High

Software Quality Management High

Level 5 KPAs: Optimizing


Defect Prevention High

Technology Change Management Partial

Process Change Management Partial


The CMM and the Cleanroom processes are highly compatible and mutuallysupportive. The focus of the CMM is on management and organization; thefocus of Cleanroom is on technology and its implementation in engineeringprocesses. The combination of these two paradigms provides substantialmanagement and engineering capability.

4.1.3 Interpreting the Cleanroom/CMM Mapping Tables

The following format is used in defining the mappings in the tables of Sections4.2 through 4.5, based on the definition of the Cleanroom Software EngineeringReference Model given in [Linger 96]:

Cleanroom Process names are shown with initial capital letters, e.g.,

Project Planning

If particular sections and/or work products are especially relevant to themapping, the Cleanroom process name is followed by a colon and a moredetailed description. The description may name an entire section in theCleanroom process, e.g.,

Project Planning: Verification section

or identify a more specific item, e.g.,

Project Planning: T1.1

where T1.1 refers to Task 1.1 (the first subtask in Task 1) of ProjectPlanning. The following abbreviations for the sections in the Cleanroomprocesses are used in these descriptions:

O ObjectivesP ParticipantsEn EntryT TasksV VerificationM MeasurementEx Exit


Any such item prefixed with “CE” refers to the Common Elements sectionof the Cleanroom process definitions, for example, CEV1 refers to theCommon Elements Verification 1 item. (The Common Elements werefactored out of the individual processes to achieve a more compactdefinition of the Cleanroom Reference Model.)

Relevant Cleanroom process work products are shown in italics, e.g.,

Project Planning: T1, Cleanroom Engineering Guide

Mappings for KPA elements which have no corresponding Cleanroomelement are shown with a dash symbol (---).

The mappings defined in the following sections are intended to provideguidance and highlight principal areas of correspondence. Tailoring andrefinement of the Cleanroom Reference Model for specific projects may expandor modify the mappings.


4.2 Cleanroom Implementation of Level 2 KPAs

4.2.1 Requirements Management

Correspondence Analysis

Software requirements analysis and documentation are essential Cleanroomactivities. Requirements management is a major aspect of Cleanroomincremental development. Ongoing confirmation or clarification ofrequirements occurs through planned customer evaluation of successiveincrements. New or changed requirements are accommodated through top-down evaluation of impacts on all work products at the outset of eachincrement’s development cycle. As with all Cleanroom work products, therequirements document and all modifications to it are subject to peer review andengineering change control.

Overall correspondence: High

Correspondence Mapping

CMM Process Element Cleanroom Process Implementation

Goals Process Name: Section, Relevant Work Products Corr

GO1 System requirements allocatedto software are controlled toestablish a baseline forsoftware engineering andmanagement use.

Project Planning: CEEnProject Planning: T2.10, Configuration ManagementPlanRequirements Analysis: O3Requirements Analysis: T1, Software RequirementsRequirements Analysis: T2

H

GO2 Software plans, products, andactivities are kept consistentwith the system requirementsallocated to software.

Project Planning: CEO1Project Planning: CEEnProject Planning: T2, Software Development PlanProject Planning: CEV2Project Management: T5Requirements Analysis: En2Increment Planning: Increment Construction Plan

H



Commitment to Perform Process Name: Section, Relevant Work Products Corr

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

Project Planning: T2.10, Configuration ManagementPlanRequirements Analysis

H


Ability to Perform Process Name: Section, Relevant Work Products Corr

AB1 For each project, responsibilityis established for analyzingthe system requirements andallocating them to hardware,software, and other systemcomponents.

Project Planning: T2.2, Project Organization PlanRequirements Analysis

H

AB2 The allocated requirements aredocumented.

Requirements Analysis: T1, Software Requirements H

AB3 Adequate resources and fundingare provided for managing theallocated requirements.

Project Planning: T2.4, Schedule and Resource PlanProject Management: T4

H

AB4 Members of the softwareengineering group and othersoftware-related groups aretrained to perform theirrequirements managementactivities.

Project Planning: T2.9, Training PlanProject Management: T3Project Management: CET1

H


Activities Performed Process Name: Section, Relevant Work Products Corr

AC1 The software engineering groupreviews the allocatedrequirements before they areincorporated into the softwareproject.

Requirements Analysis: V1 H


AC2 The software engineering groupuses the allocated requirementsas the basis for software plans,work products, and activities.

Project Planning: T2Project Management: T4Function Specification: En1Usage Specification: En1Architecture Specification: En1Increment Planning: En1

H

AC3 Changes to the allocatedrequirements are reviewed andincorporated into the softwareproject.

Project Planning: En1Engineering Change: En2Requirements Analysis: En2Function Specification: En2Usage Specification: En2Architecture Specification: En2Increment Planning: En2

H


Measurement and Analysis Process Name: Section, Relevant Work Products Corr

ME1 Measurements are made andused to determine the status ofthe activities for managing theallocated requirements.

Project Planning: T2.5, Measurement PlanProject Management: T5Requirements Analysis: CEM1, Project RecordRequirements Analysis: CEV1Performance Improvement: T1

H


Verifying Implementation Process Name: Section, Relevant Work Products Corr

VE1 The activities for managingthe allocated requirements arereviewed with seniormanagement on a periodicbasis.

Requirements Analysis: CEV1 H

VE2 The activities for managingthe allocated requirements arereviewed with the projectmanager on both a periodic andevent-driven basis.

Requirements Analysis: CEV1 H


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for managing theallocated requirements andreports the results.

While Cleanroom does not include an independentsoftware quality assurance group, the addition ofsuch a group would change this rating to H.

However, a rating of H might be justified without anSQA group. The small team approach of Cleanroomwith its associated checks and balances in teamreviews and verifications helps ensure that SQAactivities are accomplished by alternate methods.

A


4.2.2 Software Project Planning


Cleanroom project planning is robust, with emphasis on an incrementaldevelopment process for managing requirements, risks, resources, reuse, andother technical factors influencing project success. The Cleanroom ReferenceModel incorporates additional CMM requirements for effective planning, such asensuring adequate funding for the planning period itself, using estimates that arederived according to a documented procedure, and gaining explicit agreementsfrom all individuals and groups who have responsibilities related to the project.





GO1 Software estimates aredocumented for use in planningand tracking the softwareproject.

Project Planning: T2.4, Schedule and Resource PlanIncrement Planning: T2, Increment Construction Plan

H

GO2 Software project activities andcommitments are planned anddocumented.

Project Planning: O2Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development PlanIncrement Planning: T1, Increment Construction Plan

H

GO3 Affected groups andindividuals agree to theircommitments related to thesoftware project.

Project Planning: O3Project Planning: V1Increment Planning: O3Increment Planning: V1

H



CO1 A project software manager isdesignated to be responsible fornegotiating commitments anddeveloping the project’ssoftware development plan.

Project Planning: T2.2, Project Organization Plan H


CO2 The project follows a writtenorganizational policy forplanning a software project.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: CEV1

H



AB1 A documented and approvedstatement of work exists for thesoftware project.

Project Planning: En1 H

AB2 Responsibilities for developingthe software development planare assigned.


AB3 Adequate resources and fundingare provided for planning thesoftware project.

Project Planning: T2.2, Project Organization PlanProject Planning: T2.4, Schedule and Resource Plan

H

AB4 The software managers,software engineers, and otherindividuals involved in thesoftware project planning aretrained in the softwareestimating and planningprocedures applicable to theirareas of responsibility.


H



AC1 The software engineering groupparticipates on the projectproposal team.

Project Planning: T2.2, Project Organization PlanProject Management: T2

C

AC2 Software project planning isinitiated in the early stages of,and in parallel with, theoverall project planning.


C


AC3 The software engineering groupparticipates with otheraffected groups in the overallproject planning throughoutthe project’s life.

Project Planning: T2.2, Project Organization PlanProject Planning: V1Project Planning: V2Project Management: T2Project Management: T4Project Management: T5Project Management: CEV1Increment Planning: O3Increment Planning: V1

C

AC4 Software project commitmentsmade to individuals and groupsexternal to the organizationare reviewed with seniormanagement according to adocumented procedure.

Project Planning: T2.2, Project Organization PlanProject Planning: CEV1

H

AC5 A software life cycle withpredefined stages ofmanageable size is identifiedor defined.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.2, Schedule and Resource PlanIncrement Planning: T1, Increment Construction PlanIncrement Planning: T2

H

AC6 The project’s softwaredevelopment plan is developedaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development Plan

H

AC7 The plan for the softwareproject is documented.

Project Planning: T2, Software Development Plan H

AC8 Software work products that are needed to establish andmaintain control of thesoftware project are identified.

Project Planning: T2.3, Work Product Plan H

AC9 Estimates for the size of thesoftware work products (orchanges to the size of softwarework products) are derivedaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.5, Measurement PlanIncrement Planning: T1, Increment Construction Plan

H

AC10

Estimates for the softwareproject’s effort and costs arederived according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule and Resource Plan Project Planning: T2.5, Measurement PlanIncrement Planning: T1, Increment Construction Plan

H

AC11

Estimates for the project’scritical computer resources arederived according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule and Resource PlanProject Planning: T2.5, Measurement PlanIncrement Planning: T1, Increment Construction Plan

H


AC12

The project’s software scheduleis derived according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule and Resource Plan

H

AC13

The software risks associatedwith the cost, resource,schedule, and technical aspectsof the project are identified,assessed, and documented.

Project Planning: T2.7, Risk Analysis PlanProject Management: T6

H

AC14

Plans for the project’s softwareengineering facilities andsupport tools are prepared.

Project Planning: T1.2, Cleanroom Engineering Guide H

AC15

Software planning data arerecorded.

Project Planning: T2, Software Development Plan H



ME1 Measurements are made andused to determine the status ofthe software planningactivities.

Project Planning: CEM1Project Planning: CEV1

H



VE1 The activities for softwareproject planning are reviewedwith senior management on aperiodic basis.

Project Planning: CEV1 H

VE2 The activities for softwareproject planning are reviewedwith the project manager onboth a periodic and event-driven basis.

Project Planning: CEV1 H

VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for software projectplanning and reports theresults.



A


4.2.3 Software Project Tracking and Oversight


Cleanroom emphasizes not only tracking plans against performance, butstatistical control of the software process. As is the case in statistical processcontrol in general, process performance is measured and compared withperformance targets, and deviations are evaluated in the context of the range ofhistorical deviations in performance. The very name of CMM level 2,Repeatable, reflects the importance of such an evaluation. The framework forstatistical process control, first introduced in the Software Tracking andOversight KPA, matures to the Quantitative Process Management and SoftwareQuality Management KPAs at CMM level 4.





GO1 Actual results and performanceare tracked against thesoftware plans.

Project Planning: T2, Software Development PlanProject Management: T5Project Management: CEM1

H

GO2 Corrective actions are takenand managed to closure whenactual results and performancedeviate significantly from thesoftware plans.

Project Management: T5Project Management: CEV1

H

GO3 Changes to softwarecommitments are agreed to by the affected groups andindividuals.

Project Planning: V1Project Planning: V2Increment Planning: V1

H




CO1 A project software manager isdesignated to be responsible forthe project’s softwareactivities and results.


CO2 The project follows a writtenorganizational policy formanaging the software project.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development Plan

H



AB1 A software development planfor the software project isdocumented and approved.

Project Planning: T2, Software Development PlanProject Planning: CEV1

H

AB2 The project software managerexplicitly assignsresponsibility for softwarework products and activities.

Project Planning: T2.2, Project Organization PlanProject Planning: T2.3, Work Product PlanProject Management: T4

H

AB3 Adequate resources and fundingare provided for tracking thesoftware project.


H

AB4 The software managers aretrained in managing thetechnical and personnel aspectsof the software project.


H

AB5 First-line software managersreceive orientation in thetechnical aspects of thesoftware project.


H



AC1 A documented softwaredevelopment plan is used fortracking the softwareactivities and communicatingstatus.

Project Planning: T2 Software Development PlanProject Management: T5Project Management: CEV1

H


AC2 The project’s softwaredevelopment plan is revisedaccording to a documentedprocedure.

Project Planning: En2, T1 Cleanroom EngineeringGuide

H

AC3 Software project commitmentsand changes to commitmentsmade to individuals and groupsexternal to the organizationare reviewed with seniormanagement according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2 Software Development PlanProject Management: CEV1

H

AC4 Approved changes tocommitments that affect thesoftware project arecommunicated to the membersof the software engineeringgroup and other software-related groups.

Project Planning: T2, Software Development PlanProject Planning: V2Project Management: T2Project Management: CEV1Project Management: CEV2

H

AC5 The sizes of the software workproducts (or sizes of thechanges to the software workproducts) are tracked, andcorrective actions are taken asnecessary.

Project Management: T5Project Management: CEM2

H

AC6 The project’s software effortand costs are tracked, andcorrective actions are taken asnecessary.

Project Planning: T2.4, Schedule and Resource PlanProject Management: T5Project Management: CEM1

H

AC7 The projects critical computerresources are tracked, andcorrective actions are taken asnecessary.


H

AC8 The project’s software scheduleis tracked, and correctiveactions are taken as necessary.


H

AC9 Software engineering technicalactivities are tracked, andcorrective actions are taken asnecessary.


H

AC10

The software risks associatedwith cost, resource, schedule,and technical aspects of theproject are tracked.

Project Planning: T2.7, Risk Analysis PlanProject Management: T6Project Management: CEM1

H


AC11

Actual measurement data andreplanning data for thesoftware project are recorded.

Project Planning: T2.5 Measurement PlanProject Management: T5, Project RecordProject Management: CET4

H

AC12

The software engineering groupconducts periodic internalreviews to track technicalprogress, plans, performance,and issues against the softwaredevelopment plan.

Project Management: CEV1Performance Improvement: T1

H

AC13

Formal reviews to address theaccomplishments and results ofthe software project areconducted at selected projectmilestones according to adocumented procedure.

Project Management: CEV1Performance Improvement: T1

H



ME1 Measurements are made andused to determine the status ofthe software tracking andoversight activities.

Project Planning: T2.5, Measurement PlanProject Management: T5Project Management: CEM1, Project RecordProject Management: CEV1Performance Improvement: T1

H



VE1 The activities for softwareproject tracking and oversightare reviewed with seniormanagement on a periodicbasis.

Project Management: CEV1 H

VE2 The activities for softwareproject tracking and oversightare reviewed with the projectmanager on both a periodic andevent-driven basis.



VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for software projecttracking and oversight andreports the results.



A


4.2.4 Software Subcontract Management


The Cleanroom processes do not define explicit management and organizationalactivities for software subcontracting, and thus the overall correspondence withthe Software Subcontract Management KPA is rated as Consistent.

However, Cleanroom provides modern technology and engineering methodsthat can provide effective support for software subcontracting. In this approach,the prime contractor subcontracts for Cleanroom software engineering services.The prime contractor can apply Cleanroom processes in defining the contract andtracking and evaluating subcontractor performance. Cleanroom requiresrigorous specification, design, and certification work products whose propertiescan be objectively assessed by the prime contractor. For example, a subcontractcould include an agreement on required software function and certificationgoals, such that the prime contractor will

• provide software function and usage requirements• define certification goals to be achieved• conduct statistical acceptance testing based on agreed usage models

and the subcontractor will

• develop box structure specifications based on function requirements• develop usage models based on usage requirements• carry out incremental development and delivery• demonstrate achievement of certification goals through statistical testing

based on agreed usage models

Such an agreement defines precise objectives, work products, and completioncriteria for successful subcontract management. In this case, managing thesubcontract amounts to managing a Cleanroom project.

Overall correspondence: Consistent





GO1 The prime contractor selectsqualified softwaresubcontractors.

Ability to perform the Cleanroom processes forms abasis for subcontractor selection.

C

GO2 The prime contractor and thesoftware subcontractor agree totheir commitments to eachother.

- - - C

GO3 The prime contractor and thesoftware subcontractormaintain ongoingcommunications.

-- - C

GO4 The prime contractor tracks thesoftware subcontractor’s actualresults and performanceagainst its commitments.

Project Management: Prime contractor can trackresults of Cleanroom specification, development andcertification.

C



CO1 The project follows a writtenorganizational policy formanaging the softwaresubcontract.

Project Planning: T2.2, Project Organization Plan C

CO2 A subcontract manager isdesignated to be responsible forestablishing and managing thesoftware subcontract.





AB1 Adequate resources and fundingare provided for selecting thesoftware subcontractor andmanaging the subcontract.

Project Planning: T2.4, Schedule and Resource Plan C

AB2 Software managers and otherindividuals who are involvedin establishing and managingthe software subcontract aretrained to perform theseactivities.

Project Planning: T2.9, Training Plan C

AB3 Software managers and otherindividuals who are involvedin managing the softwaresubcontract receive orientationin the technical aspects of thesubcontract.

Project Planning: T2.9, Training Plan C



AC1 The work to be subcontracted isdefined and planned accordingto a documented procedure.

Project PlanningRequirements Analysis: Software RequirementsFunction Specification: Function SpecificationUsage Specification: Usage SpecificationIncrement Planning: Increment Construction Plan

C

AC2 The software subcontractor isselected, based on anevaluation of the subcontractbidder’s ability to perform thework, according to adocumented procedure.

Ability to perform the Cleanroom processes forms abasis for subcontractor evaluation.

C

AC3 The contractual agreementbetween the prime contractorand the software subcontractoris used as the basis formanaging the subcontract.

- - - C

AC4 A documented subcontractor’ssoftware development plan isreviewed and approved by theprime contractor.

Project Planning: V2 C


AC5 A documented and approvedsubcontractor’s softwaredevelopment plan is used fortracking the softwareactivities and communicatingstatus.

Project Management: T5 C

AC6 Changes to the softwaresubcontractor’s statement ofwork, subcontract terms andconditions, and othercommitments are resolvedaccording to a documentedprocedure.

Project Management: CET3Engineering Change

C

AC7 The prime contractor’smanagement conducts periodicstatus/coordination reviewswith the softwaresubcontractor’s management.

Project Management: CEV1 C

AC8 Periodic technical reviews andinterchanges are held with thesoftware subcontractor.

Project Management: T2Project Management: V1

C

AC9 Formal reviews to address thesubcontractor’s softwareengineering accomplishmentsand results are conducted atselected milestones accordingto a documented procedure.

Project Planning: T2.4, Schedule and Resource PlanProject Management: CEV1Performance Improvement: CEV1Increment Planning: T2, Increment Construction Plan

C

AC10

The prime contractor’ssoftware quality assurancegroup monitors thesubcontractor’s softwarequality assurance activitiesaccording to a documentedprocedure.

--- C

AC11

The prime contractor’ssoftware configurationmanagement group monitorsthe subcontractor’s activitiesfor software configurationmanagement according to adocumented procedure.

--- C


AC12

The prime contractor conductsacceptance testing as part ofthe delivery of thesubcontractor’s softwareproducts according to adocumented procedure.

Prime contractor appliesUsage SpecificationUsage Modeling & Test PlanningStatistical Testing & Certification

C

AC13

The software subcontractor’sperformance is evaluated on aperiodic basis, and theevaluation is reviewed withthe subcontractor.

Project Planning: T2.4, Schedule and Resource PlanProject Management: CEV1Performance Improvement: CEV1Increment Planning: T2, Increment Construction Plan

C



ME1 Measurements are made andused to determine the status ofthe activities for managing thesoftware subcontract.


C



VE1 The activities for managingthe software subcontract arereviewed with seniormanagement on a periodicbasis.


VE2 The activities for managingthe software subcontract arereviewed with the projectmanager on both a periodic andevent-driven basis.


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for managing thesoftware subcontract andreports the results.



A


4.2.5 Software Quality Assurance


The Cleanroom processes do not require a separate Software Quality Assurancefunction, although such a function is compatible with Cleanroom operations. Cleanroom does not define explicit management and organizational activitiesfor SQA group operations. The addition of an SQA group would justify anoverall correspondence rating with the Software Quality Assurance KPA of High.

However, quality control is a key element of the Cleanroom processes, whichprovide modern methods for integrating software quality assessment andassurance functions into Cleanroom operations as an intrinsic activity. Inparticular, Cleanroom provides technology and methods for precise softwarespecification and design, correctness verification, scientific quality measurementand certification, and engineering change control. These alternative methodssatisfy the intent of SQA goals 1, 2, and 3, and a rating of High might be justifiedwithout an SQA group. The small team approach of Cleanroom with itsassociated checks and balances in team reviews and verifications helps ensurethat required SQA activities are accomplished through alternate methods. Aconservative rating of overall correspondence with the Software QualityAssurance KPA is Partial.

Overall correspondence: Partial




GO1 Software quality assuranceactivities are planned.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.2, Project Organization PlanProject Planning: T2.5, Measurement PlanProject Planning: T2.7, Risk Analysis PlanProject Planning: T2.10, Configuration ManagementPlanCorrectness VerificationUsage Modeling and Test PlanningStatistical Testing and Certification

H


GO2 Adherence of software productsand activities to theapplicable standards,procedures, and requirements isverified objectively.

Project Management: O1Project Management: O2Project Management: T5Project Management: CEV1Performance Improvement T1Correctness VerificationStatistical Testing & Certification

A

GO3 Affected groups andindividuals are informed ofsoftware quality assuranceactivities and results.

Project Planning: V1Project Planning: V2Project Planning: CET1Project Management: CEV1

H

GO4 Noncompliance issues thatcannot be resolved within thesoftware project are addressedby senior management.




CO1 The project follows a writtenorganizational policy forimplementing software qualityassurance (SQA).

Project Planning: T1.1, Cleanroom Engineering GuideProject Planning: T2, Software Development Plan

H



AB1 A group that is responsible forcoordinating and implementingSQA for the project (i.e., theSQA group) exists.



A

AB2 Adequate resources and fundingare provided for performingthe SQA activities.


H

AB3 Members of the SQA group aretrained to perform their SQAactivities.

Project Planning: T2.9, Training PlanProject Management: T3

A


AB4 The members of the softwareproject receive orientation onthe role, responsibilities,authority, and value of theSQA group.


A



AC1 A SQA plan is prepared for thesoftware project according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.2, Project Organization PlanProject Planning: T2.5, Measurement PlanProject Planning: T2.7, Risk Analysis PlanProject Planning: T2.10, Configuration ManagementPlanCorrectness VerificationUsage Modeling and Test PlanningStatistical Testing and Certification

H

AC2 The SQA group’s activities areperformed in accordance withthe SQA plan.

Project Management: O1Project Management: O2Project Management: T4Project Management: T5Project Management: CEV1Performance Improvement T1Correctness VerificationStatistical Testing & Certification

A

AC3 The SQA group participates inthe preparation and review ofthe project’s softwaredevelopment plan, standards,and procedures.

Project Planning: T2, Software Development PlanProject Planning: V2

A

AC4 The SQA group reviews thesoftware engineering activitiesto verify compliance.

SQA review elements are distributed among Cleanroom processes, especially the following:

Project Management: T5Project Management: CEV1Performance Improvement T1Correctness VerificationStatistical Testing & Certification

A

AC5 The SQA group auditsdesignated software workproducts to verify compliance.

Project Management: T5Project Management: CEV2Correctness Verification: T2Statistical Testing & Certification: T6

A


AC6 The SQA group periodicallyreports the results of itsactivities to the softwareengineering group.

--- C

AC7 Deviations identified in thesoftware activities andsoftware work products aredocumented and handledaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering GuideProject Management: T5Project Management: CET4

H

AC8 The SQA group conductsperiodic reviews of itsactivities and findings withthe customer’s SQA personnel,as appropriate.

- - - C



ME1 Measurements are made andused to determine the cost andschedule status of the SQAactivities.


H



VE1 The SQA activities arereviewed with seniormanagement on a periodicbasis.

Project Management: CEV1 A

VE2 The SQA activities arereviewed with the projectmanager on both a periodic andevent-driven basis.

Project Management: CEV1 A

VE3 Experts independent of theSQA group periodicallyreview the activities andsoftware work products of theproject’s SQA group.

--- C


4.2.6 Software Configuration Management


Cleanroom requires procedures for configuration management of all workproducts associated with specification, development, and certification. Cleanroom processes focus on explicit control of change management activities. However, Cleanroom does not prescribe procedures for defining work productbaselines; this addition and associated management processes would justify achange in the overall correspondence rating from Partial to High.





GO1 Software configurationmanagement activities areplanned.

Project Planning: T2.10, Configuration ManagementPlan

P

GO2 Selected software workproducts are identified,controlled, and available.

Project Planning: T2.3, Work Product PlanProject Planning: T2.10, Configuration ManagementPlanProject Management: T4

P

GO3 Changes to identified softwarework products are controlled.

Project Planning: T2.10, Configuration ManagementPlanProject Management: CEEn2Project Management: CET3Engineering Change

H

GO4 Affected groups andindividuals are informed ofthe status and content ofsoftware baselines.

Project Management: T1Project Management: T2Project Management: CEV2

L




CO1 The project follows a writtenorganizational policy forimplementing softwareconfiguration management.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.10, Configuration ManagementPlan

P



AB1 A board having the authorityfor managing the project’ssoftware baselines (i.e., asoftware configuration controlboard - SCCB) exists or isestablished.

--- C

AB2 A group that is responsible forcoordinating and implementingSCM for the project (i.e., theSCM group) exists.

Project Planning: T2.2, Project Organization Plan P

AB3 Adequate resources and fundingare provided for performingthe SCM activities.


P

AB4 Members of the SCM group aretrained in the objectives,procedures, and methods forperforming their duties.


C

AB5 Members of the softwareengineering group and othersoftware-related groups aretrained to perform their SCMactivities.

Project Planning: T2.9 Training PlanProject Management: T3Project Management: CET1

P



AC1 A SCM plan is prepared foreach software project accordingto a documented procedure.

Project Planning: T2.10, Configuration ManagementPlan

P


AC2 A documented and approvedSCM plan is used as the basisfor performing the SCMactivities.

Project Planning: T2.10, Configuration ManagementPlanProject Planning: V2Project Management: T4

P

AC3 A configuration managementlibrary system is establishedas a repository for the softwarebaselines.

-- - C

AC4 The software work products tobe placed under configurationmanagement are identified.

Project Planning: T2.3, Work Product PlanProject Planning: T2.10, Configuration ManagementPlan

P

AC5 Change requests and problemreports for all configurationitems/units are initiated,recorded, reviewed, approved,and tracked according to adocumented procedure.

Engineering Change: Engineering Change Log H

AC6 Changes to baselines arecontrolled according to adocumented procedure.

Project Planning: T2.10, Configuration ManagementPlanProject Management: CEEn2Project Management: CET3Engineering Change: Engineering Change Log

L

AC7 Products from the softwarebaseline library are createdand their release is controlledaccording to a documentedprocedure.

--- C

AC8 The status of configurationitems/units is recordedaccording to a documentedprocedure.

Project Planning: T2.10, Configuration ManagementPlanEngineering Change: Engineering Change Log

P

AC9 Standard reports documentingthe SCM activities and thecontent of the softwarebaseline are developed andmade available to affectedgroups and individuals.

- - - C

AC10

Software baseline audits areconducted according to adocumented procedure.

--- C




ME1 Measurements are made andused to determine the status ofthe SCM activities.


P



VE1 The SCM activities arereviewed with seniormanagement on a periodicbasis.

Project Management: CEV1 P

VE2 The SCM activities arereviewed with the projectmanager on both a periodic andevent-driven basis.


VE3 The SCM group periodicallyaudits software baselines toverify that they conform to thedocumentation that definesthem.

--- C

VE4 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for SCM and reportsthe results.



A



4.3.1 Organization Process Focus


The Cleanroom processes generally focus on the software project level, and donot define management activities at the organizational level. If Cleanroom isinstantiated at the project level only, therefore, the overall correspondence withthe Organization Process Focus KPA is Consistent. If Cleanroom is the standardorganizational process, however, the correspondence could be Partial or High.

Overall correspondence: Consistent




GO1 Software process developmentand improvement activitiesare coordinated across theorganization.

--- C

GO2 The strengths and weaknessesof the software processes usedare identified relative to aprocess standard.

Project Planning: T2.4, Measurement PlanPerformance Improvement: M1, PerformanceImprovement Plan

P

GO3 Organization-level processdevelopment and improvementactivities are planned.

--- C




CO1 The organization follows awritten organizational policyfor coordinating softwareprocess development andimprovement activities acrossthe organization.

Cleanroom Engineering Guide for the organization C

CO2 Senior management sponsorsthe organization’s activitiesfor software processdevelopment andimprovement.

-- - C

CO3 Senior management overseesthe organization’s activitiesfor software processdevelopment andimprovement.

Project Planning: CEV1, Cleanroom Engineering GuidePerformance Improvement: CEV1, PerformanceImprovement Plan

C



AB1 A group that is responsible forthe organization’s softwareprocess activities exists.


AB2 Adequate resources and fundingare provided for theorganization’s software processactivities.


C

AB3 Members of the groupresponsible for theorganization’s software processactivities receive requiredtraining to perform theseactivities.

Project Planning: T2.9, Training PlanProject Planning: CET1Project Management: T3Project Management: CET1

C

AB4 Members of the softwareengineering group and othersoftware-related groupsreceive orientation on theorganization’s software processactivities and their roles inthose activities.


C




AC1 The software process isassessed periodically, andaction plans are developed toaddress the assessmentfindings.

Performance Improvement: T1, PerformanceImprovement Plan

P

AC2 The organization develops andmaintains a plan for itssoftware process developmentand improvement activities.

Performance Improvement: Performance ImprovementPlan

C

AC3 The organization’s andproject’s activities fordeveloping and improvingtheir software processes arecoordinated at theorganization level.

- - - C

AC4 The use of the organization’ssoftware process database iscoordinated at theorganizational level.

- - - C

AC5 New processes, methods, andtools in limited use in theorganization are monitored,evaluated, and, whereappropriate, transferred toother parts of theorganization.

Performance Improvement: T2, PerformanceImprovement PlanPerformance Improvement: M1

P

AC6 Training for the organization’sand project’s software processesis coordinated across theorganization.

--- C

AC7 The groups involved inimplementing the softwareprocesses are informed of theorganization’s and project’sactivities for software processdevelopment andimprovement.

Project Planning: T2.2, Project Organization PlanProject Planning: V1Performance Improvement: CEV1

C




ME1 Measurements are made andused to determine the status ofthe organization’s processdevelopment and improvementactivities.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordProject Management: T7Performance Improvement: T1, PerformanceImprovement PlanPerformance Improvement: Measurement sectionPerformance Improvement: CEV1

P



VE1 The activities for softwareprocess development andimprovement are reviewedwith senior management on aperiodic basis.

Project Planning: CEV1Project Management: CEV1Performance Improvement: CEV1

P


4.3.2 Organization Process Definition


The Cleanroom processes generally focus on the software project level, and donot define management activities at the organizational level. If Cleanroom isinstantiated at the project level only, therefore, the overall correspondence withthe Organization Process Focus KPA is Partial. If Cleanroom is the standardorganizational process, however, many of the KPA elements would be rated ashaving a High correspondence, and the overall rating could be High.





GO1 A standard software process forthe organization is developedand maintained.

Cleanroom Engineering Guide for the organization P

GO2 Information related to the useof the organization’s standardsoftware process by softwareprojects is collected, reviewed,and made available.

Project Planning: T1, Cleanroom Engineering GuideProject Management: T5Project Management: CET4Project Management: CEV1, Project RecordPerformance Improvement: T1, PerformanceImprovement Plan

P



CO1 The organization follows awritten policy for developingand maintaining a standardsoftware process and relatedprocess assets.

- - - C




AB1 Adequate resources and fundingare provided for developingand maintaining theorganization’s standardsoftware process and relatedprocess assets.


C

AB2 The individuals who developand maintain theorganization’s standardsoftware process and relatedprocess assets receive requiredtraining to perform theseactivities.


C



AC1 The organization’s standardsoftware process is developedand maintained according to adocumented procedure.

--- C

AC2 The organization’s standardsoftware process is documentedaccording to establishedorganization standards.

--- C

AC3 Descriptions of software lifecycles that are approved foruse by the projects aredocumented and maintained.


AC4 Guidelines and criteria for theproject’s tailoring of theorganization’s standardsoftware process are developedand maintained.


AC5 The organization’s softwareprocess database is establishedand maintained.

--- C


AC6 A library of software process-related documentation isestablished and maintained.

--- C



ME1 Measurements are made andused to determine the status ofthe organization’s processdefinition activities.

Project Planning: T2.5, Measurement PlanPerformance Improvement: CEM1, Project RecordPerformance Improvement: CEV1Performance Improvement: T1

P



VE1 The software quality assurancegroup reviews and/or auditsthe organization’s activitiesand work products fordeveloping and maintainingthe organization’s standardsoftware process and relatedprocess assets and reports theresults.



A


4.3.3 Training Program


The Cleanroom processes generally focus on the software project level, and donot define training activities at the organizational level. If Cleanroom isinstantiated at the project level only, therefore, the overall correspondence withthe Organization Process Focus KPA is Partial. If Cleanroom is the standardorganizational process, however, the correspondence could be High.

The Cleanroom processes emphasize and require formal training in projectmanagement, incremental development, software specification, design, andcorrectness verification, and statistical testing and certification.





GO1 Training activities areplanned.

Project Planning: T2.9, Training Plan P

GO2 Training for developing theskills and knowledge needed toperform software managementand technical roles isprovided.


P

GO3 Individuals in the softwareengineering group andsoftware-related groupsreceive the training necessaryto perform their roles.


P



CO1 The organization follows awritten policy for meeting itstraining needs.


C




AB1 A group responsible forfulfilling the training needs ofthe organization exists.

- - - C

AB2 Adequate resources and fundingare provided for implementingthe training program.


P

AB3 Members of the training grouphave the necessary skills andknowledge to perform theirtraining activities.

- - - C

AB4 Software managers receiveorientation on the trainingprogram

Project Planning: T2.9, Training PlanProject Planning: V2Project Planning: CET1

P



AC1 Each software project developsand maintains a training planthat specifies its trainingneeds.

Project Planning: T2.9, Training Plan H

AC2 The organization’s trainingplan is developed and revisedaccording to a documentedprocedure.

--- C

AC3 The training for theorganization is performed inaccordance with theorganization’s training plan.


P

AC4 Training courses prepared atthe organization level aredeveloped and maintainedaccording to organizationstandards.

--- C


AC5 A waiver procedure forrequired training isestablished and used todetermine whetherindividuals already possessthe knowledge and skillsrequired to perform in theirdesignated roles.

- - - C

AC6 Records of training aremaintained.

--- C



ME1 Measurements are made andused to determine the status ofthe training programactivities.

- - - C

ME2 Measurements are made andused to determine the qualityof the training program.

--- C



VE1 The training programactivities are reviewed withsenior management on aperiodic basis.


VE2 The training program isindependently evaluated on aperiodic basis for consistencywith, and relevance to, theorganization’s needs.

--- C

VE3 The training programactivities and work productsare reviewed and/or auditedand the results are reported.

--- C


4.3.4 Integrated Software Management


Cleanroom project plans are developed and tailored based on the CleanroomReference Model, and the Cleanroom incremental development life cycle affordsa stepwise, controlled framework for managing project performance, reducingrisk, and reviewing and revising project plans.





GO1 The project’s defined softwareprocess is a tailored version ofthe organization’s standardsoftware process.

Project Planning: O1Project Planning: T1, Cleanroom Engineering Guide

H

GO2 The project is planned andmanaged according to theproject’s defined softwareprocess.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development PlanProject ManagementProject Management: T5Project Management: CEV1

H



CO1 The project follows a writtenorganizational policy requiringthat the software project beplanned and managed using theorganization’s standardsoftware process and relatedprocess assets.

Project Planning: O2Project Planning: T1, Cleanroom Engineering GuideProject Management

H




AB1 Adequate resources and fundingare provided for managing thesoftware project using theproject’s defined softwareprocess.


H

AB2 The individuals responsible fordeveloping the project’sdefined software processreceive required training inhow to tailor theorganization’s standardsoftware process and use therelated process assets.


H

AB3 The software managers receiverequired training in managingthe technical, administrative,and personnel aspects of thesoftware project based on theproject’s defined softwareprocess.


H



AC1 The project’s defined softwareprocess is developed bytailoring the organization’sstandard software processaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering Guide H

AC2 Each project’s defined softwareprocess is revised according to adocumented procedure.

Project Planning: En2Project Planning: T1, Cleanroom Engineering GuidePerformance Improvement: T1, PerformanceImprovement Plan

H


AC3 The project’s softwaredevelopment plan, whichdescribes the use of theproject’s defined softwareprocess, is developed andrevised according to adocumented procedure.

Project Planning: En1Project Planning: En2Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development Plan

H

AC4 The software project ismanaged in accordance withthe project’s defined softwareprocess.

Project Management: T4Project Management: T5

H

AC5 The organization’s softwareprocess database is used forsoftware planning andestimating.

--- C

AC6 The size of the software workproducts (or size of changes tothe software work products) ismanaged according to adocumented procedure.

Project Planning: T2.3, Work Product PlanProject Planning: T2.5, Measurement PlanProject Management: T4Project Management: T5Increment Planning: T1, Increment Construction Plan

H

AC7 The project’s software effortand costs are managedaccording to a documentedprocedure.

Project Planning: T2.4 ,Schedule and Resource PlanProject Management: T4Project Management: T5

H

AC8 The project’s critical computerresources are managedaccording to a documentedprocedure.


H

AC9 The critical dependencies andcritical paths of the project’ssoftware schedule are managedaccording to a documentedprocedure.

Project Planning: T2.4, Schedule and Resource PlanProject Management: T4Project Management: T5Increment Planning: T1, Increment Construction PlanIncrement Planning: T2

H

AC10

The project’s software risks areidentified, assessed,documented, and managedaccording to a documentedprocedure.

Project Planning: T2.7, Risk Analysis PlanProject Management: T6Project Management: CEV1

H


AC11

Reviews of the software projectare periodically performed todetermine the actions neededto bring the software project’sperformance and results in linewith the current and projectedneeds of the business, customer,and end users, as appropriate.




ME1 Measurements are made andused to determine theeffectiveness of the integratedsoftware managementactivities.


H



VE1 The activities for managingthe software project arereviewed with seniormanagement on a periodicbasis.


VE2 The activities for managingthe software project arereviewed with the projectmanager on both a periodic andevent-driven basis.


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for managing thesoftware project and reportsthe results.



A


4.3.5 Software Product Engineering


The Cleanroom processes and work products provide a completeimplementation of the Software Product Engineering KPA for softwaremanagement, requirements, specification, architecture, design, verification,testing, and certification. Cleanroom also supports reuse and reengineering ofsoftware within the SPE context. With respect to SPE Activity 6, integration testing is not a separate activity in theCleanroom process. In Cleanroom, integration is intrinsic to the stepwiseincremental development and certification process. Certification testing ofsuccessive increment accumulations is carried out in the system environment.





GO1 The software engineering tasksare defined, integrated, andconsistently performed toproduce the software.

Project Planning: Cleanroom Engineering Guide,Software Development PlanProject Management: Project RecordEngineering Change: Engineering Change LogRequirements Analysis: Software RequirementsFunction Specification: Function SpecificationUsage Specification: Usage SpecificationArchitecture Specification: Software ArchitectureIncrement Planning: Increment Construction PlanSoftware Reengineering: Reengineering Plan, Reengineered SoftwareIncrement Design: Increment DesignCorrectness Verification: Increment VerificationReportUsage Modeling & Test Planning: Usage Models,Increment Test Plan, Statistical Test CasesStatistical Testing & Certification: ExecutableSystem, Statistical Testing Report, IncrementCertification Report

H


GO2 Software work products arekept consistent with eachother.

Project Planning: T2.10, Configuration ManagementPlanAll GO1 processes: CEO1All GO1 processes: CET3Engineering Change

H



CO1 The project follows a writtenorganizational policy forperforming the softwareengineering activities.

Project Planning: T1, Cleanroom Engineering GuideProject Management: T4

H



AB1 Adequate resources and fundingare provided for performingthe software engineering tasks.


H

AB2 Members of the softwareengineering technical staffreceive required training toperform their technicalassignments.


H

AB3 Members of the softwareengineering technical staffreceive orientation in relatedsoftware engineeringdisciplines.


H

AB4 The project manager and allsoftware managers receiveorientation in technical aspectsof the software project.


H




AC1 Appropriate softwareengineering methods and toolsare integrated into the project’sdefined software process.

Project Planning: T1, Cleanroom Engineering GuidePerformance Improvement: T2, PerformanceImprovement Plan

H

AC2 The software requirements aredeveloped, maintained,documented, and verified bysystematically analyzing theallocated requirementsaccording to the project’sdefined software process.

Project Planning: T1, Cleanroom Engineering GuideRequirements Analysis: Software Requirements

H

AC3 The software design isdeveloped, maintained,documented, and verified,according to the project’sdefined software process, toaccommodate the softwarerequirements and to form theframework for coding.

Project Planning: Cleanroom Engineering Guide,Software Development PlanProject Management: Project RecordEngineering Change: Engineering Change LogRequirements Analysis: Software RequirementsFunction Specification: Function SpecificationArchitecture Specification: Software ArchitectureIncrement Planning: Increment Construction PlanSoftware Reengineering: Reengineered SoftwareIncrement Design: Increment DesignCorrectness Verification: Increment VerificationReport

H

AC4 The software code isdeveloped, maintained,documented, and verified,according to the project’sdefined software process, toimplement the softwarerequirements and softwaredesign.

Project Planning: Cleanroom Engineering Guide,Software Development PlanProject Management: Project RecordEngineering Change: Engineering Change LogIncrement Planning: Increment Construction PlanSoftware Reengineering: Reengineered SoftwareIncrement Design: Increment DesignCorrectness Verification: Increment VerificationReport

H

AC5 Software testing is performedaccording to the project’sdefined software process.

Project Planning: T1, Cleanroom Engineering GuideProject Management: Project RecordUsage Specification: Usage SpecificationIncrement Planning: T2, Increment Construction PlanUsage Modeling & Test Planning: Usage Models,Increment Test Plan, Statistical Test CasesStatistical Testing & Certification: ExecutableSystem, Statistical Testing Report, IncrementCertification Report

H


AC6 Integration testing of thesoftware is planned andperformed according to theproject’s defined softwareprocess.

In Cleanroom, integration is accomplished throughincremental development. Each increment is testedin the system environment, as described in AC7.

H

AC7 System and acceptance testingof the software are plannedand performed to demonstratethat the software satisfies itsrequirements.

Project Management: T2.4, Schedule and ResourcePlanUsage Specification: Usage SpecificationIncrement Planning: Increment Construction PlanUsage Modeling & Test Planning: Usage Models,Increment Test Plan, Statistical Test CasesStatistical Testing & Certification: ExecutableSystem, Statistical Testing Report, IncrementCertification Report

H

AC8 The documentation that willbe used to operate andmaintain the software isdeveloped and maintainedaccording to the project’sdefined software process.

Project Planning: T2.3, Work Product Plan H

AC9 Data on defects identified inpeer reviews and testing arecollected and analyzedaccording to the project’sdefined software process.

Project Planning: T2.5, Measurement PlanAll GO1 processes: CEO2All GO1 processes: Verification sectionAll GO1 processes: CEM1All GO1 processes: CEM2Engineering Change: Engineering Change LogCorrectness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement: T1, PerformanceImprovement Plan

H

AC10

Consistency is maintainedacross software work products,including the software plans,process descriptions, allocatedrequirements, softwarerequirements, software design,code, test plans, and testprocedures.

Project Planning: T2.10, Configuration ManagementPlanAll GO1 processes: CEO1All GO1 processes: CET3Engineering Change

H




ME1 Measurements are made andused to determine thefunctionality and quality ofthe software products.

Project Planning: T2.5, Measurement PlanProject Management: T5All GO1 processes: Measurement and VerificationsectionsCorrectness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification Report

H

ME2 Measurements are made andused to determine the status ofthe software productengineering activities.

Project Planning: T2.5, Measurement PlanProject Management: T5All GO1 processes: Measurement and VerificationsectionsCorrectness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement: T1

H



VE1 The activities for softwareproduct engineering arereviewed with seniormanagement on a periodicbasis.

All GO1 processes: CEV1 H

VE2 The activities for softwareproduct engineering arereviewed with the projectmanager on both a periodic andevent-driven basis.

All GO1 processes: CEV1 H

VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for software productengineering and reports theresults.



A


4.3.6 Intergroup Coordination


Cleanroom specifies the roles, responsibilities, and dependencies amongindividuals and groups on the project team by prescribing the engineeringmethods through which they will work and the work products through whichthey will communicate. In addition, Cleanroom processes require customer andpeer group review, coordination, and concurrence throughout the period ofsoftware project performance.





GO1 The customer’s requirementsare agreed to by all affectedgroups.

Project Planning: T2, Software Development PlanProject Planning: V2Requirements Analysis: T1, Software RequirementsRequirements Analysis: V2

H

GO2 The commitments between theengineering groups are agreedto by the affected groups.

Project Planning: T2.2, Project Organization PlanProject Planning: V2

H

GO3 The engineering groupsidentify, track, and resolveintergroup issues.




CO1 The project follows a writtenorganizational policy forestablishing interdisciplinaryengineering teams.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.2, Project Organization PlanProject Management: T3

H




AB1 Adequate resources and fundingare provided for coordinatingthe software engineeringactivities with otherengineering groups.


H

AB2 The support tools used by thedifferent engineering groupsare compatible to enableeffective communication andcoordination.

Project Planning: T1.2, Cleanroom Engineering Guide C

AB3 All managers in theorganization receive requiredtraining in teamwork.


H

AB4 All task leaders in eachengineering group receiveorientation in the processes,methods, and standards usedby the other engineeringgroups.

Project Planning: T2.9, Training PlanProject Management: T2Project Management: T3Project Management: CET1

H

AB5 The members of the engineeringgroups receive orientation inworking as a team.


H



AC1 The software engineering groupand the other engineeringgroups participate with thecustomer and end users, asappropriate, to establish thesystem requirements.

Project Planning: T2.1 Project Mission PlanProject Planning: V2Project Management: T1Requirements Analysis: T1Requirements Analysis: T2

H

AC2 Representatives of the project’ssoftware engineering groupwork with representatives ofthe other engineering groups tomonitor and coordinatetechnical activities andresolve technical issues.

Project Planning: T2.2, Project Organization PlanProject Management: T2Project Management: T4Project Management: V1Project Management: CEV1

H


AC3 A documented plan is used tocommunicate intergroupcommitments and to coordinateand track the work performed.

Project Planning: T2.2, Project Organization PlanProject Management: T2, Project RecordProject Management: CEV1

H

AC4 Critical dependencies betweenengineering groups areidentified, negotiated, andtracked according to adocumented procedure.

Project Planning: T2.2 Project Organization PlanProject Planning: V2Project Management: T2Project Management: T5Project Management: CEV1

H

AC5 Work products produced asinput to other engineeringgroups are reviewed byrepresentatives of thereceiving groups to ensure thatthe work products meet theirneeds.

Project Management: T2 P

AC6 Intergroup issues not resolvableby the individualrepresentatives of the projectengineering groups are handledaccording to a documentedprocedure.

Project Planning: T2.2, Project Organization PlanProject Management: T2Project Management: CEV1

P

AC7 Representatives of the projectengineering groups conductperiodic technical reviews andinterchanges.

Project Planning: T2.2, Project Organization PlanProject Management: T2Project Management: CEV2

P



ME1 Measurements are made andused to determine the status ofthe intergroup coordinationactivities.


P



VE1 The activities for intergroupcoordination are reviewedwith senior management on aperiodic basis.



VE2 The activities for intergroupcoordination are reviewedwith the project manager onboth a periodic and event-driven basis.


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for intergroupcoordination and reports theresults.

- - - C


4.3.7 Peer Reviews


Cleanroom is a team-based process involving ongoing peer review in every taskand of every work product. Peer review is essential to the Cleanroom objectiveof intellectual control of evolving products. Cleanroom provides technology andprocesses for mathematics-based correctness verification of softwarespecifications, designs, and implementations in team reviews.





GO1 Peer review activities areplanned.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule & Resource PlanIncrement Planning: T2, Increment Construction PlanCorrectness Verification

H

GO2 Defects in the software workproducts are identified andremoved.

Following processes, CEO2 and Verification sections:Requirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationSoftware ReengineeringIncrement DesignUsage Modeling & Test Planning

Correctness VerificationEngineering Change: T4

H



CO1 The project follows a writtenorganizational policy forperforming peer reviews.

Project Planning: T1, Cleanroom Engineering GuideCorrectness Verification

H




AB1 Adequate resources and fundingare provided for performingpeer reviews on each softwarework product to be reviewed.


H

AB2 Peer review leaders receiverequired training in how tolead peer reviews.


H

AB3 Reviewers who participate inpeer reviews receive requiredtraining in the objectives,principles, and methods of peerreviews.


H



AC1 Peer reviews are planned, andthe plans are documented.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule & Resource PlanIncrement Planning: T2, Increment Construction PlanCorrectness Verification

H

AC2 Peer reviews are performedaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering GuideFollowing processes, Verification sections:

Requirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationSoftware ReengineeringIncrement DesignUsage Modeling & Test Planning

Correctness Verification

H

AC3 Data on the conduct and resultsof the peer reviews arerecorded.

Following processes, Verification sections and ProjectRecord:


Correctness Verification: T2, Increment VerificationReport

H




ME1 Measurements are made andused to determine the status ofthe peer review activities.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordFollowing processes, Measurement and Verification sections:


Correctness Verification: Increment VerificationReportPerformance Improvement: T1

H



VE1 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for peer reviews andreports the results.



A



4.4.1 Quantitative Process Management


Cleanroom process management is based on incremental development understatistical process control, in particular, the measures produced by statisticaltesting and certification. Statistical process control is a defining characteristic ofCleanroom. As is the case in statistical process control in general, processperformance is measured and compared with performance targets, anddeviations are evaluated in the context of the range of historical deviations inperformance. In the absence of historical data, quantitative process decisionsmay be based on industry standards, expected values, customer requirements, orsome combination of these criteria.





GO1 The quantitative processmanagement activities areplanned.

Project Planning: T2.5, Measurement Plan H

GO2 The process performance of theproject’s defined softwareprocess is controlledquantitatively.

Project Management: O2Project Management: O3Project Management: T5Statistical Testing & Certification: T5Statistical Testing & Certification: T6Statistical Testing & Certification: T7

H

GO3 The process capability of theorganization’s standardsoftware process is known inquantitative terms.

Project Planning: T2.5, Measurement Plan H




CO1 The project follows a writtenorganizational policy formeasuring and quantitativelycontrolling the performance ofthe project’s defined softwareprocess.

Project Planning: T2.5, Measurement PlanProject Management: T5Statistical Testing & Certification

H

CO2 The organization follows awritten policy for analyzingthe process capability of theorganization’s standardsoftware process.

Project Planning: T2.5, Measurement PlanPerformance Improvement T1, PerformanceImprovement Plan

H



AB1 A group that is responsible forcoordinating the quantitativeprocess management activitiesfor the organization exists.


AB2 Adequate resources and fundingare provided for thequantitative processmanagement activities.


H

AB3 Support exists for collecting,recording, and analyzing datafor selected process and productmeasurements.

Project Planning: T2.5, Measurement PlanProject Planning: T2.4, Schedule and Resource Plan

H

AB4 The individuals implementingor supporting quantitativeprocess management receiverequired training to performthese activities.


H

AB5 The members of the softwareengineering group and othersoftware-related groupsreceive orientation on the goalsand value of quantitativeprocess management.


H




AC1 The software project’s plan forquantitative processmanagement is developedaccording to a documentedprocedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.5, Measurement Plan

H

AC2 The software project’squantitative processmanagement activities areperformed in accordance withthe project’s quantitativeprocess management plan.

Project Management: T4Project Management: T5Project Management: CEV1Performance Improvement: T1

H

AC3 The strategy for the datacollection and the quantitativeanalysis to be performed aredetermined based on theproject’s defined softwareprocess.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.5, Measurement Plan

H

AC4 The measurement data used tocontrol the project’s definedsoftware processquantitatively are collectedaccording to a documentedprocedure.

Project Management: T2.5, Measurement PlanProject Management: T5Usage Modeling & Test Planning: T5, Increment TestPlanStatistical Testing & Certification: StatisticalTesting Report, Increment Certification Report

H

AC5 The project’s defined softwareprocess is analyzed andbrought under quantitativecontrol according to adocumented procedure.

Project Management: T2.5, Measurement PlanProject Management: T5Project Management: T5Project Management: T7Statistical Testing & Certification: T6Performance Improvement: T1

H

AC6 Reports documenting theresults of the software project’squantitative processmanagement activities areprepared and distributed.

Statistical Testing & Certification: T6, IncrementCertification ReportPerformance Improvement: T1, PerformanceImprovement Plan

H

AC7 The process capabilitybaseline for the organization’sstandard software process isestablished and maintainedaccording to a documentedprocedure.





ME1 Measurements are made andused to determine the status ofthe activities for quantitativeprocess management.

Project Planning: T2.5, Measurement PlanProject Management: T5Project Management: CEM1, Project RecordProject Management: CEV1Statistical Testing & Certification: T5, IncrementCertification ReportStatistical Testing & Certification: T6Statistical Testing & Certification: T7Performance Improvement: T1

H



VE1 The activities for quantitativeprocess management arereviewed with seniormanagement on a periodicbasis.

Project Management: CEV1Performance Improvement: CEV1

H

VE2 The software project’sactivities for quantitativeprocess management arereviewed with the projectmanager on both a periodic andevent-driven basis.

Project Management: CEV1Performance Improvement: CEV1

H

VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for quantitativeprocess management andreports the results.



A


4.4.2 Software Quality Management


Development of high quality software products is a defining characteristic ofCleanroom. Extensive analysis of requirements, precise specification of functionand usage, rigorous design, correctness verification, and continual customerfeedback all contribute to software quality.

Objective measurement of software quality is a key Cleanroom activity. Softwareis certified to be fit for use if it exhibits specified characteristics in statisticalcertification testing. Certification goals may be specified by the customer, set bythe product team, or given as a combination of the two. Progress towardsoftware quality goals is assessed at regular intervals in increment testing andcertification.





GO1 The project’s software qualitymanagement activities areplanned.

Project Planning: T1, Cleanroom Engineering GuidePerformance Improvement: T1

H

GO2 Measurable goals for softwareproduct quality and theirpriorities are defined.

Project Planning: T2.5, Measurement PlanUsage Modeling & Test Planning: T5, Increment TestPlan

H

GO3 Actual progress towardachieving the quality goals forthe software products isquantified and managed.

Project Management: T5, Project RecordStatistical Testing & Certification: T5Statistical Testing & Certification: T6Statistical Testing & Certification: T7, IncrementCertification ReportPerformance Improvement T1

H




CO1 The project follows a writtenorganizational policy formanaging software quality.

Project Planning: T1, Cleanroom Engineering GuidePerformance Improvement: T1

H



AB1 Adequate resources and fundingare provided for managing thequality of the softwareproducts.


H

AB2 The individuals implementingand supporting softwarequality management receiverequired training to performtheir activities.


H

AB3 The members of the softwareengineering group and othersoftware-related groupsreceive required training insoftware quality management.


H



AC1 The project’s software qualityplan is developed andmaintained according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development PlanCorrectness VerificationUsage Modeling & Test Planning: T5, Increment TestPlanPerformance Improvement T1, PerformanceImprovement Plan

H

AC2 The project’s software qualityplan is the basis for theproject’s activities for softwarequality management.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development PlanProject Management: T4Project Management: T5Project Management: T7Performance Improvement T1, PerformanceImprovement PlanStatistical Testing & Certification

H


AC3 The project’s quantitativequality goals for the softwareproducts are defined,monitored, and revisedthroughout the software lifecycle.

Project Planning: T2.5, Measurement PlanProject Management: T5Usage Modeling & Test Planning: T5, Increment TestPlanStatistical Testing & Certification: T5, IncrementCertification ReportStatistical Testing & Certification: T6Performance Improvement T1, PerformanceImprovement Plan

H

AC4 The quality of the project’ssoftware products is measured,analyzed, and compared to theproject’s quantitative qualitygoals on an event-driven basis.

Project Management: T5Project Management: CEV2Project Management: CEM2Correctness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement T1, PerformanceImprovement Plan

H

AC5 The software project’squantitative quality goals forthe products are allocatedappropriately to thesubcontractors deliveringsoftware products to theproject.

Increment Planning: Increment Construction Plan C



ME1 Measurements are made andused to determine the status ofthe software qualitymanagement activities.

Project Management: T2.5, Measurement PlanProject Management: T5Project Management: CEM1, Project RecordProject Management: CEV1Correctness Verification: Increment VerificationReportStatistical Testing & Certification: T5, IncrementCertification ReportStatistical Testing & Certification: T6Statistical Testing & Certification: T7Performance Improvement: T1

H




VE1 The activities for softwarequality management arereviewed with seniormanagement on a periodicbasis.


VE2 The activities for softwarequality management arereviewed with the projectmanager on both a periodic andevent-driven basis.


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for software qualitymanagement and reports theresults.



A



4.5.1 Defect Prevention


Cleanroom is first and foremost about defect prevention. The Cleanroom namewas borrowed from the semiconductor industry, in which a physical Cleanroomexists to prevent the introduction of defects in chip fabrication. Defectprevention is intrinsic to the technologies embodied in the Cleanroom processes.Defects are prevented through mathematically-based engineering methods forspecification, design, and correctness verification, as well as through peer review,engineering change control, and continuous process improvement.





GO1 Defect prevention activitiesare planned.

Project Planning: T1, Cleanroom Engineering GuidePlanned development activities in the followingprocesses prevent defects through mathematically-based engineering methods:

Requirements AnalysisFunction SpecificationUsage SpecificationArchitecture SpecificationSoftware ReengineeringIncrement DesignCorrectness VerificationUsage Modeling & Test Planning


H


GO2 Common causes of defects aresought out and identified.

Performance Improvement T1, PerformanceImprovement PlanCorrectness Verification: T2, Increment VerificationReportStatistical Testing & Certification: T4, StatisticalTesting Report

H

GO3 Common causes of defects areprioritized and systematicallyeliminated.

Performance Improvement T1, PerformanceImprovement Plan

H



CO1 The organization follows awritten policy for defectprevention activities.


CO2 The project follows a writtenorganizational policy fordefect prevention activities.




AB1 An organization-level team tocoordinate defect preventionactivities exists.

- - - C

AB2 A team to coordinate defectprevention activities for thesoftware project exists.


AB3 Adequate resources and fundingare provided for defectprevention activities at theproject and organization levels.


P

AB4 Members of the softwareengineering group and othersoftware-related groupsreceive required training toperform their defectprevention activities.


H




AC1 The software project developsand maintains a plan for itsdefect prevention activities.

Project Planning: T1, Cleanroom Engineering Guide H

AC2 At the beginning of a softwaretask, the members of the teamperforming the task meet toprepare for the activities ofthat task and the relateddefect prevention activities.

- - - C

AC3 Causal analysis meetings areconducted according to adocumented procedure.


H

AC4 Each of the teams assigned tocoordinate defect preventionactivities meets on a periodicbasis to review and coordinateimplementation of actionproposals from the causalanalysis meetings.

Performance Improvement: T1, PerformanceImprovement PlanEngineering Change: T1Engineering Change: T2

H

AC5 Defect prevention data aredocumented and tracked acrossthe teams coordinating defectprevention activities.

Project Management: T5, Project RecordPerformance Improvement: T1, PerformanceImprovement PlanCorrectness Verification: T2, Increment VerificationReportStatistical Testing & Certification: T4, StatisticalTesting Report

H

AC6 Revisions to the organization’sstandard software processresulting from defectprevention actions areincorporated according to adocumented procedure.

Cleanroom Engineering Guide for the organizationPerformance Improvement: T1

P

AC7 Revisions to the project’sdefined software processresulting from defectprevention actions areincorporated according to adocumented procedure.

Project Planning: T1, Cleanroom Engineering GuideProject Management: T7Performance Improvement: T1, PerformanceImprovement Plan

H


AC8 Members of the softwareengineering group andsoftware-related groupsreceive feedback on the statusand results of theorganization’s and project’sdefect prevention activities ona periodic basis.

Project Management: T7Performance Improvement: T1Performance Improvement: CEV1, PerformanceImprovement PlanPerformance Improvement: CEV2

P



ME1 Measurements are made andused to determine the status ofthe defect preventionactivities.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordFollowing processes, Measurement and Verification sections:


Correctness Verification: Increment VerificationReportStatistical Testing and Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement: T1, PerformanceImprovement Plan

H



VE1 The organization’s activitiesfor defect prevention arereviewed with seniormanagement on a periodicbasis.

- - - C

VE2 The software project’sactivities for defect preventionare reviewed with the projectmanager on both a periodic andevent-driven basis.

Project Management: CEV1Performance Improvement: CEV1, PerformanceImprovement Plan

H


VE3 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for defect preventionand reports the results.



A


4.5.2 Technology Change Management


The Cleanroom processes generally focus on the software project level, and donot define management activities at the organizational level. If Cleanroom isinstantiated at the project level only, therefore, the overall correspondence withthe Technology Change Management KPA is Partial. If Cleanroom is thestandard organizational process, however, the correspondence could be High.

New software technologies are identified, and pilot applications are conducted toevaluate their potential effectiveness. The Cleanroom incrementaldevelopment life cycle provides for planned and controlled technologyintroduction. Project data are reviewed and analyzed at the completion of eachincrement to identify technology improvement opportunities, and appropriatetechnology changes are implemented in the development of succeedingincrements.





GO1 Incorporation of technologychanges is planned.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2.4, Schedule & Resource PlanProject Management: T7Increment Planning: T2, Increment Construction PlanPerformance Improvement: T2, Performance Improvement Plan

P

GO2 New technologies areevaluated to determine theireffect on quality andproductivity.


P

GO3 Appropriate new technologiesare transferred into normalpractice across theorganization.

Cleanroom Engineering Guide for the organizationPerformance Improvement: T2, PerformanceImprovement Plan

C




CO1 The organization follows awritten policy for improvingits technology capability.

Cleanroom Engineering Guide for the organizationPerformance Improvement

C

CO2 Senior management sponsorsthe organization’s activitiesfor technology changemanagement.

-- - C

CO3 Senior management overseesthe organization’s technologychange management activities.

- - - C



AB1 A group responsible for theorganization’s technologychange management activitiesexists.

- - - C

AB2 Adequate resources and fundingare provided to establish andstaff a group responsible forthe organization’s technologychange management activities.

- - - C

AB3 Support exists for collectingand analyzing data needed toevaluate technology changes.

Project Planning: T1.2, Cleanroom Engineering GuideProject Planning: T2.5, Measurement PlanProject Management: T4

C

AB4 Appropriate data on thesoftware processes andsoftware work products areavailable to support analysesperformed to evaluate andselect technology changes.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordCorrectness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement: Performance ImprovementPlan

H


AB5 Members of the groupresponsible for theorganization’s technologychange management activitiesreceive required training toperform these activities.

- - - C



AC1 The organization develops andmaintains a plan fortechnology changemanagement.


AC2 The group responsible for theorganization’s technologychange management activitiesworks with the softwareprojects in identifying areas oftechnology change.

Performance Improvement: T2 P

AC3 Software managers andtechnical staff are keptinformed of new technologies.

Performance Improvement: Performance ImprovementPlan

P

AC4 The group responsible for theorganization’s technologychange managementsystematically analyzes theorganization’s standardsoftware process to identifyareas that need or could benefitfrom new technology.


AC5 Technologies are selected andacquired for the organizationand software projects accordingto a documented procedure.


P

AC6 Pilot efforts for improvingtechnology are conducted,where appropriate, before anew technology is introducedinto normal practice.

Performance Improvement: T2Project Management: T7

P


AC7 Appropriate new technologiesare incorporated into theorganization’s standardsoftware process according to adocumented procedure.


C

AC8 Appropriate new technologiesare incorporated into theproject’s defined softwareprocess according to adocumented procedure.


H



ME1 Measurements are made andused to determine the status ofthe organization’s activitiesfor technology changemanagement.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordPerformance Improvement: Performance ImprovementPlan

C



VE1 The organization’s activitiesfor technology changemanagement are reviewedwith senior management on aperiodic basis.

- - - C

VE2 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for technology changemanagement and reports theresults.

- - - C


4.5.3 Process Change Management


The Cleanroom processes generally focus on the software project level, and donot define management activities at the organizational level. If Cleanroom isinstantiated at the project level only, therefore, the overall correspondence withthe Process Change Management KPA is Partial. If Cleanroom is the standardorganizational process, however, the correspondence could be High.

Continuous process improvement is an explicit Cleanroom objective. TheCleanroom incremental development life cycle includes planned periods forprocess review. Project data are analyzed at the completion of each increment forthe purpose of identifying process improvement opportunities, and processchanges are implemented in the development of succeeding increments.





GO1 Continuous processimprovement is planned.

Project Planning: T1, Cleanroom Engineering GuideProject Planning: T2, Software Development PlanProject Management: T7Performance Improvement: Performance ImprovementPlan

H

GO2 Participation in theorganization’s software processimprovement activities isorganization-wide.

- - - C

GO3 The organization’s standardsoftware process and theproject’s defined softwareprocess are improvedcontinuously.

Cleanroom Engineering Guide for the organizationProject Planning: T1, Cleanroom Engineering GuidePerformance Improvement

P




CO1 The organization follows awritten policy forimplementing software processimprovements.


CO2 Senior management sponsorsthe organization’s activitiesfor software processimprovement.

-- - C



AC1 A software processimprovement program isestablished which empowersthe members of theorganization to improve theprocesses of the organization.


AC2 The group responsible for theorganization’s software processactivities (e.g., softwareengineering process group)coordinates the softwareprocess improvementactivities.

- - - C

AC3 The organization develops andmaintains a plan for softwareprocess improvement accordingto a documented procedure.

Cleanroom Engineering Guide for the organizationPerformance Improvement: Performance ImprovementPlan

C

AC4 The software processimprovement activities areperformed in accordance withthe software processimprovement plan.

Project Management: T7Performance Improvement: T1, PerformanceImprovement PlanPerformance Improvement: CEV1

P

AC5 Software process improvementproposals are handledaccording to a documentedprocedure.

Performance Improvement P


AC6 Members of the organizationactively participate in teamsto develop software processimprovements for assignedprocess areas.

-- - C

AC7 Where appropriate, thesoftware process improvementsare installed on a pilot basis todetermine their benefits andeffectiveness before they areintroduced into normalpractice.


P

AC8 When the decision is made totransfer a software processimprovement into normalpractice, the improvement isimplemented according to adocumented procedure.

Project Management: T7Performance Improvement: T1, PerformanceImprovement Plan

P

AC9 Records of software processimprovement activities aremaintained.


P

AC10

Software managers andtechnical staff receivefeedback on the status andresults of the software processimprovement activities on anevent-driven basis.

Performance Improvement: CEV1 P



ME1 Measurements are made andused to determine the status ofthe software processimprovement activities.

Project Planning: T2.5, Measurement PlanProject Management: T5, Project RecordProject Management: T7Correctness Verification: Increment VerificationReportStatistical Testing & Certification: StatisticalTesting Report, Increment Certification ReportPerformance Improvement: T1, PerformanceImprovement PlanPerformance Improvement: Measurement sectionPerformance Improvement: CEV1

H




VE1 The activities for softwareprocess improvement arereviewed with seniormanagement on a periodicbasis.

Performance Improvement: CEV1 H

VE2 The software quality assurancegroup reviews and/or auditsthe activities and workproducts for software processimprovement and reports theresults.

- - - C



References [CMU 95] Carnegie Mellon University, Software Engineering Institute.

The Capability Maturity Model: Guidelines for Improving theSoftware Process. Reading, Ma.: Addison-Wesley PublishingCompany, 1995.

[Hausler 94] Hausler, P.A.; Linger R.C.; & Trammell, C.J. Ch. 1, "AdoptingCleanroom Software Engineering with a Phased Approach.”Cleanroom Software Engineering: A Reader. Oxford,England: Blackwell Publishers, 1996.

[Linger 79] Linger, R.C.; Mills, H.D.; & Witt, B.I. StructuredProgramming: Theory and Practice. Reading, Ma.: Addison-Wesley, 1979.

[Linger 93] Linger, R.C. "Cleanroom Software Engineering for Zero-Defect Software." Proceedings of the 15th InternationalConference on Software Engineering. Baltimore, Md., May17-21, 1993. Los Alamitos, Ca.: IEEE Computer Society Press,1993.

[Linger 94] Linger, R.C. "Cleanroom Process Model." Ch. 6, CleanroomSoftware Engineering: A Reader. Oxford, England: BlackwellPublishers, 1996.

[Linger 96] Linger, R.C. & Trammell, C.J. Cleanroom SoftwareEngineering Reference Model. (CMU/SEI-96-TR-022).Pittsburgh, Pa.: Software Engineering Institute, CarnegieMellon University, 1996.

[Mills 86] Mills, H.D.; Linger, R.C.; & Hevner, A.R. Principles ofInformation Systems Analysis and Design. New York:Academic Press, 1986.

[Mills 87] Mills, H.D. "Cleanroom: An Alternative SoftwareDevelopment Process." Ch. 3, Cleanroom SoftwareEngineering: A Reader. Oxford, England: BlackwellPublishers, 1996.


[Mills 92] Mills, H.D. "Certifying the Correctness of Software."Proceedings of 25th Hawaii International Conference onSystem Sciences. Kauai, Hawaii, January 7-10, 1992. LosAlamitos, Ca.: IEEE Computer Society Press, January 1992.

[Poore 95] Poore, J.H. "Usage Testing as Engineering Practice." Proceedings of the 2nd European Industrial Symposium onCleanroom Software Engineering. Berlin, Germany, March1995. Lund, Sweden: Q-Labs, 1995.

[Poore 96] Poore, J.H. & Trammell, C.J. Cleanroom SoftwareEngineering: A Reader. Oxford, England: BlackwellPublishers, 1996.

[Sherer 96] Sherer, S.W.; Kouchakdjian, A.; & Arnold, P.G. “ExperienceUsing Cleanroom Software Engineering.” IEEE Software 13, 3(May, 1996).

[Trammell 95] Trammell, C.J. "Quantifying the Reliability of Software:Statistical Testing Based on a Usage Model." Proceedings ofthe Second IEEE International Symposium on SoftwareEngineering Standards, Montreal, Quebec, Canada, August1995. Los Alamitos, Ca.: IEEE Computer Society Press, 1995.

[Walton 95] Walton, G.H.; Poore, J.H.; & Trammell, C.J. Ch. 15,"Statistical Testing Based on a Software Usage Model."Cleanroom Software Engineering: A Reader. Oxford,England: Blackwell Publishers, 1996.

UNLIMITED, UNCLASSIFIEDSECURITY CLASSIFICATION OF THIS PAGE

REPORT DOCUMENTATION PAGE1a. REPORT SECURITY CLASSIFICATION

Unclassified1b. RESTRICTIVE MARKINGS

None2a. SECURITY CLASSIFICATION AUTHORITY

N/A3. DISTRIBUTION/AVAILABILITY OF REPORT

Approved for Public ReleaseDistribution Unlimited

2b. DECLASSIFICATION/DOWNGRADING SCHEDULE

N/A4. PERFORMING ORGANIZATION REPORT NUMBER(S)

CMU/SEI-96-TR-0235. MONITORING ORGANIZATION REPORT NUMBER(S)

ESC-TR-96-023

6a. NAME OF PERFORMINGORGANIZATION

Software Engineering Institute

6b. OFFICE SYMBOL(if applicable)

SEI

7a. NAME OF MONITORING ORGANIZATION

SEI Joint Program Office

6c. ADDRESS (city, state, and zip code)

Carnegie Mellon UniversityPittsburgh PA 15213

7b. ADDRESS (city, state, and zip code)

HQ ESC/AXS5 Eglin StreetHanscom AFB, MA 01731-2116

8a. NAME OF FUNDING/SPONSORING ORGANIZATION

SEI Joint Program Office

8b. OFFICE SYMBOL(if applicable)

ESC/AXS

9. PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER

F19628-95-C-0003

8c. ADDRESS (city, state, and zip code) 10. SOURCE OF FUNDING NOS.

Carnegie Mellon UniversityPittsburgh PA 15213

PROGRAMELEMENT NO

63756E

PROJECTNO.

N/A

TASKNO

N/A

WORK UNITNO.

N/A

11. TITLE (Include Security Classification)

Cleanroom Software Engineering Reference Model12. PERSONAL AUTHOR(S)

Richard C. Linger, Mark C. Paulk, Carmen J. Trammell13a. TYPE OF REPORT

Final13b. TIME COVERED

FROM TO 14. DATE OF REPORT (year, month, day)

December 199615. PAGE COUNT

92 pp.16. SUPPLEMENTARY NOTATION

17. COSATI CODES 18. SUBJECT TERMS (continue on reverse of necessary and identify by block number)

FIELD GROUP SUB. GR. capability maturity model, cleanroom software engineering,

correctness verification, reliability certification, software

architecture, software reeengineering, software specification,

statistical quality control, statistical testing, usage models

19. ABSTRACT (continue on reverse if necessary and identify by block number)

Cleanroom software engineering is a theory-based engineering process for development and certification of high-reliability software systems under statistical quality control. Cleanroom is intended to help software organizationsimprove their ability to apply engineering discipline to software development. Cleanroom is defined in terms of 14processes that implement the technology and operations involved in Cleanroom software development.

This report defines the Cleanroom software engineering implementation of the Capability Maturity Model for Software. The definition is expressed in terms of a mapping of the 14 Cleanroom processes into the 18 CMM key process areas.20. DISTRIBUTION/AVAILABILITY OF ABSTRACT

UNCLASSIFIED/UNLIMITED ■ SAME AS RPT ❏ DTIC USERS ■

21. ABSTRACT SECURITY CLASSIFICATION

Unclassified, Unlimited Distribution22a. NAME OF RESPONSIBLE INDIVIDUAL

Thomas R. Miller, Lt Col, USAF22b. TELEPHONE NUMBER (incl. areacode)

(412) 268-7631

22c. OFFICE SYMBOL

ESC/AXS (SEI)

DD FORM 1473, 83 APR EDITION of 1 JAN 73 IS OBSOLETE UNLIMITED, UNCLASSIFIEDSECURITY CLASSIFICATION OF THIS PAGE

Documents

Technical Report CMU/SEI-96-TR-023 ESC-TR-96-023...Cleanroom Software Engineering, by Richard C. Linger and Carmen J. Trammell. The book will be published by the Addison-Wesley Publishing