SOFTWARE IN PRACTICE
A component of a system that is treated as a self contained unit for the purposes of identification and change control. All configuration items (CIs) are uniquely identified by CI registration codes and version numbers. A CI may be a primitive system building block (e.g. code module) or an aggregate of other CIs (e.g. a sub-system is an aggregate of software units).
Examples of Configuration Items
The figure depicts the configuration of an underground railway environmental control system. The system has a central operation control centre and many railway stations. Each station has:
For the purposes of example let's look at the configuration items identified for the remote terminal unit control software. The RTU has three components that are managed as self-contained units for the purposes of identification and change control:
These three components were identified as primitive level configuration items as they cannot be further decomposed and are managed as self-contained units. For example each logic file that is loaded into the RTU has a unique identifier and version number.
The RTU is an example of an aggregate configuration item. An RTU CI release is an aggregate of firmware, configuration and logic CIs. The station CI is another aggregate configuration item. A station CI release is an aggregate of the individual LCP, RTU and IBP CI releases.
Designating Configuration Items
The choice of aggregate and primitive level configuration items is driven by the way the development, operation and maintenance of a system is managed. For example the station CI was selected as a configuration control item because it is useful to have one revision identifier that indicates the configuration status of all control system components at that location. The revision level assigned to the station CI denotes the level of functionality available and the possible modes of communication with the operation control centre.
General guidelines for identifying configuration items are: