A critical component of project monitoring and control is change management. As business requirements and operating environments change all the time, the project manager has to manage change throughout the software development cycle from acquisition,
supply, development, operation, and then maintenance. The guiding principles, techniques, and tools for change management are discussed in this chapter.
Configuration Management Procedures
Strict configuration management requires that one person (or group) on each development and maintenance project be assigned as the project librarian. The project librarian is the only person authorized to write into the baseline library for the project. The procedure is summarized below.
1. File baseline code module.
2. Allow checkout for read-only purposes to individuals needing access. For instance, test team needs access for testing.
3. Allow chargeout for update to authorized programmers.
4. Monitor that chargeout items are returned.
5. Notify testers of chargein items for testing.
6. Verify that the text preamble to code identifies the change, date, programmer, and lines of code affected.
7. Chargein the item, refiling the module.
8. If derivations are used, file the derivation with project documentation.
When a project is in the code and unit test stage, the project librarian establishes an application library. As each module is unit tested and moves into subsystem and integration testing, the programmer's final version is given to the project librarian for addition to the library.
Error fixes, changes during testing, and maintenance changes are all managed the same way. The programmer tells the librarian she or he is checking the module out for update, and the librarian keeps track of this fact. The code is copied out of the library
and into the programmer's own workspace. The charges are made and unit tested. Upon completion of the unit test, the programmer gives the module and documentation to the librarian for reentry to the library.
The librarian checks that no other changes have been made during the time the programmer has the module out for update. If not, the module is rewritten into the library.
Depending on the library software used, additional features allow the librarian to issue a chargeout against a module. A charge-out causes a lock to be placed on the module such that no other chargeouts for update may be performed until the lock is removed. When the changed version of the code module is reentered into the library, a charge-in occurs. A charge-in is the updating of a charge-out module to remove the lock. The more intelligent the software, the more actions taken during charge-in. For instance, some library software packages initiate a regression test when a chargein action is, taken.
FIGURE 18-16 Delta Version Development
The disadvantage to having a formal project librarian is that the librarian becomes indispensable. The risk is that the librarian might become a bottleneck to updating the production library. For instance, if one person is the librarian, he or she might
be called for jury duty and be out of work for several weeks. During that time, unless another librarian is named, no updates can be performed.