Configuration identification

6.2 Configuration identification

CID involves selecting the items to be configuration managed and giving each of them a unique identifier or name.

6.2.1 Configuration item

Each component of the software is a manageable configuration item. Each project will decide the level of component that will become the lowest managed item.

A configuration item (CI) is any product-any component of the software, documentation, code, and in some cases storage medium (e.g., memory chip)-that has a unique CID. Thus, CID can be applied to everything produced during the software life cycle. In fact, for most large-scale software systems, this is true. Compilers and assemblers usually are constructed so as to append an updated CID to each new assembly or compilation.

Each CI must have a unique identifier to differentiate it from all of its predecessors and successors. The identifier should show the CI's parent; that is, the next higher level of configuration and the specific issue at this level. There must also be a clear indication of the status of the CI. The CID must at least show the release and version and, if used, the edition of the CI. In documentation, this is generally a simple document name followed by an issue indicator. For code CIs, it is much more important to show the sequence of compilation or assembly, so that work may be performed on the most recent or up-to-date instance of the CI. As integration proceeds and delivery is made, the situation becomes more critical. The software system being tested must be exactly known, down to the unit level, so that when changes are made, only the correct instance of each component is affected.

In the simplest form of identification, each CI is sequentially numbered, starting with 1 and continuing until the last CI has been created. This system does fulfill the requirement of unique identifiers for each instance of each CI, but there is little intelligence contained in the name. Clearly, a table of numbers versus the CIs would be needed to be able to tell which product was which. This base-level naming scheme would be suitable for only the smallest of software projects. In a slightly more informational scheme, a date and time-of-creation tag could be used. This scheme presumes that two CIs cannot be created at the same instant. As in the case of the sequential numbering approach, though, a table showing the correspondence between a specific name and the exact CI to which it applies will be required.

Figure 6.7 depicts two examples of simple schemes, as well as a much more elaborate identification scheme. This is more likely to be of the type most software projects would use. Each level of the system has its identifier included in the name. With some care, a certain amount of intelligence can be built into a naming approach such as this. The characters chosen for each of the level names can be related to the level so that the user can recognize products without an elaborate cross-reference table. Of course, if the number of CIs is large, a reference list may be necessary just to keep track of what the codes in each field stand for.

Figure 6.7: Naming schemes.

In any case, the CID must be suited to the software system being developed. Clearly, very large software systems will require more elaborate naming schemes than very small systems. Further, the CID should, to the extent possible, be based on a standard CID method throughout the organization. Using a single scheme throughout the organization makes it easier for the CM practitioner to operate on more than one project at a time. Having a separate naming approach for each project, or even groups of several projects, may increase complexity unnecessarily.

6.2.2 Release

A release is a major instance or issue of the product. Releases usually occur at a milestone point and often are the baseline of the product as defined at the milestone. Once the software is placed into operation, a release represents an entire new issue of the software product. The term release is usually applied to the reissue of a product at its highest level.

6.2.3 Version

Each time a component is formally reissued, recompiled, or assembled for inclusion in its parent, a new version of all higher-level components is created.

The concept of version is usually rather subjective and is reflective of the needs of the organization and the project. In general, a new version is created anytime there is a major update to a component. A revision to a document is usually considered to be a new version. (This is a smaller case than the release, which is the issuance of the document with all revisions to all components fully integrated.) A new compilation of a code component for inclusion in the next higher-level component is also generally considered to be a new version.

Each component of the system, down to the unit level, may be considered to be a replaceable part of the whole. A code CI at the unit level is a part of a code CI at the module level. A module is a part of a subsystem, and so on. There is a less clear inclusive relationship between documents, but the same principle applies. A design specification describes the detailed response to some portion of the requirements. When the design changes, there may be an impact on the related requirements. Within a document, a chapter or major section is clearly a part of the whole document.

When a large number of changes (and this is a subjective term, sometimes determined by an arbitrary standard suitable to the software of the organization) are made as a group, a new version is created. This is often associated with a set of changes to a functional aspect of the software. For example, if a new module is introduced into a subsystem, a new version of the subsystem is created. If a new chapter or major section of a document is inserted, there is a new version of that document. Changes that correct defects but do not change the basic design or functional intent of the component might not cause the designation of a new version.

6.2.4 Edition

Some organizations may find it useful to define a third level of product instance, called the edition. Each time any component of the system is recreated, a new edition is formed.

The creation of a new edition is any action that changes any component of the system. While this is a true statement, not all projects or organizations use this concept for CID. On small projects, it is sometimes not worth the extra effort to manage the configuration at this level. In most cases, though, the information is available if it is wanted. Most compilers and assemblers now include some type of new edition indication as a part of their normal processing, even if it is only a date and time record.

The use of the edition is important when working with larger systems, since several editions of the whole system may exist at any one time. Remember that any variation in any component is also a variation in every superior level of which that component is a part. Thus, if a change is made to a unit, that change must be reflected in the CID of every level above that unit all the way to the system level if integration is in progress.

At some point, there are sufficient editions present within a version to make the creation of a new version appropriate. Thus, a new issue of the component will be made with the version identifier increased and the edition identifier reset to its starting point. The new version will also cause ripples up through the system, since its change must be reflected by all components of which it is a part. Whether the superior components become new releases, versions, or editions is a decision based on the overall CM philosophy for the project or the organization.