15.1 Milestones

Milestone deliveries are important. They must be planned in good time and must always be placed under configuration management. As the name implies, they are always deliveriesconfiguration items composed of other configuration items, which may be either single items or other deliveries.

Milestone deliveries often become more and more comprehensive throughout the development process, because they should always consist of the preceding milestone delivery (in new versions, if necessary) as well with the new delivery from the concluded delivery. However, milestone deliveries need not develop this way; this will happen mainly where configuration management is performed with a fairly high degree of formalism. Table 15-1 shows the possible development in milestone deliveries.

Identification

A delivery must be identified just like any other configuration item. The unique identification of milestone deliveries may be built up this way: PPPP MMM.nn. Table 15-2 describes the function of each element.

Table 15-1. Development in Milestone Deliveries

	Milestone
Included Configuration Item	Closing of Requirements	Closing of Architectural Design	Closing of Detailed Design	Closing of Module Test	Closing of System Test	Final Acceptance of System Test
Project plan	1.0	2.0	3.0	4.0	4.1	4.1
Configuration management plan	1.0	2.0	3.0	4.0	4.0	4.0
Test plan and test specification	1.0	2.0	3.0	4.5	5.2	6.3
Requirement specification	1.0	1.2	1.3	1.4	1.6	1.6
Architectural design		1.0	1.2	1.3	1.3	1.3
Detailed design			1.0	1.1	1.2	1.3
User manual				1.0	1.1	1.1
Subsystem 1				1.0	1.1	1.2
Subsystem 2				1.0	1.1	1.2
Compiler				4.3	4.3	4.3
Linker				7.2.5	7.2.5	7.2.6
Complete system					1.0	1.1
Release note						1.0

Table 15-2. Unique Identification of Milestone Deliveries

Element	Function
PPPP	The project or product to which the configuration item belongs (e.g., PCM for Professional Configuration Management)
MMM	Milestone designation (e.g., "CURS" for "Closing of User Requirement Specification"). For further inspiration, see the headings in Table 15-1.
.nn	Version designation, expressed by "." followed by running number (two digits).

It's important to define authorization for milestone deliveries: whom each delivery is produced by, under the responsibility of, and approved by. Often, the producer will be responsible for development or the like, while final responsibility should rest with the project manager. It may be an advantage to include an impartial quality function to carry out auditing and general approval of milestone deliveries, such as by checking that all components are present in the correct versions and approved. Milestone deliveries can be traced to a project or development plan in which the milestones have been planned.

Generic Content Lists

The components of a milestone delivery must be identified correctly and precisely, taking the entire unique identification into account. It may be a good idea to keep a generic list of the componentsfor example, to have a list showing that the contents of the generic delivery "Printer driver" are the generic configuration items "Print card," "PLD," "EPROM," and so on. But when a specific delivery is made, both the delivery itself and all components must be explicitly identified, using the correct and complete unique identification.

Where deliveries are defined like this from generic lists or inherit their contents from earlier versions, it's important that they not contain components that are no longer relevant. This means that stray items must be recognized and removed from the identification of deliveries.

Storage

An individual configuration item is physically placed in storage and has associated metadata. A delivery will also have associated metadata but will not necessarily be present as a physical item in its own right. Part of the metadata for a delivery is a list of the components. This refers to physical configuration itemsat least eventually, when the entire hierarchy has been resolved. Furthermore metadata points out how the delivery is to be assembled , typically by referring to a make-file or packing list.

Where a delivery doesn't exist in physical form, it will be constructed at the time of release. This will take place according to the production description. To give an example, it may be the release of a software product, where the source code, tools, and build script are stored in the configuration management library. The delivery consists of an executable file produced at the time of release and not kept in storage.

It may be necessary to place a proxy item in the configuration management library, especially if metadata are maintained together with the items and the tool used for the library requires items to handle the metadata. Typically, a proxy item is an ASCII file with a text like "I am a representative of hardware item XYZ, which is physically to be found at xxx." This provides registration without the need to place tools, for example, under configuration management. Proxy items and their metadata must be included in status reports and the like for the physical item.

A delivery may be assembled in a physical item, such as an apparatus with embedded software. A list of components should still accompany such an item. A delivery may be a mixture of the above two casesconsisting of both a physical item and references to configuration items that are already present. An example could be an apparatus with an electronic user manual under configuration management.

Change Control

Typically, a milestone delivery will be definitively defined shortly before the final review associated with it, such as the closing of design activity. The person who is to approve the activity (typically the customer or a general product manager) will receive the delivery for approval. At this stage, events may occur that require changes in one or more components before approval. This means that a milestone delivery often does not change at all, or just a little, in connection with final approval. However, change control must be carried out for milestone deliveries.

Actually, events are registered for deliveries more often than for individual configuration items. For these items, the configuration control board will often consist of people on a relatively high level in the organization.

During analysis of an event registration, change requests will be produced for relevant items, which are subsequently changed for the delivery to be released in a new, changed version composed of the new, changed versions of some or all of the components. An example could be an error in a delivery A , v.1.2. Analysis identifies an error in building block 4, v.3.5. This is corrected, and building block 4 is released in v.3.6. Delivery A is subsequently released in v.1.3. If building block 4 is part of other deliveries, this is a multivariant situation.

Changing components in a milestone delivery after approval of the milestone should not affect earlier deliveries. They must function as fixed snapshots that must not be changed retroactively. New versions of components will become part of future milestone deliveries. The processing speed for events and changes should be high for milestone deliveries, to facilitate progress.

Status Reporting

A report template should be available that can produce reports listing metadata for the components of milestone deliveries, together with, naturally, metadata for the milestone delivery itself. The degree of detail for such reports should be considered , as milestone deliveries often consist of deliveries in several layers .