GFG Microsystems Limited
IT Department
Information Technology Department
Configuration Management Standard
You will be notified if any standard is revised; it is your responsibility to obtain up-to-date personal copies of standards and to destroy old ones.
GFG IT UK-99-SO-2/0.01 4 of 45 12 December 1997
Configuration Management Standard GFG Microsystems Limited
Project Name Standards Number: SO
DOCUMENT DISTRIBUTION
Document IdentificationDocument Ref:
/ GFG IT UK-99-SO-2/0.01
/ Authors Ref:
/ s002o001.DOC
Author:
/ Date:
/ 12 December 1997
Dept/Section:
/ GFG IT Development
/ Version:
/ 0.01
Reason for Distribution
/ For Review
/ Status:
/ Draft
Reviewers / Department / Responsibilities / Comments Received
Distribution of Approved Version:
Issued By:
......
......
Copy No:
Issued To:
GFG IT UK-99-SO-2/0.01 4 of 45 12 December 1997
Configuration Management Standard GFG Microsystems Limited
Project Name Standards Number: SO
CONTENTS
1 INTRODUCTION 5
1.1 Purpose 5
1.2 Scope 5
1.3 Related Standards 5
1.4 Revision History 5
2 The Object and Document numbering system 7
2.1 Identifier 7
2.2 Country 7
2.3 Number issuing authority 7
2.4 Context 8
2.5 Object 9
2.6 Version 10
2.7 Permitted Abbreviations 10
3 File nAmes 12
3.1 File naming rules 12
3.2 Operating system assumptions 13
3.3 Construction of file names 13
4 The integration workbook 15
5 Configuration control 16
5.1 Object control forms 16
5.2 Use of software tools 18
5.3 Revision histories 21
5.4 Creation of new versions 21
6 Releases 22
6.1 The release form 23
6.2 Master disks 24
6.3 Nested releases 24
7 Change control 25
7.1 The change record form 25
7.2 The life cycle of change 27
8 Disk control 30
8.1 Disk numbers 30
8.2 Naming disks 30
8.3 Master disks 31
8.4 Exported disks 32
GFG IT UK-99-SO-2/0.01 4 of 45 12 December 1997
Configuration Management Standard GFG Microsystems Limited
Project Name Standards Number: SO
1 INTRODUCTION
1.1 Purpose
This standard defines a set of procedures which, when followed, ensure that GFG IT project activities conform to the British Standard for configuration management (BS 6488: 1984).
BS6488 does not itself define any detailed rules or procedures: it is in effect a requirements specification for a configuration management system.
1.2 Scope
All documents, software and other items may be controlled by the methods set out in this document.
The rules given are largely independent of the computer systems used to produce and maintain documentation and software, so the rules are in some cases fairly general. Where more specific rules need to be defined to cope with specific computer systems or software tools these are documented on a per-project basis.
A number of very different levels of activity are covered by this standard, including:
a) naming of disk files
b) use of software tools in constructing systems
c) problem and bug reporting
d) control of software releases ("configuration baselines")
e) control of changes to systems (or their specifications) requested by clients, together with the necessary project management procedures.
All these different levels are aspects of the control and management of change.
1.3 Related Standards
The reader should be familiar with the following documents that supplement the contents of this Standard.
[1] / GFG IT UK / SO / 1 / The Object and Document Numbering System[2] / GFG IT UK / SO / 15 / Commenting and layout checklist
[3] / 6488 : 1984 / BS / Configuration management of computer based systems.
1.4 Revision History
Version / Date / Author / Description / Sections Affected0.1 / 97/12/12 / GFG / First draft / All, diagrams and forms to be added
2 The Object and Document numbering system
The configuration management system is based on the GFG IT numbering system. The GFG IT numbering system is documented fully in GFG IT UK 99-SO-1, but the most relevant parts of the numbering system are also described here to make this standard more self-contained. (Be aware, however, that GFG IT UK 99-SO-1 is definitive in this area and takes precedence over this section.)
Anything can be assigned a GFG IT number which is recorded on the LIST form (GFG IT FO-2) for the project. A GFG IT number typically looks like:
Id country nia-context-object/version
where:
id is the identifier, which makes it clear to the reader of a document that the originator of the document is a GFG Microsystems Limited company: the id is GFG IT
the country, which identifies the national GFG IT organisation: the country is "UK"
the number issuing authority, which identifies the individual division or some other number issuing authority within the country
the context, which identifies the collection to which the object belongs
the object number, which identifies the object within its context
the version number, which identifies the particular version of the object being described.
2.1 Identifier
Every GFG IT number begins with the word “GFG IT" so that a document (or other object) bearing such a number may be easily identified by a client or other third party as emanating from GFG IT Development.
2.2 Country
This version of this standard is limited in scope to the UK, and the chosen country identification is "UK”.
2.3 Number issuing authority
A number issuing authority within GFG IT UK is authorised by procedures outside the scope of this standard. Each number issuing authority is assigned a two digit code, and this code is included in the GFG IT number, padded on the left with a leading zero if necessary.
The number issuing authority which is responsible for the GFG IT standards has the code 99 and all GFG IT UK standards are numbered accordingly.
2.4 Context
Every object which is within the scope of the GFG IT numbering system belongs to a context. Numbers allocated within one context are independent of numbers allocated within other contexts[1].
A context is the highest level of classification within a given number issuing authority and can be one of:
· category (see section 2.4.1 below
· project (see section 2.4.2 below)
Most of the objects that most GFG IT personnel deal with most of the time will be objects that belong to a particular project and have a project context.
2.4.1 Category
An item which is of general applicability, i.e. it does not relate to a particular client or project[2], is placed within a category
Examples: a category might be:
a) general standards
b) administrative documents relating to recruitment procedures
The name of each category is a letter followed by one or more digits.
All categories with the same initial letter form a group of categories that relate to a particular topic. Each number issuing authority maintains a list defining the allocation of letters to topics.
For each (non-empty) group of categories a form GFG IT UK 99-FO-4 (known as the CATEGORY form) contains the following information:
a) the letter defining the group of categories
b) the description of the group of categories
c) for each category in the group:
1) the category number in red ink (this is to ensure that a photocopy of the CATEGORY form is not accidentally used for allocating new numbers, which could otherwise lead to duplicate numbers)
2) the name or description of the category
Example: within the number issuing authority that controls the GFG IT standards the CATEGORY form for the S group of categories includes an entry stating that category SO contains general standards (and this category includes the document you are now reading).
2.4.2 Project
A project is a particular unit of work undertaken for a client, or, in the case of internal projects where there is no client, for GFG IT itself.
A client number is allocated by a number issuing authority and is a four digit numbers[3].
A project number consists of a client number followed by a dot(.) and then a project serial number. Project serial numbers start at 1 for each client and are allocated sequentially by the number issuing authority.
2.5 Object
An object is a document or item of software or hardware or anything else that needs to be properly identified and controlled.
An object may be an assembly of smaller parts. These smaller parts would normally also be objects.
The object number is allocated within each context by the person responsible for the context.
The object number 0 in each context is reserved and is always a form GFG IT UK 99-FO-2 ("the LIST form"). This form records the object numbers allocated within the context and contains the following information:
a) The identification of the context, i.e. the category, client number or project number.
b) A description of the context.
c) For each object number (from 1[4] upwards[5]):
1) The object number, written in red ink (this is to ensure that a photocopy of the LIST form is not accidentally used for allocating new numbers, which could otherwise lead to duplicate numbers).
2) The name or description of the object.
2.6 Version
Each object has a version number and an object will typically move through several versions during its life. The version number is in the form:
digit . digit digit
and the following rules apply:
a) the first version of the object is given an arbitrary version number: commonly this is 0.00 or 1.00
b) the latest version of an object must have a higher number than all previous versions[6]
c) when an object is changed in any way, no matter how small the change then the version number MUST be increased[7].
d) when a minor change is made to the object the version number is incremented, for example 0.03 to 0.04, 1.56 to 1.57.
e) when a major change is made to the object the version number is jumped up to the next highest number ending in 00, for example 0.03 to 1.00, 1.56 to 2.00.
f) should an object ever reach version number 9.99 and require further change a new object number must be allocated for subsequent versions.
The version number may optionally be specified as part of the GFG IT number of an object. When it is specified it is written after the object number and separated from it by a slash (/).
2.7 Permitted Abbreviations
This section describes permitted ways in which the full GFG IT number may be abbreviated in two contexts:
a) When it is required to refer to the latest version of an object rather than to a specific version the version number can be omitted.
b) When it is required to refer to another object which belongs to the same project as the document making the reference the client and project numbers can be omitted.
For example,
- if document GFG IT UK 11-1234.5-2711.00 refers to document GFG IT UK 11-1234.5-44, but does not need to specify a particular version of that document, then it may do so like this:
“... see GFG IT 44... “
- GFG IT 1234.5-46
means the latest version of object 46 in project 5 for client 1234.
- GFG IT 27/1.01
means version 1.01 of object 27 in the same project as the document which contains that reference.
3 File nAmes
Many objects are represented as computer files in some filing system. In order to keep proper control of the various files involved a formal file naming system must be followed.
File naming systems vary from computer to computer (see below) but all are based on encoding the GFG IT number for a particular version of an object in order to construct the name of the file containing that object.
3.1 File naming rules
Although file naming systems are machine dependent all systems must obey the following rule:
No two files anywhere in the system (in any directory on any disk on any computer at any time) may have the same name unless the contents of the files are identical.
This rule ensures that a file can be uniquely identified from its name without having to look at its contents (which in some cases might be difficult or impossible).
On some operating systems it is possible, and convenient, to have several files with the same basic filename but different extensions with these files containing the same information at different stages of processing, e.g. a compiler's input source file, its output binary file and its listing file. In such cases the following rule will always apply:
Several files may have the same base file name (and different extensions) only if one of the files completely defines the contents of all the others such that, given this source file, all the other files may be created from it by applying various software tools.[8]
The file name is that part of the complete path name for a file which is independent of the directory structure on the disk. Thus the rules ensure that a file can be copied to any directory on any disk on any machine and the copy can still be uniquely identified from its file name without having to know where it was originally copied from.
Any date information retained with a file (or its directory entry) by a particular operating system must not be regarded as part of the file name. In particular software tools that may exist under certain operating systems which purport to perform configuration management functions based on such dates must not be used in this way (with the possible exception of backup and archive systems).
There are limits to what identical means. For example, a file might contain a compiler listing: it is permissible to delete the listing file and recreate it later by recompiling exactly the same source files with exactly the same compiler options, in which case the recreated listing file may have the same name as the earlier copy. The contents of the files may however differ in that the header line on each page of the listing may contain a different compilation date.
3.2 Operating system assumptions
Strictly speaking the formal file naming system is machine-dependent, as it depends on:
a) the rules for constructing filenames on a particular operating system
b) any file naming conventions assumed or required by the software tools running on the machine.