This chapter is from the book
This chapter is from the book
This chapter is from the book
1.4 Change Control
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.
)
Figure 1–9 Change Control in Context
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
| Phase |
Description |
| Creation of the event registration. |
The event registration is created, and the event is described. |
| Analysis of the event registration. |
Configuration item(s) affected by possible changes are determined, and the extensiveness of these changes is estimated. |
| Rejection or acceptance of the event registration. |
If the event registration is accepted, a change request is created for each configuration item affected. |
| The change request initiates a new configuration item. |
A new configuration item is identified and created, and the change is implemented. In the course of accepting the new item and placing it in storage, feedback is given to the configuration control board. |
| Closing of the change request. |
The change request can be closed when the change has been implemented and accepted. |
| Closing of the event registration. |
The event registration can be closed when all corresponding change requests are closed. |
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 used—for 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 implemented—or 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 also—and will typically, for most important configuration items—consist 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.
)
Figure 1–10 Change Control Process Diagram