Configuration Management Principles and Practice

When developing and maintaining a product, changes are inevitable. People make mistakes, customers need changes, and the environment in which the product operates evolves. In addition, people constantly develop their knowledge of the problem and their ability to solve it. In software development, it's generally said that the solution of a problem will create new problems. In other words, we get wiser all the time.

The purpose of change control is to be fully in control of all change requests for a product and of all implemented changes. For any configuration item, it must be possible to identify changes in it relative to its predecessor. Any change should be traceable to the item where the change was implemented. Figure 1-9 shows how change control affects and is affected by its environment.

Inputs

Change control is initiated by an event. An event may also be called a wish for modification but need not be expressed as a clearly formulated wish. In this context, an event is any observation of something surprising, unexpected, inconvenient, or directly wrong during usage of the configuration item. It may, for instance, be

• A wrong formulation, caught during the review of a document

• A coding mistake found during a walk-through of a piece of source code

• An enhancement request arising from a new idea from the customer during work on the project

• A mistake found in the integration test

• A wish to expand or enhance the finished product, arising once the product is in operation

• An inquiry to a helpdesk about a problem in connection with usage of a system

• A change required in the code because of an upgrade to a new version of the middleware supporting the system, which may not be backward compatible

An event should be documented in an event registration, which is the input to the change control activity. Some changes, such as those due to a review, can be foreseen and planned, while those due to, for instance, a new customer request cannot.

Outputs

The result of change control is documented events and change requests derived from these events. Both should be securely maintained, as in a database, so that relationships between change requests and configuration items can be reliably maintained . Event registration and change requests may be put under configuration management, but this happens rarely, except where configuration management has to be very formal.

Change Control Activities

A change process is a miniature development project in itself. An event registration should have a written and controlled life cycle, consisting roughly of the phases described in Table 1-1. Each phase should be described in detail, stating the responsibility and specific actions in the company. It may be necessary for a company to describe different kinds of life cycles, depending on the types of events to be handled.

Table 1-1. Overview of Change Control Phases

Quite often the change request is joined with the event registration, so no independent change requests are created. This is not a very good idea, unless it remains possible to extract statistics and status information on individual change requests as well as on the event. This is especially true if an event causes changes in several configuration items, which is often the case.

Usage of Metadata

When performing the change process, metadata is used for analytical purposes. This may be in the form of reports or a direct search in the database or the databases where metadata is maintained. Trace information is often usedfor instance, to determine in which configuration item changes are required due to an event. Also information about variants or branches belonging to a configuration item is used to determine if a change has effects in several places.

Finally metadata may be used to determine if a configuration item has other outstanding event registrations, such as whether other changes are in the process of being implemented or are awaiting a decision about implementation.

Consequence Analysis

When analyzing an event, you must consider the cost of implementing changes. This is not always a simple matter. The following checklists, adapted from a list by Karl Wiegers, may help in analyzing the effects of a proposed change. The lists are not exhaustive and are meant only as inspiration.

Identify

• All requirements affected by or in conflict with the proposed change

• The consequences of not introducing the proposed change

• Possible adverse effects and other risks connected with implementation

• How much of what has already been invested in the product will be lost if the proposed change is implementedor if it is not

Check if the proposed change

• Has an effect on nonfunctional requirements, such as performance requirements (ISO 9126, a standard for quality characteristics, defines six characteristics: functional, performance, availability, usability, maintainability, and portability. The latter five are typically referred to as nonfunctional.)

• May be introduced with known technology and available resources

• Will cause unacceptable resource requirements in development or test

• Will entail a higher unit price

• Will affect marketing, production, services, or support

Follow-on effects may be additions, changes, or removals in

• User interfaces or reports, internal or external interfaces, or data storage

• Designed objects, source code, build scripts, include files

• Test plans and test specifications

• Help texts , user manuals, training material, or other user documentation

• Project plan, quality plan, configuration management plan, and other plans

• Other systems, applications, libraries, or hardware components

Roles

The configuration (or change) control board (CCB) is responsible for change control. A configuration control board may consist of a single person, such as the author or developer when a document or a piece of code is first written, or an agile team working in close contact with users and sponsors, if work can be performed in an informal way without bureaucracy and heaps of paper. It may alsoand will typically, for most important configuration itemsconsist of a number of people, such as the project manager, a customer representative, and the person responsible for quality assurance.

Process Descriptions

The methods , conventions, and procedures necessary for carrying out the activities in change control may be

• Description of the change control process structure

• Procedures in the life cycles of events and changes

• Convention(s) for forming different types of configuration control boards

• Definition of responsibility for each type of configuration control board

• Template(s) for event registration

• Template(s) for change request

Connection with Other Activities

Change control is clearly delimited from other activities in configuration management, though all activities may be implemented in the same tool in an automated system. Whether change control is considered a configuration management activity may differ from company to company. Certainly it is tightly coupled with project management, product management, and quality assurance, and in some cases is considered part of quality assurance or test activities. Still, when defining and distributing responsibilities, it's important to keep the boundaries clear, so change control is part of configuration management and nothing else.

Example

Figure 1-10 shows an example of a process diagram for change control. A number of processes are depicted in the diagram as boxes with input and output sections (e.g., "Evaluation of event registration"). All these processes must be defined and, preferably, described.