3.3 Related domains

---

3.3.1 CM

CM manages both hardware and software and is therefore more general than SCM, which, historically based on CM, is more closely focused on specific software support. CM was developed before SCM, and its original focus was on manager support rather than on developer support.

From a management perspective, CM directs and controls the development of a product by the identification of the product components and the control of their successive changes. The objective is to document the composition and status of a defined product and its components, to publish this to ensure that the correct working basis is being used, and that the product is being composed correctly. One example of a definition supporting this discipline is ISO 10 007, which states that the major objective of CM is “to document and provide full visibility of the product’s present configuration and on the status of achievement of its physical and functional requirements” [18]. Many other standards [4, 18, 21–23] also define CM as consisting of four activities, or areas of responsibility. These are (according to ISO 10 007):

• Configuration identification. This consists of activities comprising determination of the product structure, selection of CIs, documentation of the physical and functional characteristics of the CI (including interfaces and subsequent changes), and allocation of identification characters or numbers to the CIs and their documents.

• Configuration control. This consists of activities comprising the control of changes to a CI after formal establishment of its configuration documents. Control includes evaluation, coordination, approval or disapproval, and implementation of changes. Implementation of changes includes engineering changes and deviations, as well as waivers with impact on the configuration.

• Configuration status accounting. This is formalized recording and reporting of the established configuration documents, the status of proposed changes, and the status of the implementation of approved changes. Status accounting should provide information on the relevant configurations and all deviations from the specified basic configurations. In this way, the tracking of changes in relation to the basic configuration is made possible.

• Configuration audit. This is an examination to determine whether a CI conforms to its configuration documents. Functional configuration audit is a formal evaluation to verify that a CI has achieved the performance characteristics and functions defined in its configuration documents. Physical configuration audit is a formal evaluation to verify the conformity between the actual produced CI and the configuration according to the configuration documents.

The problems and solutions associated with SCM are almost the same as those associated with CM. However, there are some additions, and some parts are more important when managing software than when managing other items (e.g., hardware). One difference between software and hardware may be that for software, the model used during development is almost the same as the product delivered, which is not the case for hardware (a design is not the same as the product produced following the design). Another difference is that the transition from the design phase to the production phase is less clearly defined in software development and often the same person or team is involved in both. As compared with hardware, it is easier to build the software product from the model (it is automated). Also, developers may be tempted to introduce changes close to the point of release, which may cause problems. In addition, a lexically small change may have a considerable effect on the behavior of the product. For these reasons, SCM has focused particularly on problems related to changes (e.g., version control and change management).

3.3.2 Document management

Documentation is an important part of software development. In many of the SCM procedures, documents are treated as any other item. They are under the control of version, change, and release management in the same way as source code or any other type of file. However, the processing of documentation is somewhat different from the development of software. The build process is of no interest for document management, but other parts that are specific to document management are not present in SCM tools. In SCM tools, there is no advanced search capability; comparison and merge functions usually do not work for documents because of their internal format; and Web management is not part of SCM. It is questionable whether documents should be under the control of SCM instead of, as an alternative, under document/content management tools or under a PDM system. Although many companies keep documentation separated from software, others keep the documentation under SCM control. There are several reasons for this—companies may not be able to afford the costs of additional resources or the developers may want to work in an integrated environment, with documents treated in exactly the same way as other items and available in the same place. In the latter case, it is more a question of the possibility of integrating these tools. When tools are properly integrated in a common environment (this depends on the integration capabilities of the tools and the environment), the users should not be aware of any difference when using different tools.

---