Parks and Recreation Knowledge Base

Parks and Recreation Knowledge Base  /  Other Documents  /  Help Desk Lists and Policies

Software Change Control Procedure

Updated on

Software problems can be reported at any stage in the lifecycle. Problems can fall into a number of 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
  • Code/configuration does not conform to design
  • Design does not conform to requirements
  • New or changed requirements

Determination of the problem category defines the phase of the lifecycle at which corrective action needs to begin.

Diagnose Problem

  1. Identification of the problem
    1. If a discrepancy between the desired and actual behavior is identified, a request to investigate may be initialized by a phone call, email, or Zendesk ticket to the Customer Service Help Desk.
    2. The request will be reviewed by the Help Desk Operations Team to determine problem category.
    3. The request will be passed to the Projects Team Manager or designee (Controller). That individual will add the issue to the configurations management system (CMS).
    4. The Controller will then arrange for a review of the issue.
  2. Investigation
    1. The investigation may be performed by the Controller, or any other suitably knowledgeable team member. The investigator should record the results in the CMS, inclusive of no action needed when applicable.
  3. Review Investigation Results
    1. All parties within the Help Desk with a legitimate interest in the software should review the results of the investigation. This group may be formally constituted into a Software Change Review Board (SCRB). The reviewers should indicate whether the recommended solution should be implemented or rejected.
    2. If the recommendations are rejected, the Controller should record the results in the CMS for future reference, and contact the originator of the request.
    3. If the recommendations are accepted and a decision is made to implement, the process is moved to the “Make Changes” stage.

Make Changes

  1. The fix or configuration change may range in impact, from simple to extensive changes to design, documentation and code. In all cases, the changes must tie back to the problem in the CMS.

Software Configuration Control

  1. If the fix or configuration change must be completed by the vendor, the Controller will put in a ticket with the vendor for hosted solutions.
  2. If internal developed application or system configuration, the Controller will allocate to the configuration specialist or developer and schedule.
    1. Fix
      1. The software should be fixed in line with recommendations in the CMS.
      2. The new version of the software should be configured in a demo environment.
    2. Test
      1. Test and verification activities should match the extent of the changes. All code should be tested, however 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.

Release Change

  1. If internal developed application or system configuration.
    1. Completed changes will be incorporated into a new release of the software. The release may include other changes as well, or may only include the changes required by the identified problem.
    2. The release is tracked by the Controller in the CMS.
    3. The Controller schedules the release of the fix or change and sends communication to users and includes the message on InterComm.
    4. The Controller records completion in the CMS.
  2. If hosted change
    1. The SCRB will review the changes in the vendor’s release notes and make recommendations to accept or reject the implementation.
    2. If the recommendations are rejected, no actions are taken.
    3. If the recommendations are accepted, The Project Team Manager designates a Controller.
    4. The release is tracked by the Controller in the CMS.
    5. The Controller schedules the release of the fix or change and sends communication to users and includes the message on InterComm.
    6. The Controller records completion in the CMS.
Next Article User Access Procedure

Other Documents

Help Desk Lists and Policies 3

Other Resources

Print Article