Page 130 -

Change Control Process
Table 6-14 shows the script for a change control process.

TABLE 6-14. Change control process script
Name Change control process script
Purpose To control changes by evaluating their impact before agreeing to implement them
Summary The change control process ensures that the impact of each change is evaluated before the
decision is made to implement that change. A change is proposed by anyone evaluating the
software. A change control board (CCB), made up of the decision-makers, project manager,
stakeholder or user representatives, and selected team members, evaluates the change. The
CCB either accepts or rejects the change.
Work products Input
Issue report in the defect tracking system that describes the change
Output
Modified issue report that reflects the impact of the change and the decision on whether or
not to move forward with it
Entry criteria A change has been discovered, and an issue report that describes it has been entered into the
defect tracking system.
Basic course of events 1. A CCB member (typically a tester) who is familiar with the expected functionality of the
software reads and understands the issue report, which describes the requested change.
2. The CCB member familiar with the change meets with the project manager to explain its
scope and significance. Together, they identify all project team members who will be
impacted by the change, and work with them to evaluate its impact. The project manager
updates the issue report to reflect the result of that evaluation.
3. At the next CCB meeting, the project manager presents the scope and significance of the
change, along with its expected impact. The CCB discusses the change, and performs a cost-
benefit analysis to determine if its benefits are worth the cost. The CCB approves the change.
4. The project manager updates the issue report to indicate that the change has been
approved, and then updates the project plan to reflect the change. The team members
begin implementing the change.
Alternative paths 1. In Step 1, if the CCB member does not understand the change, it can be returned to the
submitter for further explanation. The submitter may choose to either update the issue
report to clarify the change (in which case, the script returns to step 1) or drop it entirely (in
which case, the change control process ends).
2. In Step 3, if the CCB determines that the benefits of the change are not worth the cost, it can
reject it. The change control process ends, and no changes are made to the project. The

project manager updates the issue report to reflect the fact that it was rejected.
Exit criteria The project plan has been updated to reflect the impact of the change, and work to implement
the change has begun.

Evaluate Changes in the CCB Meeting
There are points in the course of the project when the CCB may need to meet regularly:
• During the requirements phase, the CCB will need to discuss the scope of the project if
it turns out that there are major areas that the vision and scope failed to cover.
• During the design and programming of the software, the team may discover that the
requirements need to be changed. For example, programmers may discover require-
ments in the SRS that seemed reasonable at the time but that turn out to be contradic-
tory or convoluted, which could be changed to simplify the implementation.

122 CHAPTER SIX