ConfigVersionMgmt - CM ML Book

8/9/2019 ConfigVersionMgmt - CM ML Book

http://slidepdf.com/reader/full/configversionmgmt-cm-ml-book 1/28

LITTLE BOOK

OF

CONFIGURATION

MANAGEMENT

NOVEMBER 1998

For additional information please contact the

Software Program Managers Network

(703) 521-5231 • Fax (703) 521-2603

E-Mail: [email protected]://www.spmn.com

SOFTW ARE CO UN CIL

AIRLIE



i

THE AIRLIE SOFTWARE COUNCIL This guidebook is one in a series of guidebookspublished by the Software Program Managers Network (SPMN). Our purpose is to identify best management

and technical practices for software development andmaintenance from the commercial software sector and toconvey these practices to busy program managers andpractitioners. Our goal is to improve the bottom-linedrivers of software development and maintenance—cost,productivity, schedule, quality, predictability, and usersatisfaction.

The Airlie Software Council was convened by aDepartment of the Navy contractor in 1994 as a focusgroup of software industry gurus supporting the SPMNand its challenge of improving software across the manylarge-scale, software-intensive systems within the Army,Navy, Marine Corps, and Air Force. Council membershave identified principal best practices that are essential

to managing large-scale software development andmaintenance projects. The Council, which meetsquarterly in Airlie,Virginia, is comprised of some 20 of the nation’s leading software experts. These littleguidebooks are written, reviewed, generally approvedand, if needed, updated by Council members through theintermediary of the contractor. Your suggestionsregarding this guidebook, or others that you think should

exist, would be much appreciated.

This publication was prepared for the

Software Program Managers Network4600 North Fairfax Drive, Suite 302Arlington, VA 22203

The ideas and findings in this publication should not beconstrued as an official DoD position. It is published in the

interest of scientific and technical information exchange.

Norm BrownDirector, Software Program Managers Network

Copyright © 1998 by Computers & Concepts Associates

This work was created by Computers & Concepts Associates,a division of Integrated Computer Engineering, Inc., in theperformance of Federal Systems Integration andManagement Center (FEDSIM) Contract NumberGSOOT98AJD0047 for the operation of the Software

Program Managers Network (SPMN).



1

A project’s success is highly dependent on effectiveConfiguration Management (CM). CM becomes essentialas the size of the software increases. CM is necessary to

enable a large team to work together in a stableenvironment, yet still have the flexibility that’s needed todo creative work. All too often, CM is viewed only as acostly and time-consuming effort to be either ignored orthrown together at the last minute. However, not doingCM guarantees a project will be plagued by chaos, errors,permanent damage, low productivity, and unmanageablesoftware evolution.

CM can be defined as stabilizing the evolution of softwareproducts at key points and then controlling change. Theproject that implements good CM can reap enormousbenefits. CM can actually enhance productivity bysubstantially reducing the largest consumer of labor—rework. CM enables visibility into the status of fixingproblems and implementing changes. That’s all essentialinformation for better forecasting those ever slipperyrelease dates.

There are numerous industry and military standards (i.e.,MIL-STD-973 or MIL-STD-2549) that can be referenced asguides for establishing an effective and efficient CMprocess. These standards should be examined and tailoredto the project’s specific requirements. Instituting CM bestpractices is essential to the successful development and

maintenance of a software product. The principles andguidelines described in this guidebook will assist you indeveloping a solid Configuration Management program.

1

THE PURPOSE OF

THIS LITTLE BOOK

Norm Brown

Executive Director



3

3

THE CM PROCESS

The fundamental purpose of Configuration Management(CM) is to establish and maintain the integrity and controlof software products throughout a p roject’s life cycle.This includes products such as performance requirements,

functional and physical attributes, and design andoperation information. CM is a discipline applying bothtechnical and administrative direction for the control of change and integrity of the product data anddocumentation. CM involves identifying the configurationof the software (i.e., software work products) at givenpoints in time, systematically controlling changes to theconfiguration, and maintaining the integrity and

traceability of the configuration throughout the project’slife cycle.

The Software Configuration Management process iscomprised of the following integrated activities:

• Configuration identification of artifacts/work productsused or developed by a project

• Configuration change control of information, including

the impact of changes to organizations, managementpractices, schedules, budgets, technical or assuranceactivities, testing or retest requirements, orproject status

• Status accounting of artifacts/work products used in thedevelopment, release, and maintenance of a project

• Configuration reviews and audits that assess the status

and acceptability of products controlled or releasedby CM

INTRODUCTION

Configuration Management is the means by which thecontent, change, or status of shared information withina project is managed and controlled. A project’s successis highly dependent on good CM, and the way CM is

performed can make or break a project. By followingthe straightforward guidelines and disciplines in thisbook, establishing good CM processes and proceduresearly in your project, and getting buy-in from allaffected parties, you will put your project firmly on theroad to success.

Michael W. Evans

President, Integrated Computer Engineering, Inc.

Jeannine Gathmann-Hobbs

Manager, Configuration Management

Lockheed Martin Corporation



5

5

• Project delivery and release management procedures,and the capability to monitor the status of projectinformation

• Establishment of a Software Development Library

(SDL) and maintaining the integrity of the work products placed under CM control to ensurerepeatability of the products and baselines

Configuration Management is the basic project controlmechanism that establishes and maintains the integrityof software products through the project’s life cycle.CM provides:

