Software Configuration Management

Software Configuration Management

Software Configuration Management (SCM) is the discipline whose objective is to identify the configuration of software at discrete points in time and to systematically control changes to the configuration for the purpose of maintaining software integrity, traceability, and accountability throughout the software life cycle.

Goals & benefits of SCM

The main goal of SCM is to identify, control, maintain, and verify the versions of software configuration items. Babich (1986) argues that the art of SCM lies in the coordination of the software evolution process, by which confusion and resulting mistakes are minimized, and productivity is maximized.

The goal of SCM benefits the organization in four major ways (Futrell et al., 2002):

• Control: SCM offers the opportunity to review, approve, and incorporate changes to the configuration item. It provides a standard method for traceable and controlled changes to the baseline-version of a configuration item.
• Management: SCM provides a process of automatic identification and guidance of configuration items in their whole life cycle.
• Cost Savings: Using SCM, cost savings can be realized throughout the whole life cycle of a configuration. By actively defining, tracing, and auditing configuration items, failures can be detected early, and corrective action can be taken. No confusion in task division can occur.
• Quality: Deliverables are checked continuously during the software development process. By checking the human-work in an automated way, the level of compliance of deliverables with predefined requirements can be maximized.

Overview

Figure 1: Main activities in the SCM Process

The SCM process can be generalized as depicted in figure 1. This diagram consists of the six main activities of the SCM process, on which will be elaborated in the next section. It makes clear that the initial step creates the context of all following activities. Also, Software Configuration Identification is relevant for the whole process. Notice that the process between Software Release Management & Delivery and Software Configuration Control is iterative.

Figure 2: Process-data diagram for SCM

A more comprehensive view on the SCM process is obtained by summarizing the topic in a process-data model (Saeki, 2003). This overview (figure 2) is created using the meta-modelling technique. Next to the main activities (figure 1), also sub-activities are given. Both are recognizable as rounded rectangles and displayed at the left side of the diagram (meta-process model). This representation is using the modelling language of activity diagrams (part of UML). The activities are primarily based upon the SWEBOK SCM process description (Scott & Nisse, 2001). The SWEBOK process is in main lines compatible with other influential SCM process outlines, like the Military Standard 61A (Department of Defence USA, 2001), and the ISO 10007 standard (ISO, 2003). The roles of parties involved are given between brackets. The order of activities is not fixed, and the presented sequence gives only an impression of the most logical order for conducting the steps.

At the diagram’s right side the main concepts and deliverables are given as rectangles (meta-data model). The right side uses the modelling grammar of class diagrams (also part of UML). For both sides of the diagram the style of the shapes has got the same meaning. Plain boxes represent simple concepts or activities, dark-mirrored boxes represent closed concepts or activities (irrelevant sub concepts are neglected), while open-mirrored boxes represent open concept or activities (relevant sub concepts are given).

Next, in the ‘Activities’ section the actions performed in each phase are explained. Then the ‘Roles’ section describes the responsibilities of all involved roles. The main concepts are explained in ‘Concepts’ section.

Activities

The process-data diagram (figure 2) describes the activities of the SCM process at her left side, represented by rounded rectangles. This section elaborates on those activities in order to make clear what happens at each stage. The division of activities is mainly based upon the SWEBOK Software Configuration Management description (Scott & Nisse, 2001). A comprehensive list of activities and sub activities, including a short definition, is given in the appendix.

Management of the SCM process

The initial phase of the SCM process considers the context wherein the process has to occur. To plan this process it is essential to know the organizational structures and their relationships. Sometimes the software development process is conducted parallel to hardware or firmware development or selection procedures. It is necessary to have a good overall picture of those related items before the SCM planning is conducted.

The next sub activity gathers the available guidelines and constraints for the SCM process. Guidelines can come forth of standards or preferences from the customers. Constraints may be corporate policies or contracts with stakeholders.

