Change control policy

1 Software Change Control

#1 This section of this procedure applies to software placed under configuration management.

#2 Software problems can be reported at any stage in the lifecycle. Problems can fall into several categories according to the degree of regression in the life cycle – i.e. how far back you need to go to fix the problem. Problem categories include:

• operations error;
• user documentation does not conform to code;
• code does not conform to design;
• design does not conform to requirements;
• new or changed requirements.

#3 Selection of the problem category defines the phase of the lifecycle at which corrective action needs to start.

1.1 DIAGNOSE PROBLEM

1.1.1 Identification of the Problem

1. If a discrepancy between desired and actual behaviour is identified (this covers both “bugs” and modification requests) then Section A of a Problem Report Form (see Appendix A) should be completed. The Problem Report Form should be given a unique reference.
2. The form should be passed to the individual responsible for the configuration management of the software (e.g. Maintenance Manager, project Technical Architect – known as the Controller). That individual should maintain a file of all such forms received, and place a copy of the form into that file.
3. The individual should then arrange for a review of the issue on the form, this may be a bug that needs a fix or an enhancement that is being proposed.

1.1.2 Investigation

1. The investigation may be performed by the Controller, or any other suitably knowledgeable individual. The investigator should record the results of the investigation in Section B of the Problem Report Form. The suggested action can include no action.

1.1.3 Review investigation results

1. All parties with a legitimate interest in the software should review the results of the investigation. They may be formally constituted into a Software Change Review Board (SCRB). The Reviewers should indicate whether the recommended action arising from the investigation should be implemented or rejected.
2. If the recommendations are rejected then the Controller should file the completed Problem Report Form for future reference.
3. If the recommendations are accepted and a decision is made to implement then the process moves on to the next stage – Make changes.

1.2 MAKE CHANGES

1. The fix may vary from a simple change to one software module to extensive changes to design, documentation and code. In all cases, the changes need to be tied back to the authorised Problem Report Form.

1.3 SOFTWARE CONFIGURATION CONTROL

1. The Controller should log and file the Problem Report Form. The Fix should be allocated to developers and scheduled.

1.3.2 Fix

1. The software should be fixed in line with the recommendations on the Problem Report Form.
2. The new version of the software should be stored as a separate version in the configuration management (CM) library that holds the software. The change to the code should be identified in the relevant code headers, and also in any available comment fields in the CM library.

1.3.3 Test

1. Test and verification activities should match the extent of the changes. All code should be tested, but if there are design and documentation changes, then these should also be reviewed and be subject to similar quality control measures as for an original development. The impact of the changes on other areas of the system should be assessed, and if the risk of introducing new problems is significant, then regression tests should be run.

1.4 RELEASE CHANGE

1. Completed changes will be incorporated into a new release of the software. The release may include other changes as well, or may just include the changes required by the one Problem Report Form.
2. The release is tracked on the Release Note (see Appendix B) using a unique release number.
3. The Controller schedules the fix so that it is included in a controlled release of the revised system. This may be a matter of hours if the fix is an urgent bug-fix to keep the system running, or it may not occur for a number of weeks.
4. The release may be performed by the Controller or another developer (known as the Releaser). The Releaser should record all release details on the Release Note. The release number should also be recorded on the original Problem Report Form.
5. The Releaser arranges for the fix to be delivered and installed. Once the client has expressed satisfaction about the correctness of the fix, the releaser signs the Release Note and files it.