IEEE

Std 828-1983

IEEE Standard for

Software Configuration Management P l a n s

Sponsor

Software Engineering Technical Committee

of the
IEEE Computer Society

© Copyright 1983 by

The Institute of Electrical and Electronic Engineers, Inc

345 East 47th Street, N e w York, NY 10017

No part of this publication may be reproduced in any form,

in an electronic retrieval system or otherwise,
without the prior written permission of the publisher.

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 IEEE Standards documents are developed within the Technical Com­
mittees of the IEEE Societies and the Standards Coordinating Commit­
tees of the IEEE Standards Board. Members of the committees serve
voluntarily and without compensation. They are not necessarily mem­
bers of the Institute. The standards developed within IEEE represent
a consensus of the broad expertise on the subject within the Institute
as well as those activities outside of IEEE which have expressed an in­
terest in participating in the development of the standard.
Use of an IEEE Standard is wholly voluntary. The existence of an
IEEE Standard does not imply that there are no other ways to pro­
duce, test, measure, purchase, market, or provide other goods and ser­
vices related to the scope of the IEEE Standard. Furthermore, the view­
point expressed at the time a standard is approved and issued is subject
to change brought about through developments in the state of the art
and comments received from users of the standard. Every IEEE Stan­
dard is subjected to review at least once every five years for revision
or reaffirmation. When a document is more than five years old, and has
not been reaffirmed, it is reasonable to conclude that its contents,
although still of some value, do not wholly reflect the present state of
the art. Users are cautioned to check to determine that they have the
latest edition of any IEEE Standard.
Comments for revision of IEEE Standards are welcome from any
interested party, regardless of membership affiliation with IEEE. Sug­
gestions for changes in documents should be in the form of a proposed
change of text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the mean­
ing of portions of standards as they relate to specific applications. When
the need for interpretations is brought to the attention of IEEE, the
Institute will initiate action to prepare appropriate responses. Since
IEEE Standards represent a consensus of all concerned interests, it is
important to ensure that any interpretation has also received the con­
currence of a balance of interests. For this reason IEEE and the mem­
bers of its technical committees are not able to provide an instant re­
sponse to interpretation requests except in those cases where the matter
has previously received formal consideration.
Comments on standards and requests for interpretations should be ad­
dressed to:
Secretary, IEEE Standards Board
345 East 47th Street
New York, NY 10017
USA

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
(This Foreword is not a part of IEEE Std 828-1983, IEEE Standard for Software Configuration Man­
agement Plans.)
Software Configuration Management (SCM) is a formal engineering discipline which provides
software developers and users with the methods and tools to identify the software developed, establish
baselines, control changes to these baselines, record and track status, and audit the product. SCM is
the means through which the integrity and continuity of the software product are recorded, communi­
cated, and controlled. The application of SCM, together with Hardware Configuration Management
and overall Systems Configuration Management, benefits all phases of the life cycle of a system
containing software components and is a matter of good engineering practice. Without SCM, the
reliability and the quality of the software cannot be assured.
This standard assists in the preparation of SCM plans for all environments; for example, large-scale
ADP systems, embedded computer systems, control processors, etc, and provides a standard against
which such plans can be prepared and assessed. It is directed toward the development and mainte­
nance of all software, including critical software, that is, software whose failure could impact safety or
cause large financial or social losses.
There are three groups served by this standard: the users, the developers, and the public.
(1) It aids the users in obtaining and supporting a software product consistent with the users'
evolving needs. It assists the users in obtaining a reasonable degree of confidence that the product is in
the process of acquiring required attributes as the software is being developed and maintained.
(2) It aids the developers by providing an established standard against which a cost-effective
solution to SCM needs can be planned and measured throughout the applicable portions of the soft­
ware life cycle.
(3) It aids the public by enhancing the likelihood that a software product will perform as expected.
The public has legal rights which preclude haphazard control of software development and maint­
enance. At some later date, the users and developers may be required to show that they acted in a
reasonable and prudent manner to ensure that adequate controls were applied.
This standard is consistent with ANSI/IEEE Std 730-1981, IEEE Standard for Software Quality
Assurance Plans and IEEE Std 729-1983, IEEE Standard Glossary of Software Engineering Terminol­
ogy. This standard may be applied in conjunction with those standards, or independently.
This standard was prepared by a working group of the Software Engineering Subcommittee of the
Technical Committee on Software Engineering of the IEEE Computer Society. The working group had
the following members:

