Update 27-Apr-2003

Change Control Process

Figure 1.

Usually when Company have established Change Control Process as it shown on Fig.1, everybody sure that Company use methodology. However, it is necessary to understand that some other issues need to be properly documented as well. Diagram Fig.1 shows only part of the Change Control Flow (described below) and Change Control Process itself is not guarantees that new development will be successful.

Change Control Flow

Figure 2.

On the Diagram Fig. 2 it is shown that Change Control Process (described above) is only a part of the Change Control Flow. Before implementing any change it is required to have two Reviews. Each of the reviews can either approve or reject the change. First Review estimates Impact of the Change requested. It is not always necessary to apply the Change (e.g. it may be "nice-to-have" request). Second Review analyses and assesses technical Proposal of how the requested Change will be engineered. Both Reviews also estimates cost and resources required.

Change Control Management

Figure 3.

Diagram Fig.3 shows that a Company needs to balance the amount of Change Control Management it uses carefully. 

Too much control and the development process is choked by paperwork and little actual work gets done. Not enough control and the project may never be completed as it becomes more difficult to track what has been done, and developers will make errors, and repeat work thus wasting the company's time and money.

Practical effect could be described by the following sentence: It is possible to find optimal Change Control Management level to approach maximal quality and productivity of the development in any given environment.

Baseline Scheme

Figure 4.

Baselines are the core of Software Change Management (SCM); they provide a stable platform to work to from. The Software Change Items (SCI) that are identified determine the baseline(s) associated with the project

Baseline is a secure specification of the software in its most recent state.

Changes to the baseline can only be made by following strict change control procedures. The baseline must be protected from any unauthorized changes.

Any proposed changes to the baseline must first be tested against a trial version to be sure that it does not invalidate any of the other changes.

A new baseline is established for each complete set of approved system changes.

Each baseline must include a cross-reference, or traceability matrix that maps each design element to their corresponding software requirements. The element that is associated with a given baseline must define the key information that is required to reproduce it.

After the baseline is established all subsequent changes are recorded as deltas until the next baseline is set.

The number and types of baselines will depend upon the size and scope of the project.