Page 263 -

234 PART TWO MANAGING SOFTWARE PROJECTS

9.5 CHANGE CONTROL

The reality of change control in a modern software engineering context has been
summed up beautifully by James Bach [BAC98]:

Change control is vital. But the forces that make it necessary also make it annoying. We
worry about change because a tiny perturbation in the code can create a big failure in the
product. But it can also fix a big failure or enable wonderful new capabilities. We worry
about change because a single rogue developer could sink the project; yet brilliant ideas
originate in the minds of those rogues, and a burdensome change control process could
effectively discourage them from doing creative work.
Bach recognizes that we face a balancing act. Too much change control and we cre-
ate problems. Too little, and we create other problems.
“The art of progress is For a large software engineering project, uncontrolled change rapidly leads to
to preserve order chaos. For such projects, change control combines human procedures and automated
amid change and to tools to provide a mechanism for the control of change. The change control process
preserve change 4
amid order.” is illustrated schematically in Figure 9.5. A change request is submitted and evalu-
ated to assess technical merit, potential side effects, overall impact on other config-
Alfred North
Whitehead uration objects and system functions, and the projected cost of the change. The results
of the evaluation are presented as a change report, which is used by a change control
authority (CCA)—a person or group who makes a final decision on the status and pri-
ority of the change. An engineering change order (ECO) is generated for each approved
change. The ECO describes the change to be made, the constraints that must be
respected, and the criteria for review and audit. The object to be changed is "checked
out" of the project database, the change is made, and appropriate SQA activities are
applied. The object is then "checked in" to the database and appropriate version con-
trol mechanisms (Section 9.4) are used to create the next version of the software.
The "check-in" and "check-out" process implements two important elements of
change control—access control and synchronization control. Access control governs
Confusion leads to
errors—some of them which software engineers have the authority to access and modify a particular con-
very serious. Access figuration object. Synchronization control helps to ensure that parallel changes, per-
and synchronization formed by two different people, don't overwrite one another [HAR89].
control avoid Access and synchronization control flow are illustrated schematically in Figure
confusion. Implement 9.6. Based on an approved change request and ECO, a software engineer checks out
them both, even if a configuration object. An access control function ensures that the software engineer
your approach has to
be simplified to has authority to check out the object, and synchronization control locks the object in
accommodate your the project database so that no updates can be made to it until the currently checked-
development culture. out version has been replaced. Note that other copies can be checked-out, but other
updates cannot be made. A copy of the baselined object, called the extracted version,

4 Although many change requests are submitted during the software support phase, we take a
broader view in this discussion. A request for change can occur at any time during the software
process.