Based on the context, constraints, and guidelines a sound SCM plan (SCMP) could be created. In this plan the objectives of the other SCM activities, which will be discussed later on, will be determined. Other issues to be addressed are responsibilities for tasks and organization, planning and scheduling of resources, use of SCM tools and their implementation, decisions about third parties, vendors or subcontractors to be involved, and finally the identification and control planning of interfaces to external components.

The execution of this SCMP should be supervised. There are SCM tools which are capable to support the process control task. Surveillance leads to further SCM process optimization by continuously process improvement.

Software Configuration Identification

The goal of this activity is to identify the software items that need to be controlled. This is based on the product structure modelling process. This is the process of breaking down the product (baseline) into several parts and items (software configuration items). Also, identification schemes are created for configuration items and their versions (part of version & variant management). Tools should be selected and implemented in order to acquire and manage the controlled items. This phase is repeated as new items need to be created during the SCM process. It is essential to understand the whole software configuration, in order to successfully identify and describe relations between configuration items. Fundamental for this phase are the procedures to define a baseline-version of an item.

All the controlled items should be stored in a central software library. This centralized space keeps track of all versions and documentation of related software configuration items.

Software Configuration Control

This phase concerns the management of changes to configuration items during the software product life cycle. The process starts when new changes are identified with a change request (essential part of change management). During the whole software product life cycle, change requests can be initiated by users and developers of the software. A standard procedure for handling change requests should be created. This document should describe the formal procedures for the deposit and recording of change requests, for the evaluation of costs and impacts, and finally for the acceptation, modification, or rejection of those requests. When the change request is approved by the Software Configuration Control Board, an implementation plan is created. This plan describes the procedures how the change requests are converted into a tangible solution.

Sometimes there are constraints in the software development process for which no satisfying solutions can be found at that point in the software life cycle. Then, deviations and waivers should be created.

Often the basic software building blocks are used for several related products of a manufacturer. In that case this phase of the SCM process is more complicated due to proper product family modelling.

Software Configuration Status Accounting

To control the configuration items, it is essential to record and report about the current state of affairs. An automated system will be used to capture and report all relevant information during the life cycle of a software configuration item.

The collected information will be used as input for the development team, the maintenance team, project management, and quality assurance activities. Reports can be periodic or ad-hoc. This feedback can be used to improve the system.

Software Configuration Auditing & Validation

Software is subject to many regulations, guidelines, constraints, plans, and procedures. On a regular base this compliance should be checked by a software audit. This activity covers an independent evaluation of the conformance of the configuration item under study. Audits are conducted following standard (detailed) process descriptions.

There are three fields of interest for audits: functional configuration, physical configuration, and in-process audits of the software baseline. The functional configuration audit concerns the question if the item is similar to the prevailing specifications. The physical audit considers if the technical documentation is consistent with the built software. The last form of auditing, in-process of baseline, investigates the status of several elements of the configuration. The main purpose of this last audit is to check if the current baseline meets the specifications.

Software Release Management & Delivery

This last phase of the SCM process is dedicated to the release of a version of a software product. The correct baseline, composed of baseline versions of configuration items, is compiled to an executable program. This executable can be delivered to any recipient, for purposes of testing or distribution to the customer. Specific build instructions are needed to guarantee that the build steps are taken and that they are performed in the right sequence. Sometimes different versions of the same product should be built (for platform, customer, functionality, etc.). The area of software engineering concerned with this process is build management.

When an executable program is created, the program should be delivered. This can occur to external or internal customers. Internal customers are just interested in the file and technical documentation. For external distribution some additional steps should be taken, such as inserting a manual, release notes, and put it in a box. The topic on Release Management elaborates on this activity in more detail.

Roles

In figure 2 the roles involved in each activity are given between brackets. In total four different roles can be identified in the SCM process. Only the managerial roles in the process are discussed.

Software Configuration Management Group (SCM Group)

The Software Configuration Management Group has to define the inventory of software and related documents to be controlled during development. Also the baseline versions which are in use at the beginning of the project are identified. New releases of an application are updated in the software library.

