CM ML book - AcqNotes book of Configuration Management.pdf · Major Elements of Configuration Management CM_ML_book 2/1/99 2:45 PM Page 4. 7 CM is essential to program and software

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]

http://www.spmn.com

SOFTWARE COUNCILAIRLIE

CM_ML_book 2/1/99 2:45 PM Page 1

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 managementand 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 essentialto managing large-scale software development andmaintenance projects. The Council, which meetsquarterly in Airlie,Virginia, is comprised of some 20 ofthe 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 shouldexist, 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 theinterest 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 SoftwareProgram 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 toenable 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 andmaintenance 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 BrownExecutive Director

CM_ML_book 2/1/99 2:45 PM Page ii

33

THE CM PROCESS

The fundamental purpose of Configuration Management(CM) is to establish and maintain the integrity and controlof software products throughout a project’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 ofchange 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 andtraceability 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, includingthe impact of changes to organizations, managementpractices, schedules, budgets, technical or assuranceactivities, testing or retest requirements, or project status

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

• Configuration reviews and audits that assess the statusand acceptability of products controlled or released by 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 isperformed 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. EvansPresident, Integrated Computer Engineering, Inc.

Jeannine Gathmann-HobbsManager, Configuration ManagementLockheed Martin Corporation


55

• 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 workproducts 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 ofcontrol 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 thestatus of the implementation of approved changes.Status record information provides an accessible and

CM BASICSTHE CM PROCESS

(cont.)

Major Elements ofConfigurationManagement

ConfigurationAudits

ConfigurationChangeControl

ConfigurationItem

Identification

StatusAccounting

ChangeCriteria

Specification, Design, Drawing,

Test Documentation,and Data Revisions

Change ControlProcedures, includingVerification of Change

Implementation

Change Control and Review

Organizations

Product Configuration

Identifiers(names and numbers)

Identification of Product

Acceptance Requirements

Identification of Changes

to Data Items

Specifications and Drawings

Data ReleaseIdentificationRequirements

FunctionalConfiguration

AuditsPhysical

ConfigurationAudits

FormalQualification

Reviews

ProductDescription

Records

ChangeStatus

Records

ConfigurationVerification

Records

Files ofChange Authorizations

and Approvals

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 softwaredevelopment 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 theinformation 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 necessary? After all, as an engineer,aren’t I most qualified to know how to fix aproblem? I’ve got schedules and technicalobligations to meet. I do not have the time to dealwith this bureaucratic delay. I’ve got important

current record of the status of each controlled pieceof 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 testorganization plans on accessing through 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

work to do. The change is just five lines of codethat I can patch. If I just change this interfaceslightly, the program will run twice as fast.”

This represents the frustration of dedicated engineersforced 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 softwareengineer 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 procedures. 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, orforget 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, oroperational 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 projectpersonnel, 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 ofconfiguration 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 ofthe development process and sharinginformation, 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 ofactivities and tasks. The following are key elements toestablishing a successful CM program:

1. Plan and document the software CMrequirements, activities, and responsibilities.

2. Establish a generic software development processand 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 majormodification, 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 ofConfiguration 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 properauthorization 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 configurationand contractual baselines.

• Establish implementation and timing ofinternal 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 alldetected 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/EngineeringReview 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 applicable.

9. Establish and document the configurationidentification scheme to be used for 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, andcorrective 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 workproducts 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 arecomplete and available with respect to thestatus of the work products and approvedmodifications 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 ofartifacts 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 JobFrom the inception of the project, create anenvironment where adherence to the establishedCM process is the only acceptable way of doingbusiness.

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 ofinformation, 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 tomisdiagnose. 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 ConfigurationManagementMake every aspect of your development processhelp your people adhere to the CM discipline.Define the engineering/CM process first, andrefine the process as necessary throughout theproject’s life cycle. Find those areas that causedevelopers and testers difficulty 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 hierarchical; requirements branch downward from aset 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 aproposal 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 define the process,then the tools must be selected to support 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 setcannot support this, the project 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 theindividuals have the technical expertise todevelop and implement sound processes andprocedures.

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, CMPlan, 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 project should not cutCM staff simply because things appear to be going well.The CM process must be institutionalized, not justwritten 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 stages of aproject. Staffing, budget, schedule, process, andprocedures should be planned and included inthe overall project’s strategy.

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

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

• Organization—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 proceduresfor 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 ofwork products and status of change.

• Configuration Audits—Describes the plans andprocedures 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 control in a timely manner.

RULE 2: Early identification and change control ofartifacts and work products is integral to a project.

RULE 3: The change management process must besimple, consistent with the culture and requirements ofthe project, and supported by the methods and tools ofthe project.

RULE 4: The actions, roles, and responsibilities of theEngineering Review Board (ERB) and the ChangeControl Board (CCB) should be documented.

RULE 5: Change control must be a primary focus ofthe program and must be integrated into the culture ofthe project.

RULE 6: All information that is placed under CMcontrol or promoted in the CM hierarchy must bepromoted based on successful completion of a quality 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 ofthe 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 ofboth) does not produce the records necessary to verifyCM 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 Ownership ofInformation and Bring Work Products underControl in a Timely Manner.

One critical aspect for control of work products is theproper 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.

System Requirements Review

Updated System Specification

Preliminary performance budget allocations

Final System SpecificationsTraceability of system requirementsPerformance/error budgets

Functional Baseline

System Design Review (SDR) or Preliminary Design Review (PDR)

Software Requirements Specifications (SRSs)

Interface Requirement Specifications (IRSs)

SRSs/IRSs traceability

SRSs/IRSs updateUpdate of requirements traceability to SRSs/IRSs and Software Development Description budgets

