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 thesoftware or documentation, or because of an enhancement topreviously-defined requirements. Typically, a change request contains adetailed description of the item to be changed, together withinformation on the reason for the change, the task priority and anexpected date by which the change request should be implemented.
This request is then passed on to the project manager during a formalsoftware review, via written or verbal request to the project manager,or through the on-site customer representative. The project managershould log each change request, perform an evaluation of the impact ofthe change with the development team, and notify the customer of thetime and cost associated with implementing the change request. Whencalculating this time and cost, it's important to factor in the effortrequired to update the documentation delivered in previous stages, andto re-execute all test cases relevant to the change.
Once the customer formally approves the change, the change request logshould be updated and the request handed over to the development teamfor implementation. The updated software then passes through unit andsystem testing before being released to the customer, together withupdated documentation. The original requirements specification, designdocument and test plan should also be updated by the project manager toincorporate the changes.
An important component of this entire process is the so-called "changerequest log", functionally similar to the "defect log" maintained duringthe test phase. The status of each change request(reviewed/canceled/approved/underway/delivered) should be maintained andupdated on a daily basis by the project manager, so that a quickoverview of the current status of all change requests related to theproject can be quickly obtained at any time. This change request logalso serves as a record of the modifications made to the software over aperiod of time.
It's also important to ensure that proper version control processes arefollowed when executing change requests, especially if these requestsoccur on an ongoing basis. By ensuring that every change to the sourcecode of the application is placed under version control, the developmentteam has the capability of reverting to an earlier version of theapplication at any time, in case unexpected problems crop up (or thecustomer changes his or her mind). As I've said before, this source coderepository should be backed up on a regular basis, with all concernedfocals aware of how it may be restored in the event of a disk crash orsystem failure.
Every released version of the software should also be archived onreliable 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 thedevelopment or testing team. This archive makes it easier to retrieve aparticular version of the software, provides a history of the varioussoftware releases, and simplifies the process of testing for, andreplicating, errors encountered by the customer with specific versionsof the software. Ensure that each archived version is clearly taggedwith a version number and a release note detailing the changes that tookplace in that version.
Next: Playing The Numbers >>
More Practices Articles
More By Vikram Vaswani, (c) Melonfire
