BS 6488:1984 download.Confiquration management of computer-based systems.
1. Scope
BS 6488 gives recommendations for the establishment of configuration management procedures for computer-based systems. It will enable organizations to develop and apply procedures that will:
(a) identify the configuration current at any time;
(b) identify different configurations that can run the same system or associated group of systems;
(C) control changes to systems:
(d) trace a configuration and the changes made to it through periods of time.
BS 6488 assumes that systems will be;
(1) documented in accordance with BS 5515;
(2) tested in accordance with BS 5887.
BS 6488 also assumes that. in service:
(i) documentation will be maintained;
(ii) systems will be subjected to performance monitoring in accordance with BS 6238.
NOTE. The titles of the publications referred to in this stendrd are listed on the inside back cover.
2. Definitions
For the purposes of BS 6488, the following definitions apply.
2.1 configuration management. The discipline of identifying the components of a continuously evolving system (taking into account relevant system interfaces) for the purposes of controlling changes to these components and maintaining integrity and traceability throughout the system life cycle.
2.2 configuration. The totality and the inter-relationship of the hardware, software, firmware, services and supplies required for the successful operation of a computer-based system or associated group of systems at a given reference point in time.
2.3 system life cycle. The system life span commencing with the system requirement specification and continuing after the system has been discontinued and until the documentation describing it has been destroyed.
2.4 configuration baseline. A specific reference point of system definition to which changes or proposed changes may be related.
2.5 configuration item. An entity within a configuration that satisfies an end use function and that can be uniquely identifed at a given reference point.
2.6 configuration status accounting. The recording of all configuration item descriptions together with the status of
proposed changes to the system and the implementation state of proposed changes.
3. System configurations
Individual systems or groups of systems may comprise combinations of wide ranges of hardware (including communications facilities), services, operational and support software, applications software, data bases and both operational and archival files. The configurations to be managed can therefore be extensive.
4. System life cycles
The configuration management procedures should recognize and accommodate the life cycles of the systems to which they are applied. The life cycle of a system will normally be as defined in 2.3. Within these limits, however, the stages through which individual systems pass in their life cycles, particularly development stages, may not all be identical. The numbers of stages will be determined by the size and complexity of the respective systems and should be identified when the requirement specification is produced.
5. Reference points
During the project development stages of a system, the reference points at which the configuration is identified should relate, usually directly, to the stages specified by the project management system applicable to that project. Because an organization’s projects may vary in size and complexity, the respective project management systems may not all specify the same stages. In order to ensure compatible configuration management of any interacting or interfacing systems, which may be under development at the same time, the following key project stages should always be included:
(a) requirement specification;
(b) system description;
(c) system test:
(d) handover.
During the in-service life of a system, turther reference points should be established whenever events occur that affect the system and the configuration should be updated for each event. Typical events include:
(1) major enhancements of operational systems;
(2) upgrading of hardware;
(3) introduction of new versions of operational or support software;
(4) implementation of new systems which will share resources (e.g. hardware) with existing systems, whether or not directly interfaced.
6. Configuration baselines
The configuration identified at a reference point is normally recognized as the configuration baseline at that point. All changes that are proposed to a system between that reference point and the next should be the subject of configuration control procedures. Individual changes introduced through these procedures should be recorded as a series of updates to the configuration and, collectively, should be assimilated into a new configuration baseline at the next reference point.
7. Configuration item
The identification of what constitutes a configuration item in a given system design stage can be critical to the effective configuration management of that system. The definition given in 2.5 should be applied so that when an aggregation of configuration items is presented as being the configuration at a particular reference point, it accurately represents that configuration without omissions or extraneous items. It is also essential that each configuration item should carry its own unique identity.
It is important that the description of a configuration item should include:
(a) the unique identification of the item;
(b) the item type, e.g. (for software) master, archive, security, source, object, working copy and the manner of its derivation, e.g. date of its generation, name and version of the tools used;
(c) for software, the nature and identity of its machine- readable form;
(d) ‘used on’ references wherever these are significant. It is also necessary to recognize, as configuration items, those items included in the test plan, test specification and test summary described in clauses 7,8 and 9 of BS 5887:
1980.
It is recommended that each configuration item should be made subject to configuration control as soon as but not before it is fully defined and uniquely identified (see also clause 8).
8. Configuration control
All introductions or changes to a system configuration should be controlled by a procedure that:
(a) requires documentation to be produced that:
(1) specifies the nature of the change;
(2) identifies all configuration items involved;
(3) uniquely identifies any new configuration items;
(4) identifies the effects of the change on other configuration items;
(5) identifies the effects of the change on system performance;
(6) evaluates the merits of the change in order to justify the expenditure of time and resources;
(b) specifies the level of authority for approving or rejecting the change;
NOTE. It may be necessary to identify different levels of authority for défferent kinds of change.
(c) communicates the details of the change and its approval or rejection to all who need to know:
(d) ensures that all relevant configuration management documentation is updated and cross-referenced;
proposed changes and the implementation state of approved changes. It provides the means by which the history of the system life cycle can be traced and includes the recording and reporting of:
(a) the dates when baselines and changes from the baselines were established;
(b) the date when each configuration item was brought under configuration control;
Cc) the current issue or change status;
Cd) the status of proposed changes;
Ce) deficiencies identif led by a configuration audit
(see clause 13).
Configuration status accounting records should provide the means by which the master configuration index relating to any reference point or baseline can be reconstructed. It therefore follows that the means by which configuration status accounting records are kept and the master configuration index is maintained should be compatible. whether manual or machine methods are chosen.
13. Configuration audit
Configuration management should be subject to the same standards of quality assurance as other systems and operations management functions. Because of the potentially serious effects that configuration management failures could have on the integrity of the organization’s computer- based systems, audits should ensure that:
(a) configuration management responsibilities are clearly defined and accepted;
(b) configuration management procedures are clear and comprehensive and meet the criteria set out in BS 6488.
Detailed audits should check, in particular, the:
(1) validity of the hierarchical development of the configuration through successive reference points;
(2) functioning of the configuration control procedures; (3) uniqueness of configuration item identities;
(4) traceability of configuration items to their documentary representations and vice versa;
(5) validity of records of associations, dependencies and interlaces;
(6) compatibility of copies of the master configuration index;
(7) functioning of the organization’s documentation library control system.
14. Design reviews
Configuration management can beneficially assist in the conduct of design reviews by providing such valuable information as:
(a) the identity of the configuration at each reference point;
(b) the changes proposed, approved and rejected between each reference point;
(c) the status of each configuration item;
(d) the status of the documentation at the review date.