The purpose of the identification activity area is to determine the metadata for a configuration itemto uniquely identify it and specify its relations to the outside world and other configuration items.
Identification is one of the cornerstones of configuration management, as it's impossible to control something whose identity you don't know. If the tables in a restaurant have no numbers to which orders can be traced, the waiter will have difficulty matching the dishes to the proper guests. Perhaps this will come off all right if you have three or four tables, but definitely not if you have more than 20 and the guests keep coming and going all evening and the waiter who serves the food is not the one who received the order. To be sure everything is under control, the waiters and orders need to be uniquely identified as well. Figure 14 shows how identification is influenced by its surroundings.
Figure 14 Identification in Context
Two incidents may initiate the identification process:
The first time an item is to be placed under configuration management, identification starts with a need defined in the plans. From the project plan, you know an item has to be produced (for instance, a design or a code module), and from the configuration management plan, you know this item must be placed under configuration management.
When you have to change a configuration item, identification will start with a change request. In this case, Change Control has decided that a new version of the configuration item must be produced, (for example, the requirement specification document must be changed in light of a review), and subsequently this new version must be placed under configuration management.
Identification results in the registration of metadata for a configuration item.
Methods, conventions, and procedures necessary for the activities in identification may be
Procedure(s) for registration of metadata, including procedure(s) for tracing
Procedure(s) for inheritance of metadata
Convention(s) for unique identification
Convention(s) for authorization, including restrictions on distribution, if any
Convention(s) for identification of components in a delivery
Each organization must define its own conventions for unique identification. One general convention most often is not enough; typically, a number of conventions are necessary for various classes of configuration items, such as documents and code.
These conventions may be difficult to define. You have to consider what purpose the unique identification serves and how to implement it in the easiest way. It will connect the registration and the physical configuration item in such a way that it's always possible to find the configuration item. This should be considered when defining conventions for unique identification. Furthermore, the procedures are tool dependent and often highly predefined in the tools available.
The file name under which the item is saved may constitute the unique identification. It should also be possible to write the unique identification on the configuration item's mediumfor instance, on a diskette label. The unique identification also registers the relations between configuration items, such as variations or parts of each other. It may be a good idea to consider making identification a key in a database registration.
It's important to define the conventions for unique identification so that the formation of new configuration items will not make it necessary to change or delete existing configuration items. For instance, the number of digits in a number must be sufficient to cover the total number of configuration items; it's not appropriate to have only two digits if more than a hundred items may be produced.
The document identifier in Figure 15 contains
Project and year: SC.91 Document number: 009 Author and affiliation: OA.ect Activity identifier: T2.3.1 Document type: RP (Report) Version: 02
Figure 15 Document Front Page
The test cases in Figure 16 are included in a test specification document, and the identification contains (for the first test case)
The current section number in the document: 10.3.1.6 Running unique number: 80 Version of test case: 1.A
Figure 16 Test Cases
Authorization information may be derived from a quality assurance plan and a development plan. It's an advantage to have general directions for authorization in such plans, such as descriptions of the kinds of people who are responsible for acceptance and production of various types of configuration items.
Perhaps documents placed under configuration management in the form of a draft could be approved by the author himself, while documents placed under configuration management in a version to be used by everybody should be approved by a group consisting of the project manager, the person responsible for quality assurance, and a customer representative.
Often the person who produces an item is also in charge of its identification. Identification is based partly on conventions for individual data elements and partly on information available from various plans (for instance, general procedures determining who is in charge of the approval of a particular kind of document). It may be necessary to draw on a library tool, for example, if numbers that are part of the unique identification are generated automatically and/or reserved in a storage tool.
Connection with Other Activities
An item cannot be declared as being under full configuration management until it has been placed in controlled storage. It is not sufficient that the item be identified. Identification, production, and placement in storage often overlap or are carried out interchangeably.
Sometimes the identification, or parts of it, is carried out before the item is produced, such as when the decision is made about its production. In other cases, it may be carried out in connection with placing the item in storage (for instance, when a tool increases a counter).