Figure 8.1 : Change Control Approval Board members
All objects that are produced or procured during a project have a defined life-cycle. Approval and baselining is one of the key milestones in this life-cycle. It is at this milestone that work on an object is declared as being complete and the object is deemed to be fit for purpose and approved (refer to the Approval and Baselining Standard).
Change control is the process that should be applied to control all changes to objects once they are approved. The application of change control is not necessary for draft objects, e.g. draft documents and code that have not yet been approved.
A Change Control Coordinator (CCC) shall be appointed with the responsibility of administering the change control process. The main responsibilities of the CCC are as follows:
• Act as first contact for all matters relating to change control.
• Maintain the change control log.
• Administer the change control process as defined in this document.
A Change Approval Board (CAB) may be established for reviewing all change requests. The CAB is the sole authority on a project for the authorisation of change. Figure 8.1 identifies the membership of the CAB.
Figure 8.1 : Change Control Approval Board members
The Software Development Manager should ensure that the membership of the CAB is matched to the requirements of his project.
The outline responsibilities of the various CAB members are as follows:
• Software Development Manager: Has the responsibility for presenting Change Requests (CRs) and all the relevant information.
• Business Representative: Has the responsibility for reviewing changes from the business perspective, e.g. assessing the business need and the business case.
• User Representative: Has the responsibility for reviewing changes from the user perspective, e.g. does it have the correct functionality. User involvement is mandatory for all changes that have impact on the system functionality.
• A Technical Representative: Has the responsibility for reviewing the impact of change on the technical integrity of the system.
The Software Development Manager shall ensure that resources are appointed to the above roles and that full job descriptions are produced and agreed.
Figure 8.2 is a schematic of the change control process.
Figure 8.2 : Outline change control process
All staff and users may initiate change by contacting the CCC. Changes may include the following:
• Issues or Concerns: Where the initiator believes that a change to the system may be necessary to rectify a potential problem or shortfall.
• Problems: Where the initiator wishes to report a defect or failure in an object. Developers must initiate a change request if they identify problems in approved objects during any project stage.
• Enhancements: Where the initiator wishes to modify a baselined object and this modification does not involve correcting a defect.
Projects shall define a process for initiating changes. This may involve a help desk type function or the use of paper CR forms.
The CCC has responsibility for logging all new CRs. A reference number shall be assigned to all new CRs and relayed back to the initiator.
The Software Development Manager shall investigate all CRs with the aim of confirming their validity and the necessary action to progress them.
For all valid changes this involves the following:
Impact analysis aims to identify the impact of the CR on existing baselined objects.
A detailed impact analysis report shall be produced that identifies all the affected products. Rules defining the format and contents of this shall be defined in appropriate procedures
The work schedules and resource requirements should be identified for each valid CR.
An estimate for the cost of constructing the change should be produced by the Software Development Manager in preparation for the CAB meeting.
All changes that involve introducing enhancements to baselined objects shall be supported by a justification. Major changes shall be supported by a detailed business case. Rules defining the format and contents of this shall be defined in appropriate procedures
The CAB shall meet on regular basis and perform the following:
• Review CRs and determine which can proceed and which cannot.
• Sign-off completed CRs and authorize their closure.
• Agree a venue for the next meeting.
The CAB meeting shall be minuted and the minutes issued following each meeting.
All objects listed in the impact analysis report shall be reserved for update (refer to the Version Control Standard). The status of these objects shall revert to “Draft” as soon as they are reserved (refer to the Approval and Baselining Standard).
A record shall be produced that identifies what objects have been reserved for change and by whom (refer to the Version Control Standard).
All modified objects shall be approved as defined in the impact analysis report. Once approval is granted all objects shall be marked as approved and then baselined (refer to the Approval and Baselining).
Approved objects shall be replaced in to the Master Library and a history record produced that describes the changes made to the objects (refer to the Version Control Standard).
The CAB shall sign-off all completed CRs.