• Configuration Identification—The ability toidentify what information has been approved forconcurrent use in the project, who owns theinformation, how the information was approved forCM control, and the latest approved release.

• Configuration Control —The configuration controlprocess and procedures designating the level of control through which each work product must pass(for example, author control, project-level control,acquirer control); identifying the persons or groupswith authority to authorize changes and to makechanges at each level (for example, theprogrammer/analyst, the software lead, the projectmanager, the acquirer);and the steps to be followedto obtain required authorization for changes, toprocess change requests, to track changes, todistribute changes, and to maintain past versions.Change control provides the mechanism to buildsoftware systems for tests that have a knownconfiguration and can be exactly reproduced.

• Status Accounting—Formalized recording andreporting of the established configurationdocuments, the status of proposed changes, and the

status of the implementation of approved changes.Status record information provides an accessible and

CM BASICSTHE CM PROCESS

(cont.)

Major Elements ofConfiguration

Management

ConfigurationAudits

ConfigurationChangeControl

ConfigurationItem

Identification

StatusAccounting

Change

Criteria

Specification,Design, Drawing,

Test Docum entation,and Data Revisions

Change ControlProcedures, includingVerification of Change

Implementation

Change Controland Review

Organizations

ProductConfiguration

Identifiers(names and numbers)

Identification of Product

AcceptanceRequirements

Identificationof Changes

to Data Items

Specificationsand Drawings

Data ReleaseIdentificationRequirements

FunctionalConfiguration

AuditsPhysicalConfiguration

Audits

FormalQualification

Reviews

ProductDescription

Records

ChangeStatus

Records

ConfigurationVer ification

Records

Files of Change Authorizations

and App rovals

Baselines

Figure 1. Major Elements of Configuration Management



77

CM is essential to program and software project successfor the following reasons:

1. CM is the means by which shared information (whetherit is produced, used by, or released from a software

development or support activity) is controlled andmaintained.

2. CM methods provide a means to identify, track, andcontrol system development from the inception of theconcept for the system until it is replaced or retired.

3. Management of baselines and engineering productsthrough CM provides a sustained control of the

information as the engineering functions work theirway through the process.

4. CM provides visibility into project control changeindicators, including CM churn per month, requirementschange per month, and number of defects that are openand closed.

Application of CM to a project environment provides thediscipline needed to ensure that the system operationalconcept is consistent with the capability that results.

CM also provides constant control over changes tomanaged information. An engineer made the comment:

“Why is this neces sa ry ? After a ll, as a n engineer, ar en’t I mos t qua lified to know how to fix a problem? I’ve got sched ules and technical obligatio ns to meet. I do not have the time to deal

w ith this bureaucra tic delay . I’ve got imp or tant

current record of the status of each controlled p ieceof information that is planned to be used, the contentof each release from CM, and who has checked outor is working on a piece of information that the test

organization plans on accessingthrough CM.

• Reviews and Audits—Frequent evaluation of thecontent, baseline integrity, and release integrity of allcontrolled products to ensure they conform to theirconfiguration documents.

Information to be controlled includes software and itsassociated documentation; interface requirements anddocumentation; engineering artifacts resulting from themethods and tools used by the project; trade studiesand user requirements, needs, and expectations;management plans; information and reports;projecttools and users’manuals;project records and history;test plans, procedures, cases, scenarios, and data;andtest tools (anything concurrently used across projectorganizations or approved for sharing).

WHY CM

IS ESSENTIAL

CM BASICS

(cont.)



99

w or k to do. The change is just five lines of cod e that I can pa tch. If I just change this interface slightly, the p rogr am w ill run tw ice as fa st.”

This represents the frustration of dedicated engineers

forced to slow down because of a requirement to haveproposed changes approved before they may beimplemented. However, this discipline is essential if theintegrity of the project environment is to be retained.The individual engineer cannot know the impact ontesting, documentation, or agreed-to user and supportinterfaces that may be experienced if that change isapplied to an operational configuration. The software

engineer cannot anticipate the system impacts of justslightly changing an interface or the operationalimplications of a system failure caused by a patch thatis incomplete or which has not followed establishedquality assurance p rocedures. Although appearing to bea burden, change control is the key discipline that tiesthe project together as information is modified toreflect project realities. This can be summarized as:

The Fundamental Law of Configuration Management

Configuration Management is the foundation of a softwareproject. Without it, no matter how talented the staff, howlarge the budget,how robust the development and testprocesses,or how technically superior the developmenttools, project discipline will collapse and success will beleft to chance. Do Configuration Management right, or

forget about improving your development process.

CM applies technical and administrative direction andsurveillance to:

• Identify and document the functional and physicalcharacteristics of a system, software, hardware, or

operational component so that these relationshipsmay be managed, maintained, controlled, and assured

• Control changes to those characteristics

• Record and report the status of proposed changes,and the status of the implementation of approvedchanges

• Disseminate baseline information to the project

personnel, and establish and maintain a statusaccounting and reporting system that records thebaseline, authorized changes to the baseline, andverification of changes incorporated into thedocumentation and/or product

• Review and audit the CM process to assure theprocess and the adequacy of control

• Establish a specific hierarchy of information for bothnondeliverables and deliverables

• Establish CM metrics, and trend and alert indicatorsto support quality evolution of the software product

PRIMARY CM ACTIVITIESWHY CM IS

ESSENTIAL (cont.)



11

configuration identifiers associated with eachartifact/work product

• Status of proposed engineering changes frominitiation to implementation

• Traceability of changes for baselineddocumentation for each CI

• Effectivity and installation status of configuration changes to all CIs at all locations

• Defect identification and reporting from theCM problem reporting/corrective actionsystem

• Methods of access to information inconfiguration status accounting systems andfrequency of reporting and distribution,including real-time, on-line access by all teammembers

6. Provide a framework for assessing the integrity of the development process and sharing

information, and establish a means to integrate,qualify, and accept diverse components of asystem.

7. Provide discrete points at which the schedule,budget, and quality of development may beevaluated. These are key items integral to theProject Control Panel.

8. Establish and implement configuration controlprocedures, designating: the level of control each

Setting up CM requires an orderly planned sequence of activities and tasks. The following are key elements toestablishing a successful CM program:

1. Plan and document the software CM

requirements, activities, and responsibilities.2. Establish a generic software development process

and identify points at which quality gates willassess product integrity. Provide uniform formatand content of engineering information,documentation, and review requirements.

3. Survey and select tools that can, without major

modification, support the needs of the softwareprocess.

4. Establish the configuration identification schemeto be used for all software work products placedunder configuration control. Configurationidentification activities include the determinationof the product structure, selection of Configuration Items (CIs), documenting the CIs,

and allocating identification characters ornumbers to the CIs and their documents.

5. Document and implement a method forcollecting, recording, processing, and maintainingdata necessary to provide configuration statusaccounting information. The process orprocedure should include:

• Identification of current approvedconfiguration documentation and

11

SETTING UP CM



1313

work product must pass through;those withauthority to authorize or make changes at eachlevel;and the steps to be followed to obtainauthorization for changes, to process changerequests, to track changes, to distribute changes,and to maintain past versions. Change controlactivities should be documented and be used to:

• Establish a Software Development Library(SDL) and change control process to establishbaselines and to maintain the integrity andtraceability of the configuration.

• Manage program baselines and ensure proper

authorization of changes to those itemsselected for both internal and formal releasefrom the SDL.

• Release and submit configurationdocumentation in relation to program events(i.e., technical reviews and design reviews).

• Establish internal development configuration

and contractual baselines.• Establish implementation and timing of

internal and customer configuration control.

• Define the roles and responsibilities of theconfiguration control boards.

• Establish a problem reporting/change controlprocess that is closed-looped to ensure that all

detected problems are reported and enteredinto the system, action is initiated on them,

resolution is achieved, status is tracked, andrecords of the problems are maintained for thelife of the project.

• Establish a Change Control Board/Engineering

Review Board with the authority for managingthe project’s software baselines. Products fromthe SDL are created, and their release iscontrolled through the CCB/ERB according to adocumented procedure.

• Document the procedure/process, includingroles and responsibilities, to be followed torequest authorization for changes, processchange requests, track changes, distributechanges, and maintain past versions. Changesthat affect an entity already under configurationcontrol will be proposed to the affectedorganizations (i.e., customer/subcontractor) inaccordance with contractually establishedforms and procedures, as app licable.

9. Establish and document the configurationidentification scheme to be usedfor all artifacts/work products placed underconfiguration control. The identification schemeshould include the following types of items toidentify artifacts/work products:

• Both developmental and formal configurationbaselines, including documents, SDLs, and

corrective action process. The identification

SETTING UP CM

(cont.)



1515

scheme will be at the level at which entitiessuch as computer files, electronic media,documents, software units,Configuration Items(CIs) will actually be controlled.

• Configuration identification activities, includingdetermining the product structure, selectingCIs, documenting the CIs, and allocatingidentification characters or numbers to the CIsand their documents. The selection of work products placed under CM includes thesoftware products that are delivered to thecustomer (for example, the code/build scripts,

software requirements, software design, andsoftware test procedures and documents) andthe items that are identified with or required tocreate these software products (for example,the compiler, vendor-supplied/government-furnished information, and so on).

• Configuration identifiers, including documentnumbers and software identifiers for bothsoftware and firmware. The identificationscheme should include the version/revision/ release status of each entity.

10. Through configuration auditing, establish anddocument the plans and procedures forperiodically auditing and evaluating the softwareproducts. In addition to specific auditrequirements, a configuration evaluation/auditshould be conducted to determine:

• If the quality of the product meets bothfunctional and physical requirements

• If the work products are stored in a controlledlibrary corresponding to the CM records

• If the work products and baseline CIs are

complete and available with respect to thestatus of the work products and app rovedmodifications from which they are built

11. Establish and implement procedures for thepackaging, storage,handling, backup,restore/ recovery, and delivery of deliverablesoftware products.

12. Establish sound subcontractor monitoring andauditing. Identification and re-creatability of artifacts or work products are required prior toacceptance from subcontractors.

SETTING UP CM

(cont.)



1717

In many instances, catastrophic engineering problemsoccur because of inadequate information managementand control—the problem solved by CM. The CMdisciplines are prime risk reducers in a projectenvironment. CM is vital to the success of any softwareeffort.

BEST PRACTICE #1

Best Practice #1: Make Configuration ManagementEveryone’s Job

From the inception of the p ro ject, create a nenvironment w here a dherence to the established

CM pr ocess is the o nly a cceptable w ay of do ing business.

Software engineering applications must be developedand maintained in an environment that enablescommunication and ensures a smooth, controlled flowof information and insight to development changes thataffect the product. Many different organizations, oftendistributed across rooms, buildings, sites, or evencontinents, must work together to satisfy a requirementwithin a predetermined cost and schedule.Experimentation, rework due to poor control of information, and uncontrolled change cannot beallowed if the project is to succeed.

