The Art Of Software Development (part 5): Adding Value - Changing Things Around (
Page 3 of 6 )
Change requests may arise on account of problems encountered in the
software or documentation, or because of an enhancement to
previously-defined requirements. Typically, a change request contains a
detailed description of the item to be changed, together with
information on the reason for the change, the task priority and an
expected date by which the change request should be implemented.
This request is then passed on to the project manager during a formal
software review, via written or verbal request to the project manager,
or through the on-site customer representative. The project manager
should log each change request, perform an evaluation of the impact of
the change with the development team, and notify the customer of the
time and cost associated with implementing the change request. When
calculating this time and cost, it's important to factor in the effort
required to update the documentation delivered in previous stages, and
to re-execute all test cases relevant to the change.
Once the customer formally approves the change, the change request log
should be updated and the request handed over to the development team
for implementation. The updated software then passes through unit and
system testing before being released to the customer, together with
updated documentation. The original requirements specification, design
document and test plan should also be updated by the project manager to
incorporate the changes.
An important component of this entire process is the so-called "change
request log", functionally similar to the "defect log" maintained during
the test phase. The status of each change request
(reviewed/canceled/approved/underway/delivered) should be maintained and
updated on a daily basis by the project manager, so that a quick
overview of the current status of all change requests related to the
project can be quickly obtained at any time. This change request log
also serves as a record of the modifications made to the software over a
period of time.
It's also important to ensure that proper version control processes are
followed when executing change requests, especially if these requests
occur on an ongoing basis. By ensuring that every change to the source
code of the application is placed under version control, the development
team has the capability of reverting to an earlier version of the
application at any time, in case unexpected problems crop up (or the
customer changes his or her mind). As I've said before, this source code
repository should be backed up on a regular basis, with all concerned
focals aware of how it may be restored in the event of a disk crash or
system failure.
Every released version of the software should also be archived on
reliable media (CD-ROM is the cheapest and most effective at this time),
and stored in a library, so that it can be accessed at any time by the
development or testing team. This archive makes it easier to retrieve a
particular version of the software, provides a history of the various
software releases, and simplifies the process of testing for, and
replicating, errors encountered by the customer with specific versions
of the software. Ensure that each archived version is clearly tagged
with a version number and a release note detailing the changes that took
place in that version.