Allocated Baseline

Critical Design Review (CDR)

Detailed design

Detailed interface design

Test procedures

CI test plan

Detailed design updatesUpdated interface definitionsUpdated traceability

Preliminary Product Baseline or Detail Design Baseline

Test Readiness Review (TRR)/Site Acceptance Test

Establishment of configuration baseline, test documentation adequacy, compatibility with requirements, demonstration of performance in relation to system requirements

Detailed design approval to start testingBaselined software and test equipmentTraceability of tests to requirements

System Performance Test Baselinet

Configuration Audit

Verification of all CIs against system documentation

Configuration Controller Product 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 ofthis responsibility should be used to partition the controlof information. An example of how ownership is definedis shown in the figure below:

CM Workspace

Change AuthorizationChangeControl

ControlledProject

Area

Problem Closure

Baselined Data

Baselin

ed D

ata

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 forprogram 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 informationand/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-onlyprivileges 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 orowner 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 ofsoftware 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 Controlof Artifacts and Work Products Is Integral to aProject.

The project needs to fully identify and control changesto 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 workproducts 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-FurnishedInformation (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 MustBe Simple, Consistent with the Culture andRequirements of the Project, and Supported bythe Methods and Tools of the Project.

• The process 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 beconsistent with, the cultural aspects and realities ofthe 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 reportedthrough 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 EngineeringReview 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 asrequired 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 prior 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 Responsibilitiesof the Engineering Review Board (ERB) and theChange Control Board (CCB) Should BeDocumented.

Actions that may result from the ERB/CCB are:

• Reject—Reject the Software Problem Report (SPR).

• Assign 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 anotherproblem 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 and 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 ResponsibilitiesThe 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 ResponsibilitiesThe chairperson is responsible for resolving disputesregarding proposed changes and for implementing the 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/herjurisdiction

• 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 the

information 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: Change Control Must Be a Primary Focusof the Program and Must Be Integrated into theCulture of the Project.

• The project has to have a mechanism tointroduce change: Change is very often a function oftime—the longer the duration of the program, 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 allocateresources.

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

• Timely and comprehensive visibility of changestatus: Timely and comprehensive visibility of allchanges is needed through the ERB or CCB.

• A historical record of all changes: This record, oraudit trail, should be consistent with the tracking,reporting, and certification requirements of theprogram.

• Changes must be adjudicated before they aremade: The project should have a process to evaluateproject input and a forum through which to adjudicatethe implementation of a change before it is made.

RULE 6: All Information That Is Placed under CMControl or Promoted in the CM Hierarchy MustBe Promoted Based on Successful Completion ofa 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 ofplanned testing activities, project reviews, orindependent product analyses based on thecharacteristics, contractual status, use, and riskassociated with the product.

• For each quality gate conducted, a threshold belowwhich the specific product will not be approvedmust be defined. These thresholds serve as qualitytargets, by product, that must be met by the product.

• Product standards must identify what thedocumentation, 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 releaselevel, 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 processedcorrectly before a change to a controlled library is 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-ControlledProducts Should Be Properly Classified.

Classes of changes to CM-controlled products include:

• Class I Changes—Changes that affect thefunctionality 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.

• External Changes—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 ordelivered 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 Library Structures or Releasesfrom the CM Library Must Be Recorded in aSoftware Version Description (SVD) orComparable Document.

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

• The SVD should include the environment necessaryto 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 releaseshould be notified of the availability of the new SVD.

RULE 9: It Is Essential That CM Be ContinuallyAware of the Exact Status of Products underControl, the Relationships between these Products,Problems, and Open Issues, and Who Is Using theProducts.

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

• Each library structure should include all traceabilitymatrices that identify relationships between productsand the products and activities that assure them.

• The CM library should maintain a cross-reference ofopen SPRs and affected products.

• 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 Worst Way to Establish a CMSystem Is to Purchase a Tool Set and then Devisea Process to Fit the Tools. Establish the CMProcess That Fits Your Project and Culture, thenFind 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 ofthe 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 isessential since the CM tool is the basic integrator ofinformation and, as such, must link to all componentsof the project.

5. Is it possible to plan the overall information andorganizational flow of the project, interfaces, andrelationships between project segments and to definea schedule that integrates specific requirements ofthe selected methodologies into a consistent andeffective project structure for test?

Corollary 1: Artifacts Used for Evaluating CMEffectiveness Must Be Products of the System. Ifthe CM Tool Set (Manual, Automated, or SomeCombination of Both) Does Not Produce theRecords Necessary to Verify CM Integrity, theTool Set Is Flawed.

Corollary 2: Only the Most Trivial DevelopmentCan Survive without Automated Tools.

Corollary 3: A Mature, Stable CM System(Process and Supporting Tool Set) Does NotRequire an Army to Administer It. A Few GoodPeople Should Be Able to Run Any Development.

• 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 produce 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 approved 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 beenbaselined?

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 documentedprocess 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 audittrails on the status of proposed changes that are 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 ofall 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 doesthis 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 andcompleteness of baselines?

b. Is the configuration control process an integralpart 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 adequatelysupported 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

Victor Basili University of Maryland

Grady Booch Rational

Norm Brown Software Program Managers Network

Peter Chen Chen & Associates, Inc.

Christine 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 Mazzucchelli 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 Hunter College, CUNY

Ed Yourdon American Programmer

INDICATORS OF

CONFIGURATION CONTROL

EFFECTIVENESS (cont.)


Documents

CM ML book - AcqNotes book of Configuration Management.pdf · Major Elements of Configuration Management CM_ML_book 2/1/99 2:45 PM Page 4. 7 CM is essential to program and software