Symptoms of inadequate CM are not always obvious;they are often difficult to address and easy to

misdiagnose. Problems such as nontraceability, inabilityto re-create a software product, interfaces andoperational requirements that are poorly satisfied, orcomponents that will not integrate because of interfaceinconsistencies are often blamed on technical ratherthan information management problems.



Best Practice #2: Create an Environment andEngineering Process That Enables ConfigurationManagement

Make every a sp ect of your d evelop ment p rocess

help your p eop le a dhere to the CM discip line. Define the engineering/ CM pro cess first, and refine the pr ocess a s necessa ry thro ughout the p ro ject’s life cycle. Find those a rea s tha t caus e develop ers and tes ters d ifficulty in maintainingCM, and make changes.

In examining the software development environment,the task is not simply to find ways to make it easier forsoftware engineers to design and write code or testersto run tests. It is to apply the right controls at eachphase of the development, so that baseline control ismaintained and change control is airtight.

The CM planning structure should define an integratedCM environment. The software CM planning activitiesare h ierarchical; requirements branch downward from a

set of system development and control requirements.From these requirements, a software engineeringstructure is defined that satisfies the program goals andobjectives and is consistent with system programconstraints, limitations, and essential programrelationships.

1919

At the lowest level of the software engineeringplanning process, the requirements for software CMand specific procedures for managing and controllingthe process are documented. The CM planning andprocess should be defined during the first stages of a

proposal effort. This relationship is critical to thesuccess of the software project and the quality of theproducts that are produced. If software is produced ina program environment that is unclear, inconsistent, orineffective, the quality of the software will bequestionable despite the rigor of the softwaredevelopment and the effectiveness of the softwareengineering process.

BEST PRACTICE #2



2121

Best Practice #3: Define and Document theCM/Engineering Process, Then Select the Tool Set(Automation) to Support the Process.

CM and engineering must d efine the p ro cess,

then the tools must be selected to su pp ort it.The tool set, including the automated and manualcomponents, must produce the products needed forbaseline and change control, and auditing,withoutoff-line work. The engineering CM and organizationsmust use the output of the CM tool set and must notrequire re-entering or manipulating data to performrequired management activities. If the tool set

cannot supp ort this, the p roject will quickly becomeburied in data.

Best Practice #4: The CM Staffing Should Consist ofIndividuals with Technical Expertise to Support theDevelopment and Maintenance of the Product.

When staffing the CM area, be sure the

individua ls h ave the technical exp ertise to develop and imp lement sound p rocesses and procedures.

CM should be staffed with technically skilled individualswho can develop methodologies for control, re-creationand release of models, product build/compilestructures, subcontractor monitoring and managing,andauthoring of CM-related documentation (including, CM

Plan, Software Product Specifications, Software VersionDescription (SVD) information, and so on.)

Be cautious when evaluating the staffing required toadminister the CM system. While a mature systemdoesn’t require a large staff, the p roject should not cutCM staff simply because things appear to be going well.The CM process must be institutionalized, not just

written down. The tool set must be complete, in use,and no longer in need of constant maintenance. Severalmilestones—major deliveries to system integration,large test events, or audits—all become successful whensupported by a fully utilized and reliable CM process.

BEST PRACTICE #3 BEST PRACTICE #4



2323

Best Practice #5: The CM Plan and Procedures Needto Be Developed and Documented in the Same Way aSoftware Development Plan Is Created at the InitialStages of a Project.

CM planning begins during the initial sta ges of a project. Sta ffing, bud get, sched ule, p ro cess , and pr ocedures should be p lanned a nd included in the over all p ro ject’s s tra tegy.

The following are items to be included in a CM Plan:

• Introduct ion—Sets down the purpose, scope, andapplicability of the CM Plan to the overall project.

• Or ga niz a t io n—Describes the relationship andintegration of CM with all organizations on theproject (including, Quality, Engineering, Customer,Management, and so on.)

• Project Phases and Milestones—Describes theevolution of the project with regard to CM and theestablishment of both developmental and formalbaselines.

• Configuration Identification—Discusses theselection of artifacts or work products, configurationidentifiers, establishment of the project libraries, andnaming or numbering conventions.

• Interface Management—Describes the p roceduresfor identification of interface requirements,establishment of both internal and external interfaceagreement processes and procedures, and how theproject will participate in the interface controlworking groups.

• Status Accounting—Sets down how and whenstatus accounting information will be recorded andreleased for the project. Information contained instatus accounting includes the current release of work products and status of change.

• Configuration Audits—Describes the plans and

procedures for performing audits and verification of aproduct.

• Subcontractor Management—Describes theprocess and procedures to be used to ensure thesubcontractors’compliance with projectrequirements.

BEST PRACTICE #5



2525

RULE 1: CM must manage the ownership of information and bring work products under controlin a timely manner.

RULE 2: Early identification and change control of

artifacts and work products is integral to a project.RULE 3: The change management process must besimple, consistent with the culture and requirements of the project, and supported by the methods and tools of the project.

RULE 4: The actions, roles, and responsibilities of theEngineering Review Board (ERB) and the Change

Control Board (CCB) should be documented.RULE 5: Change control must be a primary focus of the program and must be integrated into the culture of the project.

