7.4 Metadata for Relations to Other Configuration Items

Practically all configuration items have one or more relations to other items. These relations will typically be described by the data elements shown in Figure 7-4. There may also be relations to items that are not configuration items. In these cases, registration may become more difficult, especially if these items do not have a unique identification. This must be taken into account when considering which items to place under configuration management and how items not placed under configuration management should be treated.

Figure 7-4. Metadata for Relations to Other Configuration Items

Traces To (and From!)

Information carried in the traces to a configuration item provides the reason for the item's being the item it is, such as its wording, shape, or design. Tracing refers to items from preceding activities in the development, on which the configuration item is based. Often, the project plan will indicate which configuration items must be traced to each other. Tracing may, for example, be carried out in accordance with the V-model:

• Software requirements are traced to user requirements.

• Acceptance test specifications are traced to user requirements.

• Architectural design is traced to software requirements.

• System test specifications are traced to software requirements.

• Detailed design is traced to architectural design and software requirements. and so on . . .

This is only a minor extract of all the tracing possibilities a product may hold. In principle, it must be possible to trace all configuration items to preceding configuration items. However, the first configuration item produced cannot be traced to anything. Figure 7-5 illustrates the tracing between a requirement specification document and a system test specification.

Figure 7-5. Example of Tracing

Tracing Registration

Tracing is often a many-to-many relation. The prerequisite for being able to trace is that configuration items have a unique identification that does not change, is easy to reference (short and simple), and is accessible (visible and easy to copy for the person producing the tracing information).

Tracing must be registered in a way that makes it possible to report tracing in both directions. This means that it should be possible to find out which test cases a specific software requirement is traced to and which software requirements a specific test case is traced to. It should also be possible to find out which software requirements do not have traces to at least one test case, and vice versa.

A new version of a configuration item will typically inherit the traces of the previous version. This tracing should be controlled, so that the tracing is maintained and remains correct for all versions.

Importance of Tracing

Tracing is a part of registration that is often neglected, because it's regarded as a big and almost impossible task. This might be the case, and it may be especially difficult to introduce tracing in the middle of a project. However, it is often possible to undertake some kind of reverse engineering to procure trace information for already completed configuration items.

Tracing is immensely important for the people who produce configuration items and especially for those who change them. The quality will improve when people understand the relations between the items within a systemthe purpose and historical background of a given configuration item.

Moreover, tracing may reveal if something has been forgotten, or if gold plating has been done (something incorporated without anything to substantiate it). This is a way to keep costs in check. If nothing else, requirements should at least be traced to implementation and test- related configuration items.

Tracing may also be used to double-check the design. If one requirement traces to a large number of design items, it may be a sign of a design that is too complex and needs going over again.

Produced With

"Produced with" is a statement of which tool has been used in the production of the configuration item, so that the same tool may be used for future changes. It's not always considered necessary to place tools under configuration management or to register which tool a given configuration item is produced with. For delivery configuration items, it may be convenient to express what has been used (e.g., a make-file) to assemble the configuration item for release to usage. In this way, the "made with" information may be combined with the "consists of" information.

Derived From

"Derived from" expresses the history of the configuration item. As a rule, the history is seen partly in the inheritance of parts of the unique identification and partly in the change of version designation according to given conventions. "Derived from" must be expressed only if the name has been changed from one version to the next .

Consists Of

Only composite configuration items (deliveries) consist of other configuration items. A code module does not consist of other configuration items, but a software requirement release may consist of a project plan, user requirement specification, software requirement specification, and system test plan.

The most practical thing is to express which configuration items a given item consists of rather than which ones it belongs to. This will normally make it easier to assemble a composite configuration item for release to usage. The items a delivery configuration item consists of should be expressed precisely, so status can be taken into consideration when assembling the item, rather than just assembling it with the latest available version.

Information under "Consists of" will often be inherited from another version of a configuration item, and here it's important to note that the composition may change from one version to another. Items may have been eliminated from one delivery version to the next. Consequently, these items must also be eliminated from the information under "Consists of."