CM components

6.1 CM components

Traditionally, CM has included identification of the items to be configuration managed, control of the changes to the identified items, and maintenance of the status of each item.

6.1.1 Configuration identification

CID permits unique and uniform naming of each component and product of the total software system down to the lowest separable level. Any system, including software systems, is separable into smaller and smaller parts down to some desirable, manageable level. In this book, the lowest level of a software system-that is, the smallest component that can be assembled or compiled-is called the unit. Increasingly larger components are the module, the subsystem (there may be more than one level of subsystem depending on the size of the system), and finally the system itself. The documentation goes through a similar separation from the original requirements statement to the individual module and unit design specifications, the code, and the test procedures.

Each of these subdivisions, code components, and documents will go through multiple issues as they are developed. The primary issue usually is called a release. This is a formal issue and usually represents a baseline. After a release is issued, updates are made. These are often called versions and represent significant changes to the release, but not wholesale modification or replacement.

Finally, in some large systems, there may be reissues of versions that may be little more than recompiles, or document updates to make editorial or minor corrections. These low-level issues may be called editions, patches, dot releases, or any other name with meaning to the organization. Note that the actual terms used are up to the organization. As in most areas of software engineering, there are no industrywide standard names for these levels of products. Figure 6.2 shows an example of a hierarchical structure of these product levels.

Figure 6.2: Product levels.

It is clear that the management of all of these subdivisions and issues is critical to the development and delivery of a quality software system. The first step in the CM of all the various subdivisions and issues is to give each of them a unique identifier. This is the role of CID.

As each product-a component of code or a document-comes into being, it must be assigned an identifier that will depict its instance, its parent (the next larger component of which it is a part), and its age (when it was created). In this way, users of the product can be sure they have the exact issue that is appropriate for their use. As shown in Figure 6.2, each level carries the name of its parent for continuity in identification. Not all identification schemes carry this information, as will be seen in Section 6.2.1.

6.1.2 Configuration control

CC ensures that all-and only-approved changes are made to the baseline. Having established a given baseline, all changes must be acted on with increasing formality and control. Early in the development, there are normally few products to consider as changes are perpetrated. There is, for example, usually only one requirements document. Changes to that one document, early in the requirements phase, may be easy to track and record, and so may require less formal control than the entire system during acceptance testing. As the system becomes more and more subdivided into its lower-level products or component parts, defects become more expensive to correct. Therefore, control of changes becomes more stringent.

When the software system is under formal CM, changes are proposed in a formal manner (e.g., a change request form or a software trouble report). These requested changes are reviewed by a software CCB that evaluates such things as impact on other software components, cost, and schedule. Approved changes are then prepared and tested, and, if successful, are implemented into the affected component by means of an SCN (as described in Section 6.3.3). The SCN gives formal notice that the software or document has been changed. The SCN is also notification to the CA element that a change has been made to the current baseline.

It is the intent of all of CM, but especially CC, to be sure that the software products (the code and the documentation) stay in step with one another, and that no changes are made without proper consideration and approval. It is the software quality practitioner's role to verify that the CM program is sufficient to accomplish this task and that it is being followed.

6.1.3 Configuration accounting

CA maintains and records the status of each baseline and its history. It may also be called on to account for multiple instances of the products, such as those in Figure 6.2.

6.1.3.1 Baselines

The establishment of a baseline generally occurs as the result of a major phase-end review (see Section 3.3). The importance of a baseline is that it represents the starting point for all subsequent changes as the product evolves. As shown in Figure 6.3, five commonly recognized baselines should be established. These baselines and their phase-end reviews are as follows:

1. Functional (SRR);

2. Allocated (PDR);

3. Design (CDR);

4. Product (FA/PA);

5. Operational (implementation of system).

Figure 6.3: Common baselines.

Other, informal, in-process baselines may be established if they are necessary for a particular development consideration.

6.1.3.2 Instances

Instances of a product may occur when changes occur, variations evolve, or the software product exists in multiple forms. The simplest of the instances are those that happen each time a product undergoes any change. Quite often, especially during the development of drafts of a document, these instances are not recorded and disappear. Only when CM is required do the instances take on names and recorded existence. New instances arising from the modification of an existing product-usually as a result of correction or enhancement-are called successors. Figure 6.4 depicts the creation of a successor.

Figure 6.4: Successors.

When different installations of the software system require minor variations in the functional or other requirements, but the basic system is intact, variants are created, as depicted in Figure 6.5. CM of variants is extremely important in situations such as the same software running on various platforms and having to perform identical functions with slightly different, platform-dependent differences. Another instance of variants might be the weapon system software running on identical computational platforms but on different weapons platforms such as aircraft versus shipboard installations. GUIs and client-server installations often need slight modifications to permit implementation on multiple hardware configurations without affecting the users' perception of software performance.

Figure 6.5: Variants.

Equivalents are multiple instances of a product in which the content is identical. Equivalents are normally associated with multiple copies of a product, such as purchased applications that are reproduced on discs or other media. Equivalents are also created when a document or software application is copied from a floppy to a hard disc, for example. The specific medium of the equivalent is not a factor, other than to those customers who want a specific medium. The key to equivalence is identical content, not medium. Figure 6.6 shows equivalents on various media.

Figure 6.6: Equivalents.

CA keeps track of the instances of the individual products and their relation to the established baselines. It also records which smaller or lower-level components comprise each higher-level component; that is, which specific units go together to make up which specific module. Further, CA records all approved changes made to the current baseline. Accounting for all approved, but outstanding, changes is also provided. In this way, the CM requirement for providing for reconstructability is met.