RULE 6: All information that is placed under CMcontrol or promoted in the CM hierarchy must bepromoted based on successful completion of aquality gate.

RULE 7: All proposed changes to CM-controlledproducts should be properly classified.

RULE 8: All CM library structures or releases from theCM library must be recorded in a Software VersionDescription (SVD) document or comparable document.

RULE 9: It is essential that CM be continually aware of the exact status of products under control, therelationships between these products, problems, andopen issues, and who is using the products.

RULE 10: The worst way to establish a CM system is topurchase a tool set and then devise a process to fit thetools. Establish the CM process that fits your project andculture, then find a tool set that supports that process.

COROLLARY 1: Artifacts used for evaluating CMeffectiveness must be products of the system. If the CMtool set (manual, automated, or some combination of both) does not p roduce the records necessary to verify

CM integrity, the tool set is flawed.

COROLLARY 2: Only the most trivial development cansurvive without automated tools.

COROLLARY 3: A mature, stable CM system (process,procedures, and supporting tool set) does not require anarmy to administer it. A few good staff members shouldbe able to run any development.

CM RULES



2727

RULE 1

RULE 1: CM Must Manage the Owners hip of Infor ma tion and Bring Wor k Pro ducts underControl in a Timely Manner.

One critical aspect for control of work products is the

proper timing for when they enter into CM. The timingfor entering into CM should be synchronized with theproject phases. The following table provides anexample of the types of project phases, including theinput, output, and resulting type of baseline.

SystemRequirementsReview

Updated System Specification

Preliminary performancebudget allocations

Final System Specifications

Traceability of systemrequirements

Performance/error budgets

FunctionalBaseline

System DesignReview (SDR)or PreliminaryDesign Review(PDR)

Software RequirementsSpecificatio ns (SRSs)

Interface RequirementSpecifications (IRSs)

SRSs/IRSs traceability

SRSs/IRSs update

Update of requirementstraceability to SRSs/IRSs andSoftware DevelopmentDescription budgets

Allocated Baseline

Critical DesignReview (CDR)

Detailed design

Detailed interface design

Test p rocedures

CI test plan

Detailed design updates

Updated interface definitions

Updated traceability

PreliminaryProduct Baseline

or Det ail DesignBaseline

Test ReadinessReview(TRR)/SiteAcceptanceTest

Establishment of configuration baseline, testdocumentation adequacy,compatibility withrequirements, demonstrationof performance in relation tosystem requirements

Detailed design approval tostart testing

Baselined software and testequipment

Traceability of tests torequirements

SystemPerformance TestBaselinet

ConfigurationAudit

Verification of all CIs againstsystem documentation

Configuration ControllerProduct Baseline

Product Baseline

REVIEW/AUDIT INPUT OUTPUT RESULTS/BASELINE

Figure 2. Milestone and Baseline Timing

For CM to work efficiently and effectively, clearresponsibility for information ownership must bedefined upon the level of maturity and timing of controlas defined in the project’s CM Plan. The assignment of this responsibility should be used to partition the controlof information. An example of how ownership is definedis shown in the figure below:

C M Work s p a c e

C h a n g e Au t h o r i z a t i o n ChangeControl

ControlledProject

Area

P r o b l e m C l o s u r e

Baselined Data

B a s e l i n e d D a t a

Baselined Data

Status AccountingERB/CCB–approved updates

EngineeringWorkspace

Problem Reports(from any and

all users)

TestWorkspace

Customer–ControlledWorkspace

Figure 3. Configuration Control Flow



29

RULE 1

(cont.)

Configuration Control of Information

• Engineering Workspace

- Holds all information that is under developmentor being changed, that has not been approved for

program use or release

- The information may be changed by theindividual responsible for the product as theapproving agent

- The content is controlled by the individualresponsible for the information

- Workspace is owned by the engineer doing thework

• CM Workspace

- Stages of documentation and software re-creating(compiling) and releases

- Holds tools and files used by the project, orneeded to build or control project information

and/or deliverables- Project plans, procedures, and reports

- Schedules, budgets, and CM records

- Audit trails, records, and lessons-learnedinformation essential for certification,approval, or acceptance

- Workspace is owned by CM, with read-only

privileges to all other organizations

• Controlled Project Area

- Holds all information or documentation that hasbeen accepted for release inside the program buthas not yet been accepted by the customer or

owner of the information at a higher-level life cyclefor inclusion in a baseline

- Includes information approved for internal releasethrough passing of a quality gate

- Requires that the program establish a process forCM of evolving information that is shared withinthe project by different organizations

- This information cannot be updated unless thechange is authorized by an established projectboard

- Project area is owned by CM, with read-onlyprivileges to all other organizations

• Test Area

- Holds all test documentation and versions of

software released for test from CM

- Test scenarios, data, and results

- Test configurations

- Test cases

- Software configurations under test andconfiguration documentation

- Special test data, records, and audit trails- Test area is owned by test manager



31

RULE 1

(cont.)RULE 2

• Customer-Controlled Workspace

- Holds all customer-approved baselined andapproved information

- Functional

- Allocated

- Product

- Records and reports

- Other approved or delivered information

- This area cannot be updated unless the change isauthorized by the customer

- Workspace is owned by the customer

RULE 2: Early Identification and Change Control of Artifacts and Wor k Pro ducts Is Integra l to a Project.

The project needs to fully identify and control changes