R. Frederick, Chairman

H. R. Berlack J. Granton J. Postak

E. Bersoff N. Hill R. M. Poston
F. J . Buckley J. H. Johnston P. B. Powell
R. Clingan C. Kolb S. Siegel
D. Dorazio Τ. M. Kurihara L. Starbuck
R. Evans W. A. Mandeville Β. Taute
A. E t s J. Miguel A. Terentiev
J. J. Forman J. Neilson N. Thomas
J . Fonj D. Paster R. L. Van Tilburg
N. P. Ginex R. Phillips J. Williamson

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 At the time the Software Engineering Standards Subcommittee approved the standard, it had the
following members:

F. J. Buckley, Chairman

R. J. Abbott R. A. Felker Τ. M. Kurihara L. B. Robertson

A. F. Ackerman J. W. Fendrich J. A. Kyle R. E. Sandborgh
R. L. Aurbach J. Flourney D. V. LaRosa M. J. Schindler
J. P. Bateman J. J. Forman R. C. Lane Ν. F. Schneidewind
N. G. Biasi R. Fredrick G. N. Larson R. W. Schölten
E. G. Booch M. Galinier A. C. Ma L. W. Seagren
M. A. Branstead A. Ganz A. J. Mäher C. L. Shermer
W. A. Bryan F. Κ. Gardner Α. Κ. Mahindru D. J. Simkins
D. C. Burt D. Gelperin W. Α. Mandeville J. E. Skeen, Jr
H. C. Carney M. J. Gooding P. C. Marriott J. M. Smith
M. Carney S. Gloss-Soler C. F. Martiny Η. N. Sneed
C. L. Carpenter R. W. Graves G. T. Morun T. Q. Stevenson
J. V. Cellini B. W. Greene W. G. Murch D. B. Tabor
J. W. Center J. J. Greene S. Najafi K. C. Tai
E. R. Comer J. W. Grigsby J. Nebb B. Taute
J. D. Cooper R. M. Gross G. R. Neidhart J. R. Thompson
A. J. Cote, Jr R. T. Güstin D. J. Ostrom P. U. Thompson
R. Cotter V. Ε. Haas D. E. Peercy G. D. Tice, Jr
J. W. Currier Τ. L. Hannan Μ. T. Perkins T. L. Tillmanns
P. W. Daggett L. R. Hestelton, III D. J. Pfeiffer H. J. Trochesset
G. Darling C. P. Hollocker R. M. Poston C. L. Troyanowski
P. A. Denny S. Horvitz M. A. Potter W. S. Turner, III
A. Dniestrowski Η. B. Hoyle P. B. Powell Ε. A. Ulbrich, Jr
J. A. Dobbins S. Hwang S. J. Raddue R. L. Van Tilburg
W. DuBlancia J. H. Ingram S. R. Rakitin Α. H. Weigel
R. E. Dwyer J. M. Ives J. Rault P. J. D. Weyman
M. L. Eads R. M. Jacobs H. Reiche W. M. Wong
J. W. Earls G. Konomos D. J. Reifer A. W. Yonda
P. F. Zoll

Special representatives to the Software Engineering Standards Subcommittee were:

H.R. Berlack Electronic Industries Association

J. Milandin ANS ZI
W. Perry Data Processing Management Association
R. Pritchett EDP Auditors Association
T. L. Regulinski IEEE Reliability Society

At the time the IEEE Standards Board approved this standard on June 23, 1983 it had the following
members:

James H. Beall, Chairman Edward Chelotti, Vice Chairman

Sava I. Sherr, Secretary
J. J. Archambault Donald H. Heirman John P. Riganati
John T. Boettger Irvin N. Howell Frank L. Rose
J. V. Bonucchi Joseph L. Koepfinger* Robert W. Seelbach
Rene Castenschiold Irving Kolodny Jay A. Stewart
Edward J. Cohen George K o n o m o s Clifford O. Swanson
Len S. Corey John E. May Robert E. Weiler
Donald C. Fleckenstein Donald T. Michael* W. B. Wilkens
Jay Forster Charles J. Wylie

Member emeritus

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 Contents
SECTION PAGE

1. Scope and References 7

1.1 Scope 7
1.2 References 7

