Methodology:: Change Control

From SK:: Wiki

1 General
2 Change Control
3 Downloads
4 Your Comments

General

Warning If you think that you have discovered any copyright violation on page, please notify me immediately by e-mail: sergei@kostigoff.net. Thank you.

Status: Draft release.

Purpose

Purpose of this diagram set is to explain certain things of Change Control Process.

Scope

Some aspects of the Change Control Process are described. Explanations are given in the form of diagrams with some comments.

Glossary and Abbreviations

SCI - Software Change Items
SCM - Software Change Management
UAT - User Acceptance Test

Change Control

Diagrams on this page related to a Change Control and its implementation. Key points for Change Control are highlighted. It is shown that it is necessary to balance Change Control for a given circumstances, there is no Magic Universal Solution exists. Brief information about Baseline as a result of minimal Change Control is given.

Change Control Process

Usually when Company have established Change Control Process similar to shown on Figure 1, everybody sure that Company use methodology. However, it is necessary to understand that some other issues need to be properly implemented and documented as well.

Fig.1: Change Control:: Change Control Process

Diagram Figure 1 shows only part of the Change Control Procedure (described below). Change Control Process itself is not guarantees that the new development will be successful (or implementation of the new system will be successful).

Change Control Process reduces risk of new project failure, as well as risk of Production System failure.

Change Control Procedure

On the Diagram Figure 2 it is shown that Change Control Process (described above) is only a part of the Change Control Procedure.

Fig.2: Change Control:: Change Control Procedure

Before implementing any change it is recommended 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" low priority request).
Second Review analyzes and assesses Technical Proposal of how the requested Change will be engineered. Both Reviews also estimates further steps costs involved and resources required.

Please note that after any decision of the above Change Initiator should be informed about the decision made.

You may reject unnecessary Change on earlier stage, and save your time and money.

Change Control Management:: Balance

Diagram Figure 3 shows that the Company needs to carefully balance the amount of Change Control Management used.

Fig.3: Change Control Management:: Balance

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 for any given environment.

There is no universal solution, but there is universal approach to find a best possible solution.

Change Control:: Baseline Scheme

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 Scheme is shown on Figure 4.

Fig.4: Methodology:: Change Control:: Baseline Scheme

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.

Downloads

Diagrams from the above Diagram Set could be downloaded in Zip format here:

change_control_dia.zip

Diagrams are created in Dia format. For Unix/Linux users it is a standard diagrammer software. Windows users can obtain legal GPL-ed copy of DIA from http://dia-installer.de/index_en.html