to all work products required to re-create and maintainthe software product. Work products encompass morethan just deliverables. All support tools, test drivers,Commercial Off-the-Shelf (COTS), and developmentenvironment items should be considered. The followingprovides a list of the types of artifacts and work products to consider:

• Plans

- Systems Engineering Management Plan

- Software Development Plan

- Software Standards and Procedures Manual

- Software Configuration Management Plan

• System Specification

• Software Requirements Specification- Graphical analysis modes

- Process specification

- Interface specification

- Prototype(s)

- Mathematical specification



33

RULE 2

(cont.)

• Design Specification

- Data design description

- Architectural design description

- Module design description- Interface design description

- Software design folder

- Objects description (object-oriented)

• Source Code

- Source code

- Build scripts- Source code listings

- Executable programs

- Module executable code

- Linked modules

- Legacy code (i.e., COTS, Government-Furnished

Information (GFI), Non-Development Item (NDI),and so forth)

• Operation and Installation Manuals

• Test Specification

- Test plan and procedure

- Test cases and recorded results

• Database Description

- Schema and file structure

- Initial content

• Software Description Document/Version DescriptionDocument

- Compile and build instructions

- Compiler(s) or network environment

• COTS products

- Compilers

- Computer-Aided Software Engineering (CASE)products

- Models

- Simulation software



RULE 3

35

RULE 3: The Change Management Process Must Be Simp le, Consis tent w ith th e Culture and Requireme nts of the Project, and Sup p or ted by the Method s a nd Too ls o f the Project.

• The p rocess starts with a program stakeholder,engineer, user, or any other individual identifying,documenting,and prioritizing a problem and thenassessing, if possible, the impact of the problem andthe recommended correction, cost, and scheduleimpact of the change, essential resources to correct,and the effects if not corrected.

• The CM process must be adapted to, and be

consistent with, the cultural aspects and realities of the project, or it will prove ineffective and will beresisted by the project staff.

• CM must be a centralized activity integrated into theengineering process, but it should remainindependent from both engineering and qualityassurance organizations.

• CM activities must be planned and tightly coupled tothe test schedule. The work products released fromCM become the lifeline for the testing of a softwareproduct.

• CM can never be bypassed for any reason, includingthe need to recover budget or schedule.

• Suspected and confirmed problems must be reported

through CM change control, and impacts must beassessed prior to authorizing a change.

• Every suspected or observed problem or programissue, no matter how small,must be processedthrough the problem reporting/corrective actionsystem.

• All trace information between projectdocumentation, deliverable documentation andengineering artifacts, and test cases and theinformation being tested must be CM-controlledinformation that has been approved through a qualitygate.

• The proposed Software Problem Report (SPR) isreviewed by the submitters’or proper Engineering

Review Board/Change Control Board (ERB/CCB) andis either sent back for revision or approved forrelease to the CM library. The CCB/ERB evaluateseach fix, assessing the process used to make it againstthe documented project process, program plans andconstraints, and assurance requirements andstandards;and then assesses whether the fix isconsistent with the standards for the product as

required by the customer.

• All formal test builds must be managed by, controlledby, and the responsibility of CM.

• All releases from CM must be accompanied by acurrent, complete, and accurate Software VersionDescription (SVD) document or comparabledocument.



37

• All product releases should be regression-tested pr ior todeployment or release to the customer.

• Engineering changes that do not follow the CM processcannot be used by, or shared within, the software project.

RULE 3

(cont.)

RULE 4: The Actions , Roles, and Res p ons ibilities of the Engineering Review Board ( ERB) and theCha nge Contro l Boa rd ( CCB) Should Be

Documented.

Actions that may result from the ERB/CCB are:• Reject —Reject the Software Problem Report (SPR).

• Ass ign for Study —Assign the SPR to the technicalorganization for analysis.

• Assign for Correction—Assign the SPR forcorrection, authorizing update.

• Append to Open SPR—Block the SPR with another

problem under analysis.

• Reanalysis—Send the SPR back for further analysis.

• Table—Defer analysis, but don’t redefine suspensedate.

• Defer—Defer analysis and assign suspense date.

• Identify Testing a nd Retest Requirements.

• Build System and Release—Authorize a softwarebuild and release.

• Close—Close the SPR. Problem is resolved.

RULE 4



39

ERB/ CCB RESPONSIBILITIES

General ERB/CCB Responsibilities

The primary functions of the ERB/CCB are to:

• Ensure that proposed changes to hardware, software,and documentation are systematically evaluated withrespect to their impact on other related programelements

• Review and approve/disapprove all proposedchanges to controlled hardware, software, anddocumentation

• Ensure that only necessary changes are approved• Ensure that only approved changes are implemented

• Ensure that proposed changes are properly classified

• Determine urgency for incorporating the changesand establish effectivity points

Chairperson’s Responsibilities

The chairperson is responsible for resolving disputesregarding proposed changes and for implementingthe ERB/CCB aspects of the CM Plan. As required,duties include:

• Requesting and evaluating an impact analysis

• Making a decision on changes

• Giving final approval on all changes within his/her

jurisdiction

• Keeping higher management advised of significantchanges in design, cost, and/or schedules

• Establishing criteria for the acceptability of proposedchanges

• Determining the needed reviewers of a change• Assigning action items, as required

ERB/CCB Reviewer Responsibilities

• Each reviewer of a change should obtain all theinformation needed to assess any impact of thechange.

• Each reviewer should be prepared to negotiate forthe component represented and have authority tocommit the organization to take action on changesbeing reviewed.