2. Definitions and Acronyms 7

2.1 Definitions 7
2.2 Acronyms 7

3. Software Configuration Management Plans 7

3.1 Introduction (Section 1 of the Plan) 8
3.1.1 Purpose (1.1 of the Plan) 8
3.1.2 Scope (1.2 of the Plan) 8
3.1.3 Definitions and Acronyms (1.3 of the Plan) 8
3.1.4 References (1.4 of the Plan) 8
3.2 Management (Section 2 of the Plan) 8
3.2.1 Organization (2.1 of the Plan) 8
3.2.2 SCM Responsibilities (2.2 of the Plan) 8
3.2.3 Interface Control (2.3 of the Plan) 9
3.2.4 SCMP Implementation (2.4 of the Plan) 9
3.2.5 Applicable Policies, Directives, and Procedures
(2.5 of the Plan) 9
3.3 SCM Activities (Section 3 of the Plan) 9
3.3.1 Configuration Identification (3.1 of the Plan) 9
3.3.2 Configuration Control (3.2 of the Plan) 9
3.3.3 Configuration Status Accounting (3.3 of the Plan) 10
3.3.4 Audits and Reviews (3.4 of the Plan) 11
3.4 Tools, Techniques, and Methodologies (Section 4 of the Plan) 11
3.5 Supplier Control (Section 5 of the Plan) 11
3.6 Records Collection and Retention (Section 6 of the Plan) 11

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 IEEE Standard for
Software Configuration Management P l a n s

1. S c o p e and References (1) ANSI/IEEE Std 730-1981, IEEE Standard

for Software Quality Assurance Plans 1

(2) IEEE Std 729-1983, IEEE Standard Glos­

1.1 Scope. sary of Software Engineering Terminology 2

(3) IEEE Std 829-1983, IEEE Standard for

This standard provides minimum require­
Software Test Documentation
ments for preparation and content of Software
Configuration Management (SCM) Plans. SCM
2. Definitions and A c r o n y m s
Plans document the methods to be used for
identifying software product items, controlling 2.1 Definitions. The definition listed here es­
and implementing changes, and recording and tablishes meaning in the context of this stan­
dard. Other definitions can be found in IEEE Std
reporting change implementation status.
729-1983 [2]. See specifically: baseline, con­
3

This standard applies to the entire life cycle of

figuration item, configuration management,
critical software; for example, where failure configuration control, configuration control
could impact safety or cause large financial or board, configuration audit, configuration
social losses. For noncritical software, or for soft­ identification, configuration status account­
ware already developed, a subset of the require­ ing, and software library.
ments may be applied.
interface control. The process of: (1)
This standard identifies those essential items
Identifying all functional and physical charac­
that shall appear in all Software Configuration teristics relevant to the interfacing of two or
Management Plans. In addition to these items, more configuration items provided by one or
the users of this standard are encouraged to in­ more organizations. (2) Ensuring that proposed
corporate additional items into the plan, as ap­ changes to these characteristics are evaluated
propriate, to satisfy unique configuration man­ and approved prior to implementation.
agement needs, or to modify the contents of spe­
2.2 Acronyms. The following acronyms are re­
cific sections to fully describe the scope and mag­ ferred to within the text of this standard:
nitude of the software configuration manage­ CC6 Configuration Control Board
ment effort. Where this standard is invoked for a SCM Software Configuration Management
project engaged in producing several software SCMP Software Configuration Management
items, the applicability of the standard shall be Plan
specified for each of the software product items
encompassed by the project. 3. Software Configuration Management
Examples are incorporated into the text of Plans
this standard to enhance clarity and to promote The organization or person responsible for
understanding. Examples are either explicitly Software Configuration Management shall pre­
identified as such, or can be recognized by the pare a Software Configuration Management
use of the verb may. Examples shall not be con­ Plan (hereafter referred to as the Plan) that in­
strued as mandatory implementations. cludes the sections and subsections listed below.
1
ANSI standards are available from the Sales Depart­
1.2 References. ment, American National Standards Institute, 1430 Broad­
way, New York, NY 10018
The standards listed here should be consid­ *IEEE standards are available from IEEE Service Cen­
ter, 445 Hoes Lane, Piscataway, NJ 08864.
ered when applying this standard. The latest re­ 3
The numbers in brackets correspond to the references in
visions shall apply. 1.2.

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std 8 2 8 - 1 9 8 3 IEEE S T A N D A R D FOR SOFTWARE