The SCM Group is appointed by the Project Manager, and has a key role in the Software Configuration Identification phase.

Project Manager (PM)

The Project Manager is most actively involved in the first part of the SCM process. The first tasks are to assist the SCM Group with the identification of the initial software library. Also, the Software Configuration Management Plan is written by the Project Manager. This person keeps control over the whole process.

The Project Manager is involved in all SCM phases, but is primarily focused to Management of the SCM process, Software Configuration Identification, and Software Configuration Status Accounting.

Software Configuration Controller (SCC)

The Software Configuration Controller (SCC) has a central role in the SCM process. Firstly, he assists and leads the SCM Group. After identifying the baseline of the software library, the SCC is further responsible for updating the library. So, inserting new or changed items and the check-in/check-out processes are conducted by the SCC. Also, the initial implementation of the software library management system is performed under the responsibility of the SCC. The SCC performs audits on new versions and defines baseline candidates. The SCC also controls the Release Management process for building and releasing new applications.

The SCC is involved in the Software Configuration Identification, Software Configuration Control, Software Configuration Auditing & Validation, and Software Release Management & Delivery. The SCC is appointed by the Project Manager.

Software Configuration Control Board (SCCB)

The Software Configuration Control Board (SCCB) is responsible for the authorization of new baseline versions. They review baseline candidates (identified by SCC), and approve all changes to configuration items. They also approve the SCM Plan and separate the whole software project into several components which are assigned to project managers. The SCCB has to approve any new release proposed by the SCC.

The SCCB is involved in the Management of the SCM Process, Software Configuration Identification, Software Configuration Control, and Software Release Management & Delivery.

Concepts

Some concepts are identified at the right side of the process-data diagram (figure 2). Those concepts are represented as rectangles. Now the most important concepts are addressed and those not already present in Wikipedia are explained. In the appendix a comprehensive list of concepts, including a short definition, is given.

• AUDIT REPORT: Document containing the evaluation of the conformance of software product and processes to the applicable regulations, standards, guidelines, plans, and procedures (Scott & Nisse, 2001).
• BASELINE
• CHANGE REQUEST: A petition for modifying the behaviour of a system due to normal business changes or because there is a bug in the system (TheFreeDictionary.com).
• CONFIGURATION ITEM (= Controlled Software Configuration item)
• CONFIGURATION STATUS DOCUMENT: List with all relevant information concerning the identified software configuration item(s) (Scott & Nisse, 2001).
• CONFIGURATION STATUS REPORT: Summary of configuration status information for a specific information need (Scott & Nisse, 2001).
• DEVIATION: Authorization to depart from a provision prior the development of the item (Scott & Nisse, 2001).
• EXECUTABLE FILE
• IMPLEMENTATION PLAN: Document that outlines how the requests should be implemented and when (Scott & Nisse, 2001; edited).
• IN-PROCESS REPORT: Summary of the audit performed during the development process aimed at investigating the current status of specific baseline elemements of a software configuration.
• RELEASE
• RESULT REPORT: Summary of the audit performed at a (controlled) software item (Scott & Nisse, 2001).
• SOFTWARE ADAPTATION: Resolvement of provisions that cannot be satisfied at the designated point in the life cycle (Scott & Nisse, 2001).
• SOFTWARE CHANGE DOCUMENT: Document specifying the approved changes to be made in a system (Scott & Nisse, 2001; edited).
• SOFTWARE CONFIGURATION MANAGEMENT PLAN: Living document that serves as a reference for the SCM process (Scott & Nisse, 2001).
• SOFTWARE LIBRARY
• TECHNICAL SOFTWARE DOCUMENTATION
• VARIANT: New version of an item that will be added to the configuration without replacing the old version (Scott & Nisse, 2001).
• VERSION
• WAIVER: Authorization to use an item, following its development, which departs from the provisions in some way (Scott & Nisse, 2001).

Example

