Menu Content/Inhalt
Home arrow --- Methodology arrow Change Control
Change Control Print
Written by Sergei Kostigoff   
Saturday, 15 March 2008

General

informationPurpose of this diagram set is to explain certain things of Change Control Process.
informationScope: Some aspects of the Change Control Process are described. Explanations are given in the form of diagrams with some comments.
acceptStatus: Draft release.
exclamationWarning: If you think that you have discovered any copyright violation on page, please notify me immediately by e-mail: This e-mail address is being protected from spam bots, you need JavaScript enabled to view it . Thank you.

 

  

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.

Change Control:: Process
Fig.1: 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.

Change Control:: Procedure
Fig.2: 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.

Change Control:: Management Balance
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.

Change Control:: Baseline Scheme
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

addDiagrams from the above Diagram Set could be downloaded in Zip format here:
 compressed icon change_control_dia.zip
informationDiagrams are created in Dia format. For Unix/Linux users it is a standard diagram drawing software. Windows users can obtain legal GPL-ed copy of Dia from http://dia-installer.de/index_en.html

 

Your Comments

helpIt could be really great if you find time to submit your comments, corrections, and other feedback to This e-mail address is being protected from spam bots, you need JavaScript enabled to view it


Regards,
  svk signature
Sergei

Last Updated ( Saturday, 15 March 2008 )
 
< Prev   Next >

Newsflash

Migration to a new site (joomla!) hasbeen finished today, 2008-03-16. After testing and confirmation of the success the old sites will be decomissioned and removed. I will make redirects "moved permanently", but just in case - Please update your links!