• Each reviewer should complete an impact analysisdetailing the impact to the organization he/she isrepresenting.

- This impact analysis should be performed withinthe review time allocated by the ERB/CCB.

RULE 4

(cont.)



41

RULE 5: Cha nge Contro l Mus t Be a Primary Focus of the Pro gra m a nd Must Be Integrated into theCulture of the Pr oject.

• The p roject has to ha ve a mechanism to

introduce change: Change is very often a function of time—the longer the duration of the p rogram, the morechange. There must be a controlled, disciplinedprocess for presenting changes to the programcommunity.

• Establish criteria by which to classify changes:Not all changes are equal, and there must be a methodto determine importance and priority to allocate

resources.

• Consistency across pr od ucts: The impact of achange must be assessed by all disciplines within aprogram. All products must be appropriately modifiedto reflect the change.

• Timely a nd comp rehensive vis ibility of cha nge status: Timely and comprehensive visibility of all

changes is needed through the ERB or CCB.• A histo rica l record of a ll cha nges: This record, or

audit trail, should be consistent with the tracking,reporting, and cert ification requirements of theprogram.

• Changes must be a djudicated before they a re made: The project should have a process to evaluate

project input and a forum through which to adjudicatethe implementation of a change before it is made.

RULE 6: All Infor ma tion Tha t Is Placed unde r CM Control or Prom oted in the CM Hiera rchy Must

Be Pr omo ted Bas ed on Successful Comp letion of a Quality Gate.

• All products controlled by the program must be builtin accordance with established project standards andstandards of workmanship unique to the productrequirements, essential characteristics, andoperational needs.

• Quality gates used to approve information forincreasing levels of CM control must be structuredinspections,walkthroughs, successful completion of

planned testing activities, project reviews, orindependent p roduct analyses based on thecharacteristics, contractual status, use, and risk associated with the product.

• For each quality gate conducted, a threshold belowwhich the specific product w ill not be app rovedmust be defined. These thresholds serve as quality

targets, by product, that must be met by the product.• Product standards must identify what the

documentation, engineering products, and hardwareand software products look like, what they shouldcontain, and how they should be structured, tiedtogether, and packaged for release.

• Engineering Review Boards and Change ControlBoards play a critical role in technical andmanagement reviews of proposed changes and in

RULE 5 RULE 6



43

the implementation of changes. It is essential thatthese boards continually ensure that what is undercontrol is actually what was placed under CM andapproved through a quality gate.

• CM must monitor library content, assessing release

level, content, applied changes, and the approval levelof controlled information.

• CM must ensure that all products approved forcontrol have required approvals and that qualityassurance has confirmed the products meet requiredstandards.

• CM must ensure that change requests are processed

correctly before a change to a controlled libraryis made.

• CM must audit sites that have received a release toensure that the approved and released configurationis used.

RULE 7: All Proposed Changes to CM-Controlled Prod ucts Should Be Prop erly Clas sified .

Classes of changes to CM-controlled products include:

• Class I Cha nges—Changes that affect the

functionality or performance requirements, such asform, fit, function, or contractual cost, schedule,delivery, contract guarantees or warranties, or othercontractually agreed-to factors. This includesmemoranda of agreement or agreed-to work packagesbetween in-house organizations.

• Class II Changes—Minor documentation changesthat do not affect factors associated with Class I.

• Ex ter nal Cha nges—Changes to jointly owned ormanaged information (for example, interfaces), wherethe organizations owning the information do nothave a contractual relationship.

• Internal Changes —Changes that affect informationowned or used by someone else within anorganization, but which have not been approved or

delivered to the acquirer. These changes must becapable of implementation and must be withinbudget and schedule constraints.

RULE 6

(cont.)RULE 7



45

RULE 8: All CM Libra ry Structures or Releas es fro m the CM Libra ry Mus t Be Recorded in aSoftw ar e Vers ion Descrip tion (SVD) orComparable Document.

• The SVD documents the CM library structure stock list by product version ID;open problems;productincluded in the structure; closed p roblems resolvedby this product release; differences between thisversion of the CM structure and p revious release;andnotes, limitations, assumptions, and any other criticalinformation related to the partition.

• The SVD should include the environment necessary

to maintain or re-create the product: compiler nameand version, operating system and version, commandor build files, and compile instructions.

• All information released from CM, whether it bedocumentation, software, or full customer releases,should be documented through an SVD provided aspart of the release.

• The SVD should be comprehensive, documentingspecific content to the lowest-level controlled item,and should be built and maintained as part of theautomated CM tool.

• SVDs should be available electronically to all usersand stakeholders associated with the information.

• All individuals affecting or affected by a release

should be notified of the availability of the new SVD.

RULE 9: It Is Essentia l Tha t CM Be Continua lly Aw ar e of the Ex act Status of Prod ucts underControl, the Relatio nship s betw een these Pr od ucts,

Problems, and Op en Iss ues, and Who Is Using the Products.

• All library structures should contain a current index of the exact content of all products, version ID, releasestatus, and who is using the p roducts. The indexshould be hierarchical, treeing down to the lowest-controlled product.

• Each library structure should include all traceabilitymatrices that identify relationships between products

and the products and activities that assure them.• The CM library should maintain a cross-reference of

open SPRs and affected p roducts.

• The CM library should maintain records of who haschecked products out for change, and should lock theproduct against change until it is checked back in.

RULE 8 RULE 9



47