Software Configuration Management is known as a very complicated process to understand. Therefore a practical example of a tangible product can enlarge the insight of the practitioner. The next steps are a walkthrough through the SCM process for the firmware of a mobile phone. The process is graphically illustrated in figure 3.

Figure 3: Mobile phone example of the SCM process

• Management of the SCM Process: The goal of this project is to design a single firmware platform for a family of mobile phones of one manufacturer. Functionality and time are given as constraints for the project. Guidelines are retrieved from earlier firmware development processes, for example that a small core-functionality should be designed first, which is extended with more functions afterwards. The SCM plan is created. It describes which activities should be performed, and also procedures for some sub-activities are defined.

• Software Configuration Identification: A basic set of software artefacts are identified as configuration items. In this example one could think of classes for the mobile OS. The company selects IBM Rational ClearCase as the SCM tool, and implements a compatible software library to store the configuration items, their versions, and technical documentation. Relationships between objects in the software library are identified.

• Software Configuration Control: An external actor, e.g. a customer, complains about a bug in the firmware. This complaint is converted into a change request, which is approved by the SCCB. The required changes are implemented into the old version, and a new version is placed into the software library. The ‘Configuration Identification’ phase is now repeated to check if this version should be stamped as new ‘baseline-version’.

• Software Configuration Status Accounting: The project manager keeps track of the development process. He frequently creates reports with status information. When he identifies shortcomings, or interpretation failures, he directly gives feedback to the responsible software developers to correct it.

• Software Configuration Audit & Validation: An independent body of software engineers frequently audits the new software versions, and validates if those versions are confirm the prevailing regulations and guidelines. For example, if the requested Bluetooth-functionality is only available to the intended mobile phones in the product family. The audit team can consist of engineers from another project team (e.g. other mobile phone family).

• Software Release Management & Delivery: The project manager can identify a ‘release-ready’ baseline during the ‘Configuration status accounting’ phase. When that happens, it is time to build the executables of the firmware’s for each mobile phone in the product family. After building, internal tests at the manufacturer can be conducted, where after external delivery consist of nice looking boxes, user documentation, and the phone including software.

See also

• IBM Rational ClearCase Redbook: Standard procedures and descriptions of the well-known ClearCase SCM method.
• USA Military Handbook on Configuration Management (2001): Another standardized process for SCM. Mainly matches with the general process identified here.

References

• Babich, W.A. (1986). Software Configuration Management, Coordination for Team Productivity. 1st edition. Boston: Addison-Wesley

• Bersoff, E.H. (1997). Elements of Software Configuration Management. IEEE Computer Society Press, Los Alamitos, CA, 1-32

• Dennis, A., Wixom, B.H. & Tegarden, D. (2002). System Analysis & Design: An Object-Oriented Approach with UML. Hoboken, New York: John Wiley & Sons, Inc.

• Department of Defense, USA (2001). Military Handbook: Configuration management guidance (rev. A) (MIL-HDBK-61A). Retrieved February 18, 2006, from http://www.combatindex.com/mil_docs/html/hdbk/0100/MIL-HDBK-61.html

• Futrell, R.T. et al. (2002). Quality Software Project Management. 1st edition. Prentice-Hall.

• International Organization for Standardization (2003). ISO 10007: Quality management systems – Guidelines for configuration management (preview). Retrieved February 18, 2006, from http://www.standards.com.au/PDFTEMP/Previews/OSH/iso/updates2003/07/ISO_10007;2003(E)-Character.pdf

• Saeki M. (2003). Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. CAiSE 2003, 374-389.

• Scott, J.A. & Nisse, D. (2001). Software configuration management. In: Guide to Software Engineering Body of Knowledge. Retrieved February 15, 2006, from http://www.swebok.org/stoneman/version_1.00/SWEBOK_w_correct_copyright_web_site_version.pdf

Appendix: Activity & Concept definitions

Next the comprehensive activity (table 2) and concept (table 3) tables are presented. The activities and concepts are mainly derived from Scott & Nisse (2001).

Table 2: Activity table

Table 3: Concepts table