16.3 Integration

All items one could place under configuration management for integration are deliveries. This will typically be "integration subsystems," "subsystems," and "the complete system." The size and composition of these configuration items depend on which types of single items one places under configuration management and the degree of granularity one prefers for the integration systems.

In this context, an "integration subsystem" means a subsystem that cannot be delivered as is but is used for integration test. It may consist of anything from just two pieces of source code with corresponding configuration items to almost a whole (sub)system, with all its configuration items. A "subsystem" or "complete system" is an assembly that can and may be delivered.

It's important to note that the composition of integration deliveries under configuration management is determined by the design. Finding out what such deliveries should consist of is not a configuration management task; the job is only to track the components once they've been defined. But in actual practice, the person who takes care of configuration management may be involved in audits of deliveries on behalf of the person responsible for quality. In any case, the audit task should not fall between two jobs.

Production Time

A configuration item from integration may consist of all relevant single types of configuration items. At release, the integration subsystem, subsystem, or complete system is produced when the relevant make-files and/or build scripts are executed. The configuration item may also be produced and placed under configuration management as a whole and released for usage on request. It may be practical to do this rather than placing all the items for producing a (sub)system under configuration management individually.

Unique Identification

The unique identification of integration subsystems, subsystems, and complete systems may be built up this way: PPPP NNNNNN n.n. Table 16-3 describes the function of each of these elements.

Table 16-3. Unique Identification for Integration Items

Element	Function
PPPP	The project or product to which the configuration item belongs.
NNNNNN	The name of the system. It must be defined in terms of a maximum number of characters of well-defined types (e.g., 20 alphanumeric characters at most). The names must be descriptive of the items.
n	Version designation, expressed as a running number.
.n	Revision designation, expressed by "." followed by a running number.

Tracing

(Sub)system configuration items should preferably be traced to both the detailed design and software requirements. This way, the subsystems inherit tracing from these items. Analyses of tracing must be performed on the complete system, to establish that all requirements have been met.

Storage

As described earlier, deliveries are rarely stored as one physical configuration item. But at least a reference to a given delivery must be stored, to provide an overview of the delivery's content and a description of how it's produced for release (when the constituent modules are to be integration tested). As with coding, it may be practical to release such items as support for other items to be integration tested , i.e. stubs or drivers.

It's not unusual for integration subsystems to be removed as configuration items when the complete system has been delivered. This may be sensible for reasons of space but unwise if retesting or regression testing will need to be done. What is most suitable in the given situation must be thoroughly considered . The complete system is released for usage for the first time when it's to be system tested or acceptance tested.

Change Control

As the configuration items that are handled in this development activity are deliveries, they are changed when their components are changed. For this reason it's important, when preparing change requests for source code, to include the relevant change requests for (sub)systems. At this point, the fanning effect should be noticed: an event registration may produce a number of change requests for source code and the like, whereas all this may create only one change request for the affected (sub)system. It's therefore important for the configuration control board to have the necessary overview and/or access to status reports that provide the overview.