Configuration control

6.3 Configuration control

CC is that part of CM concerned with the processing, approving, and installation of changes to the software products.

6.3.1 Change processing

Without an effective change processing mechanism, the software can easily become unidentifiable and unmanageable. Change processing mechanisms must be effective (effective does not necessarily mean complicated or bureaucratic). Figure 6.8 presents a very straightforward process for incorporating changes.

Figure 6.8: Incorporating changes.

Changes come from two primary sources: defect corrections and enhancements. To the change processing system, it matters little which source is involved. Each change must be requested, prepared, tested, approved, and implemented. It is the change processing activity that ensures that all required steps have been taken.

Once the software is baselined, all changes are referenced to the baseline in effect. It is important that all changes be controlled so that their effects can be tracked. The control of the changes is dependent on the stage in the SLC, various organizational factors, standards, and project priorities. The customer, who may have to pay for the changes, also is interested in change processing. The trail of the change, from its inception as the result of a defect or an enhancement request, must be clear. All steps in the change process are important, and ignoring or skipping one or more of them can introduce mistakes and cause further changes to be necessary.

Defects make changes necessary. Obviously, changes are the methods by which defects are corrected. The full defect tracking process was discussed in Chapter 5, so suffice it to recognize here that the change process is not limited to defect correction alone.

Enhancements are a major source of changes as the deployed software matures and new capabilities are needed. There are many cases in which the software system is implemented in a phased manner, starting with a smaller capability and gradually adding functions until the full required system is available. These changes are processed in the same manner as defects. That is, they are proposed, designed and tested, approved, and implemented.

The software CCB can be seen here as playing an important role. The CCB makes the final determination as to whether the change is made at all, and, if so, when it will be made. The CCB is responsible for making sure that changes are carefully analyzed and that all associated software effects are considered. The software quality practitioner is usually is a member of the CCB and can report on the quality aspects of the change and whether the quality requirements have been met.

Figures 5.1 and 5.2 introduced forms designed for the purpose of initiating and tracking a change through its processing. Change processing also often uses automated tools, such as spread sheets, database management systems, or full CM systems, to assist in the management of changes.

6.3.2 Change control boards

The software CCB is the final approval authority for the implementation of a software change. This board is responsible for coordinating changes and their intercomponent effects.

The CCB's size and membership depend on the standards of the organization and the needs of the project. All affected functions should be represented on the CCB in order for it to adequately review requested changes. In most cases, members come from each functional area (usually subsystem level), CA, CC, and the hardware areas involved, if appropriate. In addition, the software quality practitioner is expected to be a member of the CCB. In some organizations, a representative of the internal audit group is also an appropriate member.

Size is a factor in the efficacy of the CCB. If the group is too large, there may trouble getting things done in a timely manner. If, on the other hand, the proper areas are not represented, changes may be approved that adversely affect other parts of the system.

It is the responsibility of the CCB to review all proposed changes for their correctness and their effect on the baseline. Interactions with other parts of the software system are considered, as well as impacts on the schedule and cost. Especially in the case of cost and schedule, the customer is a necessary member of the CCB. There may also be cases in which a change will impact the system requirements. In these cases, the customer or user must be present in order to agree that the change and its impact are permissible.

The impact of the change on the documentation is also considered by the CCB. Any change that impacts higher-level components than itself probably also affects documentation of that level. Some changes may affect documentation all the way back to the requirements of the system. If the documentation is not updated as changes are made, the task of the software maintainer is made much more difficult. If the documentation is not up-to-date, the maintainer must regenerate it before beginning useful work on the next change.

There are instances where multiple CCBs are convened. This may be especially true in the case of very large or multiple-contractor projects. At the software development level, an informal CCB may review changes within subsystems and the overall system as the changes are proposed. These informal boards serve to prepare the changes for the more formal software CCB to which the changes will be submitted for final approval. At the same time, there is likely to be a hardware CCB working with the proposed changes to equipment involved in the system.

In the case of large systems involving hardware as well as software, there will be hardware CCBs paralleling the software CCBs. In addition, there will be an overall system CCB to review changes that affect performance, cost, schedule, hardware/software interface, and other global concerns beyond the scope of the lower CCBs. In the case of multiple CCBs, it is imperative that a written description of the relationships among the CCBs be prepared. This will ensure that there are no conflicts over authority and that no areas of concern are left unheeded.

The software quality representative to the CCB must make certain that all software quality system requirements for the project are being met. Of particular interest to the software quality representative will be the test plans for the change and the regression tests on the rest of the system to ensure that no unexpected impacts are being felt. Changes are to be tested to the same, or even greater, rigor as original development.

6.3.3 Software libraries

Ultimate access to configuration-controlled products is through the software library.

The library is the repository of the official issues of all documents and code. The librarian is responsible for the control of the baselined system and all current issues of the documents and code. There must be formal procedures for the entry of a particular issue of a component into the library. Equally formal procedures are used to gain access to the official issues of the components.

Provisions will be made for authors and programmers to access working copies of the official issues, but not to enter them back into the current library. There will also be procedures for maintaining cognizance of which working copies are being used, so that multiple changes are not being made to the same component at the same time without the knowledge of the changers.

Once the formal change procedures have been followed, and the CCB has authorized the implementation of a change, an SCN will be generated that tells the librarian to update the current official issue of the affected component. In a well-controlled library, the SCN is the only way to effect a change to the baselined system. Finally, it is the library that prepares the full system for formal delivery to the customer. Along the way, the library will prepare official issues for testing and operation. Figure 5.3 suggested a format for a software change notice.

As reuse of existing software products becomes more prevalent, the software library's responsibilities are usually increased to include the management and control of reusable items. Not only the item or product itself, but the applicable documentation describing the item and its appropriate use must be available and configuration managed. Reuse of items usually requires some sort of modification to the item in order that it correctly fit its new use. These modifications create variants of the item that will be managed and controlled just like the original. It is worth repeating that each instance of any configuration item or product must be carefully managed and its status and baseline records maintained.

It is frequently the additional task of the library to be the repository of all documentation for the software system. In some cases, even contracts and correspondence between the organization and the customer are kept in the central library. The use of the library as a documentation center is an effective way to be sure that copies of requirements and design documents are available when needed and are of the most current issue.