The sections and subsections shall be ordered in 3.1.3 Definitions and Acronyms (1.3 of the
the described sequence (if there is no informa­ Plan). This subsection shall define or provide a
tion pertinent to a section or subsection, the fol­ reference to the definitions of all terms and acro­
lowing information shall appear below the sec­ nyms required to properly interpret the SCMP.
tion or subsection heading: There is n o perti­ 3.1.4 References (1.4 of the Plan). This sub­
nent information for this section together section shall:
with the appropriate reasons for the exclusion). (1) Provide a complete list of all documents
(1) Introduction referenced elsewhere in the SCMP.
(a) Purpose (2) Identify each document by title, report
(b) Scope number, if applicable, date, and publishing or­
(c) Definitions and acronyms ganization.
(d) References (3) Specify the sources from which the refer­
(2) Management enced documents can be obtained.
(a) Organization
(b) SCM responsibilities 3.2 Management (Section 2 of the Plan). This
(c) Interface control section shall describe the organization, and as­
(d) SCMP implementation sociated responsibilities.
(e) Applicable policies, directives and proce­
dures 3.2.1 Organization (2.1 of the Plan). This
(3) SCM activities subsection shall describe the organizational
(a) Configuration identification structure that influences the configuration man­
(b) Configuration control agement of the software during the development
(c) Configuration status accounting and the operation and maintenance phases. This
(d) Audits and reviews shall:
(4) Tools, techniques, and methodologies (1) Describe each major element of the organi­
(5) Supplier control zation together with the delegated responsibili­
(6) Records collection and retention ties. Organizational dependence or indepen­
Additional sections may be added at the end, dence of the elements responsible for SCM from
as required. Some of the material may appear in those responsible for software development and
other documents. If so, reference to those docu­ use shall be clearly described or depicted.
ments shall be made in the body of the plan. (2) Include an organizational chart or list for
The cover page of the plan shall identify the the project which illustrates the structure for
plan and the project to which the plan pertains. program/project/system management.
As a minimum, the plan shall be signed by the (3) Describe the organization responsible for
chief operating-officer of each unit having re­ SCM during the operation and maintenance
sponsibilities defined within the SCMP. phase.
Detailed requirements for each portion of the (4) Describe the interface between the devel­
Plan are described in 3.1 through 3.6 of this oping organization and the using organization,
standard. if any, with particular emphasis on the transfer
of SCM functions in the operation and mainte­
3.1 Introduction (Section 1 of the Plan). This nance phase.
section shall provide an overview of the plan. (5) Specifically cover the organizational rela­
3.1.1 P u r p o s e (1.1 of the Plan). This subsec­ tionships with the Configuration Control Board
tion shall delineate the specific purpose of the in the development and the operation, and
particular Software Configuration Management maintenance phases.
Plan.
3.1.2 Scope (1.2 of the Plan). This subsection 3.2.2 SCM Responsibilities (2.2 of the
shall identify the software items to be produced Plan). This subsection shall describe:
and used, the organizations, the activities, and (l)The organizational responsibilities for
the phases of the software life cycle to which the each SCM task; for example, identification, con­
plan applies. trol, status accounting, and reviews and audits.

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 IEEE
CONFIGURATION MANAGEMENT PLANS Std 8 2 8 - 1 9 8 3

