8.3.1 CM According to ISO 12207

According to the ISO 12207 standard, the purpose of CM is to [ISO 17]: manage and control system elements and configurations over the life cycle. CM also manages consistency between a product and its associated configuration definition. SCM is part of SQA practices. SQA must give assurance that processes and products used in the development life cycle meet their requirements by planning, using and executing activities that ensure that quality is integrated in the final product during its production. The SCM activities help SQA meet its goals and the goals of the project. It is recommended that it be used by every software project, maintenance activity as well as for its infrastructure.

ISO 12207 defines the requirements of CM as an essential process for software developers. We will not describe the detailed requirements here but provide only a high-level description and focus on the expected results of using this process.

As a result of the successful implementation of the CM process [ISO 17]:

• – items requiring CM are identified and managed;
• – configuration baselines are established;
• – changes to items under CM are controlled;
• – configuration status information is available;
• – required configuration audits are completed;
• – system releases and deliveries are controlled and approved.

The six activities of the ISO 12207 CM process are [ISO 17]:

• – plan CM;
• – perform configuration identification;
• – perform configuration change management;
• – perform release control;
• – perform configuration status accounting;
• – perform configuration evaluation.

The six CM activities of ISO 12207 are composed of 19 tasks that are not described here. The last activity, however, includes audit configuration tasks that are described later in this chapter.

CM in ISO 12207 is also applicable to maintenance, hardware and base software. The maintainer will implement or use the CM process for managing modifications to the existing system. The scope also recommends that the configuration of the infrastructure should be planned and documented as well: the infrastructure (e.g., software tools) shall be maintained, monitored, and modified as necessary. As part of maintaining the infrastructure, the extent to which the infrastructure is under CM shall be defined.

8.3.2 CM According to IEEE 828

IEEE 828 is the IEEE Standard for Configuration Management in Systems and Software Engineering [IEE 12b] and provides the requirements and the details concerning the SCM process. IEEE 828 also supports the ISO 12207 standard. It states the minimum acceptable requirements for CM in both systems and software. Consequently, it applies to all class/type of systems or software.

IEEE 828 describes the CM activities to be performed at what point of the life cycle and describes planning and the required resources. The standard details the items that should be included in a CM plan and are aligned with ISO 12207 (for software engineering), ISO 15288 (for systems engineering), and ISO 15939 (measurement standard presented in a later chapter). According to IEEE 828, the purpose of CM is to [IEE 12b]:

• – identify and document the functional and physical characteristics of a product, component, output or of a service;
• – control any changes to these characteristics;
• – record and report each change and its implementation status;
• – support the audit of the products, results, services, or components to verify conformance to requirements.

IEEE 828 also specifies [IEE 12b] that CM establishes and protects the integrity of a product or product component throughout its lifespan, from determination of the intended users’ needs and definition of product requirements through the processes of development, testing, and delivery of the product, as well as during its installation, operation, maintenance, and eventual retirement. In so doing, CM processes interface with all other processes involved in the product's life.

8.3.3 CM According to the CMMI

The CMMI-DEV has a process area named “configuration management”. The purpose of this process area is to [SEI 10a]: establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. This process area describes the following activities be conducted [SEI 10a]:

• – identifying the configuration of selected work products that compose baselines at given points in time;
• – controlling changes to configuration items (CI);
• – building or providing specifications to build work products from the CM system;
• – maintaining the integrity of baselines;
• – providing accurate status and current configuration data to developers, end-users, and customers.

These CMMI activities apply to both systems and software engineering. The following text box describes the specific goals (SG) and specific practices (SP) of this CMMI process.

Figure 8.1 shows a graphical representation of the CMMI recommendations for CM.

8.4.1 Organizational Context of SCM

In large organizations, the responsibility for SCM is often assigned to a separate department. In small organizations, the SCM tasks can be shared with developers performing software development tasks. Software is often developed as part of a system including hardware, software, and documentation. SCM activities included with project team responsibilities will need to align with the infrastructure CM (e.g., hardware and software). In this chapter, we will only focus on SCM.

SCM constraints that can make it difficult to meet these obligations originate from many situations. Published policies and procedures could impose or influence the use of SCM in projects. In the case of acquisition of software, an agreement or a contract may contain specific SCM clauses.

When software products planned to be developed may present safety issues, external regulating authorities and standards will likely impose the use of SCM.

