16.2 Coding

Coding typically produces single configuration items, but it may be a good idea to define deliveries for modules. This implies defining a corresponding module delivery for each source code module, consisting of source code, associated header files and include files, and tools. Alternatively, a module delivery may consist of the compiled item (.obj file), but not all configuration management tools can handle compiled items. As a further alternative, the tool could indicate what belongs to a piece of source code, so it can be included in the delivery.

Unique Identification

The unique identification of source code and related items may be built up this way: PPPP NNNNNN.TTT n.n. Table 16-2 describes each of these elements.

Table 16-2. Unique Identification for Coding Items

Element	Function
PPPP	The project or product to which the configuration item belongs.
NNNNNN	Item name . It must be defined in terms of a maximum number of characters , depending on the platform(s) used (e.g., 20 alphanumeric characters at most). Names must be descriptive of the items and, if the design contains a subsystem structure, must reflect the position of items within it. It's not a good idea to name the source codes after the players on the national football team, even if the system is an administration system for the local football club. It is a good idea to name related files in the same way, so that, for example, source code and the corresponding object file have the same name.
.TTT	Reference to the type, expressed by "." followed by a reference (e.g., "psc" for source code written in Pascal, or "obj" for compiled items).
n	Version designation, expressed by a running number.
.n	Revision designation, expressed by "." followed by a running number.

Authorization

It's important to define authorization for these configuration itemsthat is, describe who each item is produced by, under the responsibility of, and approved by. Configuration items produced in the coding activity will typically be produced by a single persona programmer or the like.

The responsibility for these configuration items normally rests with a person responsible for development, a group manager, or the project manager depending on the size of the project. It may be an advantage to include an impartial quality function for the final approval of these configuration items. Approval may be a peer approval, in which a colleague at the same level as the producer approves the item, or the approval may be performed by a person responsible for quality on the basis of test results or the like for the module.

Tracing

Source code or modules must be traced to detailed design. This will be a one-to-one tracing if the detailed design is broken down to the module level. Source code or modules may also be traced directly to the software requirements, to ensure that the producer has met them. This type of tracing is rare, but it can do wonders in helping the programmer understand what he or she is actually coding.

Storage

Source code and related items are often stored by means of a tool. Modules may be extracted for usage in connection with approval, such as for review or test. Moreover, it may be useful to be able to release items from coding for usage as support for other items to be tested , such as modules that function as stubs or drivers.

Change Control

The earlier source code is placed under configuration management, the easier the task of registering the events ought to be for the person having to do it, as more errors will presumably appear earlier than later. These early errors may be a source of valuable information on the design and coding processes.