CHANGE CONTROL

Home Software Testing Techniques Change Control :Process and Challenges Change Control :Process and Challenges Change control is a formal process used to ensure that a product, service or process is only modified in line with the identified necessary change. It is part of ITIL. It is particularly related to software development because of the danger of unnecessary changes being introduced without forethought, introducing faults (bugs) into the system or undoing changes made by other users of the software. A change is an event that results in a new status of one or more configuration items (CI s)”. Change control aims to ensure that all changes are assessed and approved by management before their implementation. Its goals are: * Minimal disruption to services * Reduction in back-out activities * Economic utilization of resources involved in implementing change Later it became a fundamental process in quality control. A change "freeze point" was introduced to suspend any further changes until after the completion of the initial project. Change Control is also formally used where the impact of a change could have severe risk and/or financial consequence. Typical examples from the computer and network environments are the upgrade of operating systems, network routing tables or the electrical power systems supporting such infrastructure, not forgetting changes to the contract itself. George Brilis et al. have published a paper which provides a guidance of development and implementing the policy on the integrity of recordkeeping systems The process There is considerable overlap and confusion between change management, configuration management and change control. The definition below is not yet integrated with definitions of the others. Change Control today is seen to be a set of six steps. Each step may have another process associated with it. These start with the receipt of the Request for Change or RFC, or a Request for Service (RFS): 1. Record / Classify 2. Assess 3. Plan 4. Build / Test 5. Implement 6. Close / Gain Acceptance. A formal request is received for something (usually in the Client s [contract]) to be changed, known as the "Change Initiation". Someone then records and classifies or categorizes that request. Part of the classification would be to assign a Category to the change, i. e. is the change a "major business change", "normal business change" or "minor business change". The first category would be immediately liable to a CAB (see below for references to CAB s). Then it would be necessary to assign a priority to the change, i. e. "emergency change", "expedited change" or "normal change". The first would be already completed in reality with the change being done retrospectively (An Emergency CAB may have been involved too). The second implies that it needs doing within the SLA (Service Level Agreement) times. The last is business as usual. Finally either here or at consolidation, the Impact Level needs to be decided, i. e. is this change going to have a "major", "normal" or "minor" impact on the business. The first should go to a CAB. The classifier then decides upon who or whom should be invited to make an impact assessment. The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and