ISO/IEC TR 15846:1998

TECHNICAL ISO/IEC
REPORT TR 15846
First edition
1998-11-01
Information technology — Software life
cycle processes — Configuration
Management
Technologies de l'information — Procédés de cycle de vie du logiciel —
Gestion de configuration
Reference number
B C
Contents
1 Scope . 1
1.1 Tailoring this Technical Report. 1
1.2 Process roles . 1
2 Conformance . 1
3 Normative references. 1
4 Definitions. 2
5 Symbols (and abbreviated terms) . 3
5.1 Abbreviations and acronyms . 3
6 SCM Process Implementation. 3
6.1 Initiating and defining the scope. 3
6.1.1 Defining the inputs to the SCM Process. 3
6.1.2 Defining the resources and constraints to the SCM Process . 3
6.1.3 Allocating responsibility and authority. 3
6.1.4 Criteria for selection of SCIs. 4
6.1.5 Defining the outcomes from the SCM Process . 4
6.2 Planning . 4
6.3 Controlling execution. 5
6.4 Review and evaluation of the SCM Process. 5
6.5 Closing . 5
7 Software configuration identification. 5
7.1 Identifying SCIs . 5
7.2 Identifying software configuration baselines. 6
7.3 Identifying software libraries. 6
7.4 Advancement status . 6
8 Software configuration control. 6
8.1 Proposing changes. 6
8.2 Evaluating the impact of proposed changes . 7
8.3 Implementing the changes. 7
8.4 Communicating the disposition. 7
8.5 Closing the changes. 7
9 Software configuration status accounting. 7
9.1 Recording the identification. 7
9.2 Tracing changes . 7
9.3 Reporting status accounting records. 8
10 Software configuration evaluation . 8
11 Software release management and delivery. 8
11.1 Handling . 9
11.2 Storing. 9
11.3 Replicating. 9
11.4 Packaging. 9
11.5 Delivering. 9
12 Interface control. 10
Annex A (normative) Mapping of clauses between ISO/IEC TR 15846, ISO/IEC 12207 and ISO 10007. 11
Bibliography. 17
©  ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
©
ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of Technical Reports through technical committees established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The main task of technical committees is to prepare Technical Reports, but in exceptional circumstances a technical committee
may propose the publication of a Technical Report of one of the following types:
— type 1, when the required support cannot be obtained for the publication of a Technical Report, despite repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the future but not
immediate possibility of an agreement on a Technical Report;
— type 3, when a technical committee has collected data of a different kind from that which is normally published as a
Technical Report (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they can be
transformed into International Standards. Technical Reports of type 3 do not necessarily have to be reviewed until data they
provide are considered to be no longer valid or useful.
ISO/IEC TR 15846, which is a Technical Report of type 1, was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 7, Software engineering.
Annex A forms an integral part of this Technical Report.
iii
©
ISO/IEC
Introduction
Relationship with other Technical Reports
This Technical Report presents the requirements for the Software Configuration Management (SCM) Process. SCM is a
supporting CM Process to the life cycle of a software product, as described in ISO/IEC 12207, "Information technology -
Software life cycle processes". SCM provides continuity across the Operation, Maintenance and Development Processes.
Annex A (informative) of this Technical Report shows the relationship with the clauses of ISO/IEC 12207.
Where text has been quoted from ISO/IEC 12207:1995, that text is enclosed in a box, for ease of identification.
This Technical Report keeps consistency with ISO 10007 "1995, Quality management — Guidelines for configuration
management".  The relationship of the clauses in ISO 10007 to the clauses in this Technical Report is shown in annex A.
Types of software
SCM administers any information that can be stored in a computer, including the software products. For example:
specifications, database schema, test cases, user operating instructions, reusable coded objects, source and executable code, or
data.
SCM may also administer lists and records about software items of significance stored in other locations. For example:
products installed at an operational site, or off-the-shelf products loaded on a network.
Software products used as tools in the software environment to create, maintain, archive or restore the deliverable software
product, are also types of software capable of being administered by SCM, as are the instructions and any customization or
parameters to operate the tool. The software environment (for example development) may be deliverable or may be proprietary.
SCM can apply to few or to all items of software from a life-cycle activity.
Implementation of the SCM Process
SCM may be performed by a combination of software tools, methods and techniques. This Technical Report does not specify
how to implement or perform the activities and tasks in the SCM Process. The SCM requirements remain the same irrespective
of the tools by which SCM is implemented.
A number of emerging requirements for SCM (e.g. for product delivery to multiple sites with different product configurations,
or for concurrent modification of Configuration Items - CIs) may apply the SCM Process in this Technical Report to assist in
controlling these emerging areas. Parties wishing to operate such tasks are advised to define the additional requirements in
contract agreements or SCM policy and procedures.
NOTE A procedure may a document, a template, etc.
Benefits
This Technical Report can improve the visibility and accountability within the Operation, Maintenance and Development
Processes by:
• providing an appropriate documented and repeatable scheme for identifying and controlling electronic documents, code,
interfaces, databases, etc., to support the software life-cycle processes;
• supporting a chosen development, maintenance or operations methodology fitting the requirements, standards, policies and
directives, organization and management philosophy;
• producing management and product information concerning the status of baselines, changes, releases, versions, archives,
etc.;
• recursively defining a Software CI (SCI) to the level of individual items of significance to be controlled;
• controlling the libraries used to store SCIs together with their status and related information;
• invoking the ISO/IEC 12207 Processes to assure the integrity of the configurations;
• controlling the software environment to enable a software product to be configured and reconfigured over its useful life,
including the software tools used to develop and verify the software product; to assure the integrity of the configuration
(e.g. requirements tracker, SCM library guardian, release builder); and to run those tools (e.g. operating system);
• storing and retrieving information on anomalies for individual SCIs and for software product configurations;
• reporting the ownership for intellectual property considerations, such as licences or copyright.
iv
©
ISO/IEC
SCM in contractual relationships
The SCM requirements are derived from at least three supply chain relationships:
• acquirer placing work on the software product supplier;
• supplier responsible for delivering the software product;
• subcontractor or software technicians to carry out the work.
A fourth relationship may exist where the acquirer and supplier agree to use a third party archive (for escrow). In this
relationship, in addition to the bi-directional supply chain between acquirer and supplier, there is a triangular unidirectional
flow from the supplier via the third-party archive to the acquirer (see Table 1 and Figure 1).
Benefits to the prime acquirer
For the acquirer some benefits of SCM are:
• assurance of the completeness of the development, operations or maintenance requirements;
• flexibility to enable changes to the requirements to be made under controlled conditions;
• basis to establish evaluation criteria for SCM activities and tasks;
• provision of complete and incomplete (e.g. engineering release) items.
Use of this Technical Report is intended to help ensure:
• project objectives meet customer and organizational constraints;
• criteria and means for determining successful completion of project objectives are defined;
• SCM software life-cycle products and their inter-relationships are defined;
•
inter-relationships between processes are defined, where an SCM activity interacts with other software life-cycle
process(es), e.g. Software Quality Assurance;
• software baselines are controlled;
• a plan for SCM activities, or related planning document, is created, used, monitored and adjusted;
• SCM interfacing between two or more parties or processes is defined.
Where multiple teams and/or subcontractor relationships require more emphasis on interface management, the configuration
control is normally tailored to cater to changes across interfaces rippling through levels of subcontracts or organizations.
Benefits to the software product supplier
Some benefits of SCM to the software product supplier are:
• looking after items fulfilling the requirements and by controlling change;
• support for the Joint Reviews Process by providing the status of SCIs (in this instance, the major software product from a
life-cycle process) attached to management milestones;
• support for the Audit Process by concentrating on results which are measurable for compliance checking;
• support for the Quality Assurance, Verification and Validation Processes to the extent they are present in the software
life cycle.
Benefits to a subcontractor or software technician
Some benefits of SCM to subcontractors or software technicians are:
• stable baselines with assurance these baselines can be rebuilt;
• consistent communication of status;
• status and interdependence of outstanding requirements;
• notification, analysis and reversal of change;
•
delegated change authority;
• consistent method for handling, storing, replicating, packaging and releasing SCIs.
Benefits of any third party archive (escrow)
The status of SCIs may be shared between a supplier, an acquirer and a third-party agent charged with holding items until some
contract condition is met, for example, final payment or liquidation of the supplier.
A benefit to the acquirer and supplier of a third-party agent applying SCM is the integrity of the deposited SCIs. This
Technical Report provides requirements for guarding and retrieving these SCIs.
v
©
ISO/IEC
Role As Acquirer As Supplier
Acquirer/operator/user To software product supplier: To final client:
request product may supply software product
receive SCM managed product may use software product to deliver
information technology service
Software product To SCM Process supplier: To acquirer/operator/user:
supplier
requests SCM Process supplies software product
receives result of SCM activities and tasks receives requirements for [tailoring] SCM
Process
SCM Process supplier To subcontractor or vendor: To software product supplier:
requests subcontractor work or tool receives request for SCM Process
receives subcontractor work or tool supplies SCM results to software product
subcontractor or To lower-level subcontractor: To SCM Process supplier:
vendor
may request work or tool [and so ad receives request for subcontractor work or
infinitum] tool
supplies subcontractor work or tool
acquirer Su pplier o f softw are p rodu ct
Escro w
O peration M aintenance D evelopm ent
process process
process
Interface
Escro w
Supplier
control
of S C M
P rocess
Legend:
R elationship as:
S upplier of S C M
ReRela tionrela ti
A cquirer of S CM
Subcon tractor
O ptional R elation sh ip
custom er,
or tool vendor
Figure 1 — Role relationship between Supplier of SCM Process and other parties.
vi
©
TECHNICAL REPORT  ISO/IEC ISO/IEC TR 15846:1998(E)
Information technology — Software life cycle processes — Configuration
Management
1 Scope
This Technical Report establishes the requirements for performance of the configuration management of computer software for
development, maintenance and operations. This Technical Report is based on the Configuration Management (CM) Process of
ISO/IEC 12207 (hereafter referred to as the Software Configuration Management (SCM) Process).
This Technical Report is applicable to:
— any software in any form;
— the entire software product life cycle and to individual development, maintenance and operations projects within that life
cycle; software acquired from a subcontractor or vendor;
— the supplier and the acquirer of the software product.
This Technical Report is applicable for use in a two-party situation and may be equally applied where the two parties are from
the same organisation. The situation may range from an informal agreement to a formal contract. This Technical Report may be
used by a single party as self-imposed tasks, or be applied to off-the-shelf products.
1.1 Tailoring this Technical Report
Some software products and software life cycles may require requirements set forth in other applicable standards, contracts or
to accommodate local practices. The SCM Process may be tailored by adding requirements.
The SCM Process may also be tailored to omit requirements of this Technical Report where specific requirements are identified
as not applicable. Tailoring of this Technical Report in accordance with tailoring of ISO/IEC 12207 may be assisted by the
mapping provided in this Technical Report (see annex A).
1.2 Process roles
The users of this Technical Report take the acquirer and supplier roles (see Figure1).
The supplier of the software product performing the Maintenance and Development Processes defined in ISO/IEC 12207 is the
acquirer of SCM.
For the Operation Process, after acceptance of the software product, the acquirer may take the role of supplier of SCM to the
final client or consumer.
The supplier of the SCM Process (hereafter referred to as “the SCM Process”) may take the role of acquirer of subcontracted or
vendor work.
2 Conformance
Not applicable.
3 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this
Technical Report. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.
©
However, parties to agreements based on this Technical Report are encouraged to investigate the possibility of applying the
most recent editions of the normative references indicated below. Members of ISO and IEC maintain registers of currently
valid Technical Reports.
ISO/IEC 12207:1995, Information technology — Software life cycle processes.
ISO/IEC 2382-20:1990, Information technology — Vocabulary — Part 20: System development.
ISO/IEC 2382-1:1993, Information technology — Vocabulary, Part 1: Fundamental terms.
Informative references are listed in annex B.
4 Definitions
For the purposes of this Technical Report, the definitions given in ISO/IEC 12207 and the following definitions apply.
4.1
approved modification
the disposition of one or more proposed changes authorising change to any SCIs
NOTE There may be a many-to-many relationship of "proposed change" to "approved modification". A proposed change may cause
modifications in several SCIs (even if only to the code and its test case). A modification may originate from several proposed changes,
approved simultaneously or over a period of time while the modification is still in progress.
4.2
change authority
as “configuration board” in ISO 10007
NOTE Disposition is made by a designated change authority traditionally given the name "Change/Configuration Control Board". This
authority may approve a proposed change, thus converting it to an approved modification, or may disapprove a proposed change, or may
defer a decision.
4.3
proposed change
a report of anomaly, required or recommended enhancement from the time an idea is recorded until the disposition by a
designated change authority
NOTES
1 The disposition may be to reject, to defer for further analysis, or to accept. Upon acceptance the proposed change becomes an approved
modification.
2 There may be a one-to-one, one-to-many, or many-to-many relationship between proposed changes and approved modifications.
4.4
Software Configuration Management (SCM)
the process of applying configuration management (see ISO 10007) throughout the software life cycle to ensure the
completeness and correctness of SCIs
4.5
software library
a controlled collection of SCIs to aid in development, operation and maintenance
4.6
software tool
a software product providing automatic support for software life-cycle tasks
NOTE Software tools include vendor software and in-house developed tools, whether supported by their creator or not. Tools include
software run by the operating system and the operating system itself. Tools also include interpreted programs, such as macros, test scripts,
or build instructions.
©
ISO/IEC ISO/IEC TR 15846:1998(E)
5 Symbols (and abbreviated terms)
5.1 Abbreviations and acronyms
The following abbreviations and acronyms appear within the text of this Technical Report:
CI Configuration Item
CM Configuration Management
SCI Software Configuration Item
SCM Software Configuration Management.
6 SCM Process Implementation
ISO/IEC 12207: 1995
6.2.1 Process implementation. This activity consists of the following task:
6.2.1.1
A configuration management plan shall be developed. The plan shall describe: the configuration management
activities; procedures and schedule for performing these activities; the organization(s) responsible for performing activities;
and their relationship with other organizations, such as software development or maintenance. The plan shall be documented
and implemented.
Note  The plan may be a part of the system configuration management plan.
The SCM Process is implemented to cover the entire, or any specific subset of, the software life cycle for an Operation,
Maintenance or Development Process.
6.1 Initiating and defining the scope
6.1.1 Defining the inputs to the SCM Process
The SCM Process shall obtain the SCM requirements as input and ensure the SCM requirements are complete and
understandable. These SCM requirements shall include:
• software products to be part of the SCM Process;
• evidence or assurance the SCM Process is carried as stated in a SCM Plan;
• software environment of the SCM Process.
Where the software product contains acquired, customer supplied, subcontracted, or vendor SCIs, the SCM Process shall
identify, control changes to, account for the status of, and perform configuration evaluation (also known as “configu
...