(2) The relationships with software quality-as­ (2) Describe any SCM policies, directives, and
surance, software development, and other func­ procedures that are to be written and imple­
tional organizations required to ensure delivery mented for this project
of the approved final product configuration. Examples of material which may be covered
(3) The responsibilities of the users and devel­ by policies, directives, and procedures are:
oper/maintenance activity in the review, audit, (a) Identification of levels of software in a
and approval process during each phase of the hierarchical tree
life cycle indicated in 1.2 of the Plan. (b) Program and module naming conven­
(4) Any SCM responsibilities of the represen­ tions
tatives from each organization participating in (c) Version level designations
the product development. (d) Software product identification methods
(5) The overall responsibility of the Configura­ (e) Identification of specifications, test
tion Control Board. plans and procedures, programming manuals,
(6) Any unusual responsibilities such as spe­ and other documents
cial approval requirements necessary to meet (f) Media identification and file manage­
SCM requirements. ment identification
(g) Document release process
3.2.3 Interface Control (2.3 of the Plan). (h) Turnover or release of software products
This subsection shall describe the methods to be to a library function
utilized to: (i) Processing of problem reports, change
(1) Identify interface specifications and con­ requests, and change orders
trol documents. (j) Structure and operation of configuration
(2) Process changes to released interface spe­ control boards
cifications and documents. (k) Release, and acceptance of software
(3) Provide follow-up on action items sched­ products
uled to be accomplished on items pertaining to (1) Operation of software library systems to
SCM. include methods of preparing, storing, and up­
(4) Maintain status of interface specifications dating modules
and control documents. (m) Auditing of SCM activities
(5) Control the interface between software and (n) Problem report, change request or
the hardware on which it is running. change order documentation requirements de­
scribing purpose and impact of a configuration
3.2.4 SCMP Implementation (2.4 of the
change, or both
Plan). This subsection shall establish the major
(o) Level of testing required prior to entry
milestones for implementation of the SCMP.
of software into configuration management
Example milestones include the establish­
(p) Level of quality assurance; for example,
ment of:
verification against development standards, re­
(l)The configuration control board
quired prior to entry of software into configura­
(2) Each configuration baseline
tion management
(3) Schedules and procedures for SCM reviews
and audits 3.3 SCM Activities (Section 3 of the Plan).
(4) Configuration management of related soft­ This section shall describe how the following re­
ware development, test, and support tools quirements for SCM shall be satisfied:
(1) Configuration identification
3.2.5 Applicable Policies, Directives, and
(2) Configuration control
P r o c e d u r e s (2.5 of the Plan). This subsection
(3) Configuration status accounting and re­
shall:
porting
(1) Identify all applicable SCM policies, direc­
(4) Configuration audits and reviews
tives, and procedures which are to be imple­
mented as part of this plan. The degree of imple­ 3.3.1 Configuration Identification (3.1 of
mentation of each shall be stated the Plan). This subsection shall:

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std 8 2 8 - 1 9 8 3 IEEE S T A N D A R D FOR SOFTWARE

3.3.1.1 Identify the software project base­ 3.3.2 Configuration Control (3.2 of the
lines (that is, the initial approved configuration Plan). This subsection shall:
identifications) and correlate them to the spe­ 3.3.2.1 Describe the level of authority for
cific life-cycle phases defined in 1.2 of the Plan. change approval to be used in each of the life
For each baseline, the following shall be de­ cycle phases identified in 1.2 of the Plan.
scribed: 3.3.2.2 Define the methods to be used to
3.3.1.1.1 The items which form each process change proposals to established configu­
baseline (for example, software requirements rations. As a part of this, this section shall:
specification, deliverable software, etc). (1) Identify the routing of change proposals
3.3.1.1.2 The review and approval events, during each of the software life cycle phases
and the acceptance criteria associated with es­ identified in 1.2 of the Plan. This may be pro­
tablishing each baseline. vided in chart form with narrative support.
3.3.1.1.3 The users' and developers' parti­ (2) Describe the methods of implementing ap­
cipation in establishing baselines. proved change proposals (to include changes in
The following are example baselines which source and object code, and documentation).
may be established as indicated: (3) Describe the procedures for software
(1) Functional Baseline. The agreement be­ library control including those procedures which
tween the developers and the users that defines provide for:
all the system level functions and the system (a) Access control
test criteria. (b) Read and write protection for applicable
{2) Allocated Baseline. The agreement be­ baselines
tween the developers and the users that identi­ (c) Member protection
fies all the software requirements to include de­ (d) Member identification
sign constraints and user-required standards. (e) Archive maintenance
(3) Product Baseline. The agreement between (f) Change history
the developer and the user that defines the exact (g) Disaster recovery
version of the software product which is to be (4) If patches must be used to change object
accepted. Elements of this baseline definition code, describe the methods for identification and
might include the following: control
(a) Product name and nomenclature
3.3.2.3 For each CCB and other change
(b) Product identification number
management bodies:
(c) For each new version release, the ver­
(1) Define the role of each; for example,
sion release number, a description of the new
change review authority
changes, the change release vehicle, the changes
(2) Specify their authority and responsibility
to any support software, and the changes to the
(3) Identify the chairperson and the member­
associated documentation
ship in the organizations, if the organizations
(d) Installation instructions
have been formed
(e) Known faults and failures
(4) State how the chairperson and the mem­
(f) Software media and media identifica­
bers (and alternates) are to be appointed, if the
tion
organizations have not yet been formed
3.3.1.2 Delineate the project titling, label­ (5) State the relationships of the developers
ing, numbering, and cataloging procedures for and the users to the CCB(s)
all software code and documentation.
As an example, for code: 3.3.2.4 State the methods to be used for con­
3.3.1.2.1 The compilation date may be in­ figuration control of interfaces with programs/
dicated as a part of the identification for each projects beyond the scope of this SCMP. If the
delivered module. software changes are required to be reviewed by
3.3.1.2.2 The sequence numbering of all other boards or teams prior to or in addition to
source lines of code in a module may be struc­ the CCB(s), this subsection shall describe these
tured so that future changes to any module can boards (or teams, or both) and their relationship
be properly noted. to the CCB(s) and to each other.

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.
 IEEE