Examples from the medical devices sector were described in Chapter 2 (Therac-25), however, similar problems can be happening right now all over the world in other domains such as avionics, nuclear energy, automobiles and banking, just to name a few.

8.4.2 Developing a SCM Plan

A SCM plan is typically developed during the planning of a project. It should be ready and approved by the time the project reaches the end of the software specification stage. During planning, the following should be considered: a list of SCM-related activities, the work and role assignments, the required resources and schedule, the choice and installation of tools, and the identification of supplier responsibilities.

The planning outputs will be placed in a separate SCM plan or in a section of the project planning documentation for agile projects and will be typically accessible for SQA review/audit. IEEE 828 [IEE 12b] defines six SCM information categories to be placed in the SCM plan (adapted from [IEE 12b]):

1. Introduction to the plan (the purpose, scope, and terminology);
2. SCM management (organization, responsibilities, authorities, applicable policies, guidelines, and procedures);
3. SCM activities (configuration identification, configuration control, and other activities);
4. SCM schedule (identification of the SCM activities in the project schedule);
5. SCM resources (tools, servers, and human resources);
6. SCM maintenance and updates.

IEEE 828 describes, in a normative annex, the content of a SCM plan. Following is a typical table of contents for a SCM plan:

• – introduction;
• – purpose;
• – scope;
• – relationship/dependencies with the organization and other projects;
• – references (e.g., policies, guidelines, procedures);
• – criteria for identifying which software elements will be placed under SCM;
• – description of the configuration to be managed;
• – development and testing configurations;
• – delivery configuration;
• – configuration identifiers and assignment;
• – versions and fixes numbering rules;
• – source code branching strategy;
• – marking rules;
• – repository content, location;
• – library management project rules;
• – architecture;
• – procedures for the creation of the library;
• – recording of elements in the project library;
• – access rules;
• – backups;
• – archiving;
• – project library control;
• – planned baselines and states.

If the software is developed and maintained for many years, as for the controls for railway and planes, it is necessary to add:

• – the source of the modifications;
• – a formal modification procedure;
• – the tools that were used to develop the software;
• – the verification records.

Organizational units that have to be involved in the SCM process have to be clearly identified. Table 8.1 illustrates the assignment roles for the execution of SCM of a complex project involving many players.

Depending on the size of the project, the tasks listed could be managed by the project manager, whereas for very small projects, one or more different people could be directly involved.

Updates to the plan are approved when the need arises during development. Depending on the importance of the project, SQA can be done to ensure the plan is executed correctly. In more involved projects, SCM compliance audits can be called to ensure adherence to plans.

It can be a bit overwhelming to be assigned the development of a SCM plan for the first time. Most organizations have examples and templates that can be used to kick start this process. It is common to reuse the majority of sections of existing SCM plans in an organization. Therefore, SQA should ensure that the reference documents are of high quality so it can be reused in the future. Table 8.1 shows an example of SCM task allocations for a project.

8.4.3 Identification of CI to be Controlled

This activity aims at identifying which software elements will need to be controlled during the development and maintenance life cycle of the project to avoid creating elements without proper identification or links with other elements already identified.

The identification of CI requires: (1) an already established classification reference nomenclature for items and (2) a predefined list of planned baselines identified uniquely throughout the project schedule.

The definition of a baseline implies that a document or software product was approved following a formal review. It is then available to the customer or ready for another step in the development process. Baselines for the production of new versions are also used.

The different project artifacts are typically located in a document or on the project server in folders (see an example in Figure 8.2). This folder structure is often mandated by the SQA or the project office as good practice for all projects. We will see in section 8.8 that this structure can be repeated in all the branches of the CM repository. It is recommended that developers do not change this hierarchy so that it is consistent during the project and can also be compared with other projects.

8.6.1 A Simple Branching Strategy

This strategy is appropriate for simple cases, for the development of a website for example, and requires the creation of two types of branches (see Figure 8.6):

• – the main branch;
• – the versions branch.

This simple branching strategy proposes that the main branch is used by the developers of the software. It implies that the main branch must remain stable at all times as we are always in it. Once the software is quite advanced and the team wants to deliver a version to its client, a version branch is created (e.g., 1.0.1) that will contain a complete version of all artifacts from the first production version. On the main branch, the team can continue working and improving the software. Over time, the development team will be ready to deliver a subsequent release and create another release branch (e.g., 1.1.3) and this branch will become the new production version for the client. The previous branch can be kept as historical or may be archived given that the customer has been provided a new version.

