7.2 Metadata for Unique Identification

Every configuration item must have a unique identification, which may be made up of one or more of the data elements shown in Figure 7-2.

Figure 7-2. Metadata for Unique Identification

Belongs To

"Belongs to" is an indication of the overall affiliation of the configuration item. A configuration item will typically belong to a product. In some cases, configuration items may belong to several products jointly, such as in component development. In these cases, the affiliation must indicate that the configuration item belongs to a component assortment.

Name

The name of a configuration item may be built up in many ways. Typically, it will be some combination of text, type, and running number, written together or separated according to given conventions. Table 7-1 describes each of these parts .

Table 7-1. Configuration Item Name Parts and Their Functions

Part	Function
Text	The text may be a mnemonic or an acronym describing where the configuration item belongs and its function. For code objects, the text will typically function as part of the unique identification, consisting of the general component with a short indication of the purpose of the code object (e.g., CUS_ADD for a code object involved in handling customers' addresses).
Type	The type indicates the product type of the configuration item. Type descriptions may be set at a general level such as DOC for documents or COD for code objects. Type descriptions may also refer to a more detailed level, such as PMP for "Project Management Plan" or PSC for code objects written in Pascal. It's particularly important to specify the type if this is the only difference between configuration items. This will be the case if, for example, two otherwise identical documents are written in Word and WordPerfect.
Running number	The running number distinguishes between configuration items of the same type. This is not the version number for a configuration item but individual numbers . Technical notes might, for example, be identified as TN_nnnn, where TN_ is the type description and nnnn is the running number.

Version

The version expresses the historical development of a configuration item. Version information might be the only way to distinguish between two configuration items, because each version is regarded as a separate configuration item. When a new configuration item is developed on the basis of an item already in existence, all other parts of the unique identification will often be inherited.

Information on version may contain several strata, depending on the degree of detail one wishes to maintain. Moreover, there are many ways to designate and express information on the strata.

To give an everyday example: for books, one would normally mention edition and issue. Presently, I am reading a book with the specification "1st edition, 5th issue." In this case, the information on version is a description in two strata, separated by a comma. For the tool used in writing the present book, the information on version is expressed as version 2.30.07.DK. This is a description in four strata, separated by periods: the first stratum consists of one number, the next two consist of two two-digit numbers, and the last is a two-letter designation (or so it appears).

Status

Status expresses the present state of the configuration item. It might be necessary to make status part of the item's identification if items are brought under configuration management before everybody can rely on them or if identification is undertaken before the item is brought under configuration management.

Status may enter into the version designationfor example, "dA" for draft A of a document, corresponding to the status "under quality assurance." Similarly, with other types of configuration items, one might use version numbers with decimals for those only the producer can use (typically a piece of source code), while version numbers without decimals may designate items everybody can use.

It's the decision of the individual organization when an item should be identified and when it should be brought under configuration management, and, accordingly , how status conventions are to be defined. Examples of status codes can be seen in Table 7-2.

Date

Date means version date. This expresses when the configuration item has been created. In most cases, registration of the version date cannot be undertaken until the configuration item is placed in storage.

Storage Location

Storage location tells where the configuration item is to be found physically. This will make it easier to find the item. Storage location may be implicitly specified somewhere else, such as a general directory structure on a server described in the configuration management plan for all items of a certain type. Storage location will then be expressed in the complete path and file name of electronic configuration items in which the unique identification mayto some extent or whollyform part.

Storage location can also be indirectly specified, as part of the name. This may have the form of a classification, as is the case with public library books. Storage place may also be of a physical nature: a shelf in a cupboard in a room in a . . . , and so on.

Storage Medium

The same considerations apply as described for storage location.

Example of States for a Document

Some examples of typical states for a document:

• Under preparation: identification has been undertaken, but the item is not yet under configuration managementit cannot be used by anybody else but the producer, and events are not registered (version control).

• Under quality assurance: the item is under configuration management but can be used only for quality assurance activities (e.g., review). Events are registered.

• Approved: the item has been approved via relevant quality assurance activities and may be used by everybody. Events are registered.

Example of States for a Source Code Unit, Including in Build

Table 7-2 shows an example of states for a source code unit during its development. The status codes are described in the following paragraphs. Table 7-2 also includes a description of who is responsible for the unit at any given timethe authority needed to progress a unit or a build though the life cycle.

Table 7-2. Source Code Unit State Examples

Activity/State	Unit Status	Responsible
Development, ongoing	Busy	Developer
Development, pausing	Saved	Developer
Unit CI in "useful" state	Proposed	Developer
Unit undergoing formal unit test	Proposed	Approver signature
Formal unit test ready for approval	Proposed	Developer
Formal unit test is approved	Proposed	Approver signature
Formal unit release established	Published	Configuration management
Build undergoing formal integration	Proposed	Integrator
Formal integration test is ready for approval	Proposed	Integrator
Formal integration test is approved	Proposed	Test manager signature
Formal build release established	Published	Configuration management

The statuses a unit may have are

Busy. Ensures version control, so no one else inadvertently starts to modify the same source file.

Saved. Shows that the version is private to the developer.

Proposed. Shows that the version is in a state useful to other developers. Only versions with status "proposed" (or higher) may be used in official unit tests.

Published. Shows that the version has been unit- tested and that the unit test has been formally approved.

Accessed. Shows that the version has taken part in an officially approved integration test.

Frozen. Shows that the version has been part of an official release.