Configuration accounting

6.4 Configuration accounting

Baselines mark major CI status levels of the software. However, while the creation of baselines is of major importance in CA, the baselines only form the basis for the actual accounting process.

6.4.1 Baselines

As shown in Figure 6.3, several baselines can be identified, but three (functional, design, operational) are the most common. Further, each baseline usually is associated with a major review marking the end of an SDLC phase. Again, there is no industrywide standard for the names of the baselines. The names used here are common in the defense arena.

The functional baseline is established at the SRR. At this point in the SDLC, the requirements have been documented and reviewed, at the end of the requirements phase, for compliance with the criteria discussed in Chapter 3. The functions that will perform the processing necessary to achieve the requirements, in a hardware/software system, are analyzed and assigned to the hardware and software as appropriate. Documenting the software requirements specifies the tasks assigned to the software and what the software is going to do in performing those tasks.

The requirements are then allocated to functions, and the design process determines how each requirement is going to be fulfilled. This phase is typically called preliminary design and may not be necessary for simple software projects. When it is included in the system development methodology, it culminates with the PDR. The conclusion of the PDR results in the allocated baseline.

At the end of the full design phase, the code-to design has been completed. It is validated in the CDR that determines the design baseline. The design baseline determines the specification for the coding activities.

Prior to acceptance testing on which user approval of the product is based, an analysis of the results of all preceding testing is performed. Upon the satisfactory completion of this TRR, the product baseline is established. The product baseline is that instance of the software that will undergo acceptance testing.

Upon completion of acceptance testing, completion of the FA and PA, and installation of the software, the operational baseline is established. This baseline identifies the software as it is going to be delivered to the user or customer. It is occasionally called the as-built baseline, since it represents the actual system being delivered. (This is frequently not the system that was originally specified in the initial requirements documentation.) After installation of the software system, the operational baseline will continue to evolve as the software is maintained and enhanced throughout its useful life.

Other baselines have various names and are instituted for specific purposes within the organization. There are no hard and fast rules about how many baselines there should be (other than those that are called out in software development contracts). Each project or organization will determine the applicable level of control needed for the project and will then impose those baselines that fulfill the control needs.

Baselines are defined so that change control may be instituted. The baseline reflects all previous changes to the given CI and determines the point of departure for all subsequent changes to that CI. It is a fixed reference point, and all changes are made to that reference point. As CM is imposed with increasing rigor, the baselines become more important as well. It is obvious that if the basis for changes is not known, there is a good chance that the wrong component or instance of the component will be changed. There is also the danger that two changes may be made to the same part of a component without the knowledge of each other.

6.4.2 Accounting

Given the baselines and the imposition of CC, the CA element keeps track of the status of the software as it goes through the SDLC and operation. Records of all changes, reviews, and action items affecting the configuration of the software are maintained by CA.

CA must monitor such things as the baselines themselves, where and how they were established, and by whose authority. CA maintains the records of changes made to the current baseline and notes the date of the change request, action of the CCB, status of the change in progress, and data about the ultimate installation of the change.

6.4.2.1 Instance collaboration

An important record maintained by CA is the exact composition of each instance of each software component. The name, release, version, and edition of each product and each of its subordinate components is closely monitored so that when changes are made, all CIDs of affected components can be updated. Not only is this important in the changing of software components, but it is critical to the coherence of the testing and delivery activities. To test and accept one version of a component and then deliver a different version is not conducive to quality software development or installation.

Figure 6.9 depicts a situation in which different versions of products were delivered. In this case, without more information, the user would not know whether the products were internally consistent or not. Rigorous CA will lessen the likelihood that incompatible instances of related software products will be delivered and used.

Figure 6.9: Mismatched products.

6.4.2.2 Instance tracking

As newer technologies, such as client-server, are implemented, the role of CM, and especially CA, becomes even more important. In the mainframe environments still in use throughout the world, most software products exist in only one or two instances. CM is important but not as heavily taxed as in the newer, distributed information processing installations. It is critical to keep track of environmental software such as operating systems, languages, database managers, and so on so that applications will be subject to the environments for which they were prepared.

Multiple application instances are also frequently present in distributed systems. CM, and particularly CA, must ensure that the expected instances of processing applications are called by the user. Maintenance of the environments and applications also depend on CM to ensure that modifications are correct for the product concerned and are applied to the intended products. Coordination of modifications between variants of products becomes a serious concern, especially as distributed and client-server processing and e-commerce applications become the norm.