CONFIGURATION MANAGEMENT PLANS Std 8 2 8 - 1 9 8 3

3.3.2.5 State the control procedures for asso­ (1) Identify software media and media docu­
ciated special software products, such as nonre- mentation
leased software, off-the-shelf software, user-fur­ (2) Bring documentation and media under
nished software, and in-house support software. SCM control and formally release it to a user
3.3.3 Configuration Status Accounting (3.3 As examples, it may:
of the Plan). This subsection shall: (a) Provide a description of the tools,
(1) Delineate how information on the status of methodologies, and techniques to be used for
configuration items is to be collected, verified, source and object control within the software
stored, processed, and reported libraries, to include a description of the
(2) Identify the periodic reports to be provided, Database Management System, if used
and their distribution (b) State how the software library tools,
(3) State what dynamic inquiry capabilities, if methodologies, and techniques are to be used to
any, are to be provided process software products for release
(4) Describe the means to be used to imple­ (3) Document the status of changes made to
ment any special status accounting require­ software and associated documentation. It shall
ments specified by the user further define the tools, methodologies, and
Some examples of information normally de­ techniques to be used to prepare reports for vari­
sired is as follows: ous levels of management, such as the project
(a) Status of specifications manager, CCB, SCM, and the user.
(b) Status of proposed changes
(c) Reports of approved changes 3.5 Supplier Control (Section 5 of the Plan).
(d) Status of product versions or revisions This section shall state the provisions for assur­
(e) Reports of the implementation of in­ ing that vendor-provided and subcontractor-
stalled updates or releases developed software meet established SCM re­
(f) Status of user-furnished property; for quirements. As a part of this, this section shall:
example, user-furnished operating systems (1) Indicate the proposed methods for control
of subcontractors and vendors insofar as it im­
3.3.4 Audits and R e v i e w s (3.4 of the Plan).
pacts on the execution of this SCMP
This subsection shall:
(2) Explain the methods to be used:
(1) Define the SCM role in audits and reviews
(a) To determine the SCM capability of sub­
to be performed at specified points in the soft­
ware life cycle defined in 1.2 of the SCMP contractors and vendors
(2) Identify the configuration items to be cov­ (b) To monitor their adherence to the re­
ered at each of these audits and reviews quirements of this SCMP
(3) State the procedures to be used for the As a minimum, the supplier shall be re­
identification and resolution of problems occur­ quired to prepare and implement a SCM plan in
ring during these audits and reviews accordance with this standard.

3.4 Tools, Techniques, and Methodologies 3.6 Records Collection and Retention (Sec­
(Section 4 of the Plan). This section shall tion 6 of the Plan). This section shall:
identify, state the purposes, and describe (1) Identify the SCM documentation to be re­
(within the developers' scope of proprietary tained
rights) the use of the specific software tools, (2) State the methods and facilities to be used
techniques, and methodologies to be employed to to assemble, safeguard, and maintain this docu­
s' >port SCM on the specific project. This shall mentation. As part of this, identify any off-site
include the tools, techniques, and methodologies backup facilities to be used
used to: (3) Designate the retention period

11

Authorized licensed use limited to: CINVESTAV. Downloaded on June 13,2018 at 20:54:30 UTC from IEEE Xplore. Restrictions apply.