Latest posts by Glennan Carnie (see all)
- The Rule of Zero - January 15, 2015
- The Rule of The Big Four (and a half) – Move Semantics and Resource Management - January 1, 2015
- The Rule of The Big Three (and a half) – Resource Management in C++ - December 18, 2014
A Configuration Item (sometimes referred to as a Computer System Configuration Item, or CSCI) is an artefact (hardware and/or software) that has an end-user purpose – that is, it contributes, in some way, towards the attributes of a system or product, or the development processes followed to produce the system or product. A Configuration Item (CI) is an artefact that is treated as a self-contained unit for the purposes of identification and change control. For example:
- Design models
- Source code
- Make files
Configuration Item identification
Configuration identification is the process of identifying the attributes and procedures that define every aspect of a configuration item.
Configuration identification performs three distinct roles:
Uniquely identifying each Configuration Item.
CIs are the artefacts to be controlled under Configuration Management. Each CI must be uniquely identified by name, version (revision) and location (on the file system).
Establishing a change policy
The CI’s change policy defines how the artefact is revision controlled; and whether that control changes during the lifetime of the project.
Establishing a review policy
Ideally, every artefact should be reviewed. Configuration identification establishes how the artefact will be reviewed and when it will be reviewed.
Configuration Identification must be performed prior to establishing any revision control system. All CI attributes and policies must be recorded in the project’s CM plan.
Configuration lifecycles define how an artifact is checked into and out of the revision control system. The configuration lifecycle defines the ‘life’ of one particular change, as it applies to that artifact (c.f. Change Management, below). The lifecycle is typically shown as a state transition diagram.
For any real project of any complexity a number of lifecycles will be required. Also note, an artefact’s lifecycle may change through the lifetime of the project. This is defined by the artefact’s change policy.
Listed below are a number of common configuration lifecycles.
Archive artefacts are configuration items that are simply stored in the CM system. Archive artefacts are never modified once they exist. For example, the binary (download) file for a particular release.
Figure 8 – The Archive lifecycle
‘Basic CI’ lifecycle
The ‘Basic’ CI lifecycle (Figure 9) is for artefacts that must be archive and may be modified over time. For example, the Compiler used on the project may be updated over the course of the project’s lifetime.
Figure 9 – the Basic lifecycle
In addition, this lifecycle is used for artefacts that have not yet been released (see Release Management, below). Such items should be stored in the project’s RCS repository (for completeness) and should have their modification history recorded but these items do not need to be subject to stringent review or quality checks before being checked in.
‘Reviewed CI’ lifecycle
A ‘Reviewed’ Configuration Item must pass a review (peer or formal) before it can be checked back in (Figure 10). For example, a Requirements Specification.
This lifecycle is sometimes known as a Document lifecycle.
Figure 10 – The Reviewed CI (or Document) lifecycle
Any artefact that has been released from development, or originates from outside the development department should be subject to this lifecycle.
‘Software CI’ lifecycle
The Software CI lifecycle (Figure 11) is an extension to the ‘Reviewed CI’ lifecycle (above). In addition to being reviewed, a software CI should also pass Static Analysis testing; and pass Unit (component) tests; before being checked in.
Figure 11 – The software item lifecycle.
The Software CI lifecycle can be implemented in environments that demand very high software quality, for example safety-critical applications.
To get the most out of your Revision Control System each project artefact must be defined, with its usage, review policy and, perhaps most importantly, its change policy. This information gives the developer the information needed when an artefact has to change – what is required and who must be involved. Having effective configuration identification in place also ensures that the project’s artefacts retain their quality (at whatever level that quality is set)