This strategy is appropriate for the following conditions:

• – a very small team who works in the same location in order to communicate easily;
• – corrections to production software require a fusion to the main branch. These must be closely controlled because they are made directly within the development branch;
• – new version shipped from the main branch includes all previous changes from this branch.

8.6.2 A Typical Branching Strategy

This strategy responds to the needs of more than 80% of the SCM requirements for software projects. It requires the implementation of three branches (see Figure 8.7):

• – a main branch;
• – a development branch;
• – a production branch.

In this strategy, no one works directly in the main branch. It is only used for the integration of components from the team members. This strategy will force team members to work in the development branch. It is in this branch that most of the activity and changes will take place. The development team must control its content. As a general principle, components in a branch should always be able to compile without error. The main branch will receive an intermediary version from time to time that marks progress and can be used for demonstrations as well. Its rate of change will depend on the number of merges coming from development (typically every few days, but at least once a week). Finally, the version branch will also be quite stable as it contains the production version. This branch can be used to fix production problems but if it is changed, then someone must merge these changes to the development branch to ensure it is kept in sync. This strategy can be applied in the following situations:

• – delivery of a unique major version;
• – delivery of a major version at fixed intervals;
• – every new version delivered, coming from the version branch, includes all the changes from the previous versions.

8.7.1 Requests, Evaluation, and Approval of Changes

A change request management process, as shown in Figure 8.9, describes the typical sequence for processing a change request (called a ticket in some environments):

• – the customer (internal or external) or a team member submits a request;
• – a maintainer evaluates the priority, impact and cost;
• – the Change Control Committee (CCC) or Configuration Control Board (CCB) reviews and approves the change;
• – the change is made to the software and associated documentation;
• – the change is tested and approved by the end-user;
• – the change is moved to production or installed in a system and verified afterward;
• – the change request or ticket is closed and then later archived.

Note that the request will change state at each stage of this process (see Figure 8.9).