RULE 10: The Wors t Way to Esta blish a CM Sys tem Is to Purcha se a Too l Set a nd then Devise

a Process to Fit the Too ls. Esta blish the CM Process That Fits Your Project and Culture, then Find a Tool Set That Supports That Process.

Questions to ask when selecting CM methods or tools:

1. Does a process exist for CM from which therequirements for an automated tool may be derived?

2. Have the proposed CM techniques or tools beenproven in applications of similar size and complexitywith similar environments and characteristics?

3. Are the proposed CM techniques or tools consistentwith the documentation and review requirements of the customer or contract, and can the products thatresult be used without modification in other phasesof development?

4. Is there clear traceability between requirementsspecified by the CM process or tools and thoseneeded by related methodologies or tools? This is

essential since the CM tool is the basic integrator of information and, as such, must link to all componentsof the project.

5. Is it possible to p lan the overall information andorganizational flow of the project, interfaces, andrelationships between project segments and to definea schedule that integrates specific requirements of

the selected methodologies into a consistent andeffective project structure for test?

Corollary 1: Arti facts Used fo r Evaluat ing CM Effectiveness Mus t Be Prod ucts o f the Sys tem. If the CM Tool Set (Manual, Automated, or SomeCombination of Both) Does Not Prod uce the

Records Necessary to Verify CM Integrity, the

Tool Set Is Flawed.

Corollary 2: Only the Most Trivia l Develop mentCan Surv ive w ithout Automa ted Too ls.

Corollary 3: A Mature, Stable CM System( Proces s a nd Sup p or ting Too l Set) Does Not

Requ ire a n Ar my to Administe r It. A Few Goo d Peop le Should Be Able to Run Any Develop ment.

• Monitor the output of the CM process—the reports,reviews, and audits created or carried out in thecourse of day-to-day business. If no one reads or usesthe reports, eliminate them. If the reviews and auditsdon’t p roduce measurable improvement in theproduct, stop performing them.

RULE 10



49

INDICATORS OF

CONFIGURATION CONTROL

EFFECTIVENESS

Answers to the following questions provide indicatorsof the effectiveness of a program’s configuration controlprocess. The indicators provide a "quick look" at howwell configuration control supports programrequirements.

1. Configuration Identification Process:

a. Does the program have in place a documentedprocess for uniquely identifying each baselineddocument or app roved management, engineeringassurance, or reporting product, and are thesecontrolled items current (at the most recentrelease level)?

b. Has the program partitioned this information intoFunctional, Allocated, Design, and ProductBaselines, and does it maintain traceability andcontrol among them?

c. Is there a documented and approved process inplace to accept information into the configurationcontrol process and to update it once it's been

baselined?2. Change Control Process:

a. Does the program have in place an approvedprocess for proposing changes to baselinedinformation and for evaluating and approvingthese changes prior to implementation?

b. Does the program have in place a documented

process for evaluating the management, technical,

and assurance impacts of a change to baselinedinformation, and are these impacts consideredbefore a change is approved?

c. Does the program maintain records and audit

trails on the status of proposed changes thatare pending or have been approved forimplementation?

3. Status Accounting Process:

a. Does the program have a documented andagreed-to understanding of the configurationcontrol requirements for delivery, and is a processin place to implement it?

b. Does the program have in place a means tomonitor and document the status and currency of all information that it controls, and does itdocument this status when a release is madethrough the configuration control process?

c. Does the program document all releases througha Version Description Document (VDD), and does

this VDD contain a stock list of what is in therelease by version, the problems closed by therelease, problems still open with this release, andlimitations and restrictions of the release?



4. Configuration Control Review and Audit Process:

a. Does the program conduct regular reviews and/oraudits of information against approved standards,expected delivery content, and/or currency and

completeness of baselines?b. Is the configuration control process an integral

part of the program acceptance and releaseprocess, and is CM responsible for Physical andFunctional Audits in support of this requirement?

c. Can configuration control tell the status of allbaselined information, and does the CMorganization regularly conduct reviews or auditsto verify the status of items under its control?

5. Configuration Control Planning:

a. Does the approved configuration control planaccurately reflect the process being followed, andis it current and approved?

b. Is the configuration control process adequately

supported by effective tools, and are theresufficient resources and organizational supportand discipline to support the requirement?

c. Is there a process improvement plan in place toupgrade the configuration control process, and isthis plan implemented and adequately supported?

51

THE AIRLIE SOFTWARE COUNCIL

Victo r Basili Un iversity of Marylan d

Grady Booch Rational

Norm Brown Software Program Managers Network

Peter Chen Chen & Associates, Inc.

Chris tine Davis Texas Instruments

Tom DeMarco The Atlantic Systems Guild

Mike Dyer Lockheed Martin Corporation

Mike Evans Integrated Computer Engineering, Inc.

Bill Hetzel Qware

Capers Jones Software Productivity Research, Inc.

Tim Lister The Atlantic Systems Guild

John Manzo 3Com

Lou Mazzucche lli Gerard Klauer Mattison & Co., Inc.

Tom McCabe McCabe & Associates

Frank McGrath Software Focus , Inc .

Roger Pressman R.S. Pressman & Associates, Inc.

Larry Putnam Quantitative Software Management

Howard Rubin Hunte r Co llege , CUNY

Ed Yourdon American Programmer

INDICATORS OF

CONFIGURATION CONTROL

EFFECTIVENESS (cont.)

Documents

ConfigVersionMgmt - CM ML Book