23.5 Configuration Management Plan: Activities

This chapter describes, in fairly high-level terms, how to identify items and place them in storage, along with how to perform change control and status reporting. This chapter typically contains the following sections:

1. Identification

2. Storage

3. Change Control

4. Status Reporting

This chapter may contain references to an appendix with detailed descriptions of tools, techniques, and methods .

Identification

This section plans and describes naming conventions for configuration items and the rest of the configuration management data (metadata). Detailed techniques are found in an appendix or may be included here, if they don't take up too much space. For all deliveries of systems and subsystems, this section describes

• The name of the delivery

• The contents: which software, what tools, and possibly which documentation, event registration, and so on, are connected to it. Where applicable , distinguish between new developments and reused software.

• The external interfaces of the systems, if any

• Necessary reviews and approvals

• Effort needed from each role to establish the delivery

• Tracing to the project plan or design documentation for the delivery, as applicable

Note that most of the abovementioned topics are part of the metadata for a delivery. When planning, some of this information is typically unknown, such as module names . In this case, describe how and when this information will be provided. A description of how the information is stored may also be included, but this may also be placed in the section on status reporting.

Storage

This section describes how the controlled library is built and deployed, possibly along with other libraries (even if they're not strictly part of configuration management as such). Detailed procedures can go in an appendix about tools, techniques, and methods. To give an example, a company may use Visual Source Safe for storage of code, while corresponding documentation is stored in a fixed directory structure and the relationships between documents and code are described in a database. Here, the controlled library consists of a combination of three tools. This section should therefore include a short, stepwise description of how items are correctly placed in storage and extracted, using the three tools in a suitable sequence.

This section may describe how information is collected, but this information may also be placed in the section about status reporting. To ensure that necessary information is available while avoiding an overflow of data, consider how long to keep information. Some may be obsolete after a certain point, while others must be kept for a long timeeven if just one customer is still using the system.

Finally, this section may describe how to perform backup of the libraries and other information. This is not, strictly speaking, a configuration management activity, but it's in the interest of configuration management to ensure that backups are made, are kept in a safe place (e.g., a fireproof box), and can be restored correctly.

Change Control

This section must define who has authority to request changes to a configuration itemwho are members of the configuration control boards for the various object types. A board may consist of just the author or producer of an object and possibly some peers. Also plan and document a board's delegation of authority.

Determine how event registrations and change requests for various types of objects are to be handled: are fixed forms needed or are free-text e- mails sufficient? When these procedures are established, ensure that events and changes can be handled fast enough, so configuration management is not perceived as an unnecessary bottleneck in stressed situations.

Changes in external interfaces for the system are typically handled and approved differently from internal changes. The procedure for this is also defined in this section. An area often overlooked is changes in support software and tools, such as new versions of compilers, linkers, and libraries. It's a good idea to think about how to handle such changes, including how to introduce new versions in a controlled manner.

Status Reporting

This section defines how status information about configuration items is collected, treated, and reported on. Status information is partly extractable from the metadata for configuration items and partly included in information related to item approvals, release requests, event registrations, and change requests.

An important part of status reporting is defining periodic reportscontents, frequency, and recipients. Remember to consider status reporting requirements from customers and users. The handling of ad hoc or dynamic queries may also be defined: is it possible for certain roles to write queries directly in the database, and/or how are queries to be formulated and handed to the librarian? Status reporting considerations help decide which data should be registered and how long to keep it.