During the verification activity, developers and maintainers will also typically perform a series of regression tests to ensure that a change has no impact on other characteristics. Some automation servers, like Jenkins (https://jenkins.io/) or locally developed test robots are also used to perform accelerated regression testing.

Regarding critical software, it is common to add evaluation tasks to assess the level of risk for each of the proposed changes. Individuals who can conduct this type of risk evaluation will need to be invited to contribute to the impact analysis of this change request.

The notion of traceability was introduced in an earlier chapter. Traceability is also used in SCM to facilitate the impact analysis of a change request.

8.7.2 Configuration Control Board

Typically, the authority that can accept or reject a proposed change to a software is named a configuration control board (CCB) or a change management office. In smaller projects, this authority may be directly delegated to the project manager or a maintainer. There may be several levels of change authority depending on your organizational processes, the criticality of the software involved, the nature of change (e.g., impact on budget or schedule), or the current step of the life cycle of the project.

The composition of a CCB with respect to a particular project changes on a case by case basis depending on the criticality of the change. The project specialists, according to project size and criticality, may be asked to give their opinion at CCB meetings. In addition to the project manager, a SCM representative and even a SQA representative may be present to verify that the change process and CM plan are followed.

The main tasks of the CCB are: take a go/no-go decision, assign a priority, assign the change to a future version, answer request issuers, issue access rights to libraries and write a change order with decisions taken. The change request includes the following information: identification of the affected software, the list of items in a baseline to modify, SQA tasks to ensure quality checks, if any.

8.7.3 Request for Waivers

The constraints imposed during the development activities may lead to situations where some constraints may need to be relaxed to ensure the success of the project (e.g., a process is not adequate to meet project needs, a request for a non-compliance). A waiver may then be raised on project plans or obligations (e.g., agreement or contract) of the approved life cycle processes. A waiver is an authorization to depart from an obligation. When approved, it also allows the use of that item when completed although it does not meet all of its requirements.

A procedure for submitting and approving waivers should be described in the organizational processes.

8.7.4 Change Management Policy

A policy sets out general principles that have to be followed and are reflected in the processes and procedures of an organization. The elements of a change management policy are:

• – the original text describing a change request will not change or will not be deleted from the organizational repository;
• – each changed requirement will be traceable to an approved change request;
• – all changes to requirements should follow the SCM process. If a change request is not documented, it will not be considered;
• – a CCB is created for each project;
• – the contents of the change request library must be available to all project team members;
• – no design or development/maintenance work can be initiated on unapproved changes, with the exception of exploration or feasibility studies required by the CCB.

8.8.1 Information Concerning the Status of CI

Information concerning the state of configuration elements must be identified, collected, and maintained. The following information should be available to managers and developers: the approved configuration identification, as well as the identification and current status of changes, deviations and waiver approvals. SCM items are recorded in sufficient detail so that previous versions can be recovered when needed. Questions answered by the status of CI:

• – what is the status of item X?
• – was change request X approved or rejected by the CCB?
• – what has changed in this new version of this item?
• – how many defects were detected last month and how many are corrected?
• – what is the cause of this change request?

8.8.2 Configuration Item Status Reporting

Reported information can be used by various organizational units and the project team. The CMMI noted that this report typically includes [SEI 10a]:

• – the meeting minutes of the change management board;
• – the summary and status of change requests;
• – the summary and status of problem reports (including corrective measures);
• – the summary of changes to software repositories;
• – the revision history of CI;
• – the state of software repositories;
• – the results of audits of the software repositories.

Figure 8.10 shows the output of a tool that reports on CI.

8.9.1 Functional Configuration Audit

The objective of the FCA is to provide an independent evaluation of software products to verify that the actual functionality and performance of each configuration item is within specifications. FCA should be concerned not only with the functionality, but also with the non-functional requirements. FCA typically includes the following [KAS 00]:

• – an audit of test documentation and test results;
• – audit reports of V&V to ensure their accuracy;
• – a review of all approved changes to ensure they have been properly incorporated and verified;
• – a review of updated documents to ensure their accuracy;
• – a sampling of minutes of design meetings to ensure that all findings have been incorporated;
• – a sampling of performance and other non-functional test results for completeness.

FCA of the outputs of the design process verifies the following [IEE 12b]:

• – traceability between the design items and their sources (requirements);
• – every requirement is linked to at least one design element;
• – every design element is linked to at least one requirement that justifies it.

8.9.2 Physical Configuration Audit

The objective of the PCA is to provide an independent assessment of CI to confirm that each element that makes up the software as delivered is present and traceable to specifications [KAS 00]. This audit verifies that the software and documentation are correct, consistent and ready for delivery. The available documentation typically includes: installation manuals, operation manuals, maintenance manuals, and version description documents.

A PCA will typically include the following elements [KAS 00]:

• – an audit of specifications to ensure completeness;
• – a review of the problem reporting and change management process;
• – a comparison between the architectural design and components to ensure consistency;
• – a code review to assess compliance to coding standards;
• – audit documentation to ensure the completeness and compliance with the format and with functional descriptions. These manuals include user manuals, programmer's manual, and operator's manuals.

PCAs of the outputs of the requirements process in the life cycle verify the following [IEE 12b]:

• – requirements assets have been placed under configuration control;
• – requirements assets have been properly labeled in accordance with the CMP;
• – an inventory of requirements assets exists and correctly reflects the attributes of each CI;
• – there is evidence of the use of change control procedures for each of the changes made to previous baselines, if any (for example, in a previous iteration).

8.9.3 Audits Performed During a Project

These audits are required during the phases of design and development (before the PCA and FCA) to verify the consistency of the design during its evolution. These audits are performed [KAS 00]:

• – to verify that the interfaces between hardware and software comply with the design;
• – to verify that the code is fully tested and that business requirements are met;
• – to check whether the product design throughout the development meets the functional requirements;
• – to check whether the code adheres to the detailed design.

8.13 Further Reading

1. CASAVECCHIA D. Reality configuration management, Crosstalk, November 2002.
2. DJEZZAR L. Gestion de configuration: maitrisez vos changements logiciels, Dunod, Paris, 2003.
3. JOHANSSEN HASS A. Finding CM in CMMI, Crosstalk, July 2005.
4. LEISHMAN T. and COOK D. But I Only Changed One Line of Code!, Crosstalk, 2003.
5. PHILLIPS D. Go Configure, Understanding the principles and promise of configuration management, STQE, vol. 4, Issue 3, May–June 2002.
6. RINKO-GAY W. Preparing to choose a CM Tool, STQE Magazine, July–August 2002.
7. WIEGERS K. Creating a Software Engineering Culture, Control Change Before It Controls You. Dorset House, New York, 1996, Chapter 15.