Changes those due to the evolution of work products and those due to requirement changes take place continuously in a software project. All these changes eventually get reflected as changes in the files containing source, data, or documentation. When multiple people create and change the huge number of files in a software project, it can lead to complications unless the changes are properly controlled. Consider these situations, taken from various projects.
Two different change requests came from the customer. The project manager assigned one request to Rao for implementation, and the other to Meera. Both had to modify code for module X. When Meera finished her modification, she saved the file for X, inadvertently overwriting the changes Rao had made a day earlier.
Friday was the deadline for release of a module for which three team members were developing the code. Integration of unit-tested code was planned for the final two days. On Tuesday night, Subbu, the developer of several key functions, left town to attend to an emergency. The next day the module leader and the team members spent many hours looking through Subbu's files. They managed to identify some files containing the various functions Subbu was developing, but they found umpteen versions of these files. One of the team members had to work on the problem over the weekend. Starting with some version of Subbu's programs, he developed and tested the unit, redoing the work that Subbu had almost finished before leaving. The module was finally delivered three days late.
Srinath's team was in good spirits. They had finished the development on time, and the final testing had shown no bugs. The software was released to the customer for implementation. The next day Srinath received angry e-mails from the users and the customer, reporting problems in the software. After frantic effort by the team, the cause was found: The release version of the software contained an older version of a key component.
Stories like this can be found in most organizations. Configuration management (CM) also known as software configuration management (SCM) is the aspect of project management that focuses exclusively on systematically controlling the changes so that such problems do not occur.
This chapter first discusses some general concepts relating to CM and then describes the CM process followed at Infosys. It also gives the CM plan for the case study.