Return to the home page

Change Control

Author: Mr D Wilson

Source of document: Internet

Date: 03/06/96

Usage. There will be times during continual improvement, where change will adversely affect the development of other systems. When this situation occurs, that change will need to be authorised.

• There are three fundamental types of changes that can affect multiple systems:
• Changes made to correct a baseline problem.
• Changes made to compensate for an external problem.
• Changes made to adapt the system due to requirement changes.
• Analysis. All change requests will be submitted by the sponsor, for an impact analysis prior to the review by the QE. The affected Depts will review the change request with their appropriate technical, management, quality assurance, and user personnel.
• The impact analysis includes such issues as urgency of the fix, risk, change control, schedule, cost (time and manpower), safety, and permanence. It will be documented and attached to the appropriate change request document and will list the requested change, contributing factors, alternative solutions, potential impact on other systems and documentation changes required.
• The sponsor will make a recommendation as to whether the change will be implemented in the current installed system or deferred to the next version of the system. This recommendation will take into consideration:
• Implementation schedule.
• Number of changes since the last system update.
• Size of the change (impact of time to all Depts affected).
• Validation issues.
• Approval. After the impact analysis is complete and before a change may be implemented, it must be approved by the QE. The criteria employed for determining whether or not to authorise implementation of a change will be one or more of the following:
• Schedule.
• Cost (time and manpower).
• Permanence (An Error/Patch requiring a quick fix vs. a change/addition to requirements that requires properly executed life cycle processes).
• The decision is generally made on a consensus basis. However, where consensus cannot be reached, the user representative makes the decisions in priority of effort towards meeting user requirements and the QSM makes the decisions based on technical matters based on cost (time and manpower) and priority constraints.
• Test. Regression testing is necessary to determine that a change works properly and has not compromised the system functionality. Any changes to previously verified systems must be analysed to determine the extent of reverification needed. When changes are made to the system that implements or affects a previously verified requirement, the compliance of the system to that requirement must be reverified. In addition, all critical functions associated with that portion of the system will be reverified if any change is made to any portion of the system to assure that the change does not inadvertently affect quality. The QA test engineer will determine what tests will be run to perform the regression test.
• Control. All system configurations will be controlled and only authorised changes will be installed. If after the QE gives approval for changes to the system, the sponsor determines that more extensive changes are needed, the sponsor must submit notification to the QE with a new impact analysis. The QE, in cooperation with the sponsor, will consider the modification in light of the original request and make appropriate decisions.
• All changes as described under "usage" above, will be controlled by the QE and an official build implementing designated changes will be released by the QE. The changed system configuration will be described in WTI's/WI's.
• All changes will include documentation consisting of the appropriate problem reports, change log, and any other information documenting the change.

QE Quality Engineer.

QSM Quality Supervisory Manager

QA Quality Auditor

WTI Workshop Technical Instruction

WI Work Instruction

Return to the home page