Software Configuration Management

Chapter 8: Software Configuration Management

Acronyms

Acronym	Full Form
CCB	Configuration Control Board
CI	Configuration Item
CM	Configuration Management
CMDB	Configuration Management Database
CR	Change Request
FCA	Functional Configuration Audit
PCA	Physical Configuration Audit
QA	Quality Assurance
SCCB	Software Configuration Control Board
SCI	Software Configuration Item
SCM	Software Configuration Management
SCMP	Software Configuration Management Plan
SCR	Software Change Request
SCSA	Software Configuration Status Accounting
SQA	Software Quality Assurance
VDD	Version Description Document

Introduction

Software Configuration Management (SCM) is the discipline of applying technical and administrative direction to identify and document a configuration item’s characteristics, control changes to them, report on the change process, and verify compliance with requirements. SCM is a critical software life cycle process that supports project management, development, maintenance, and quality assurance (QA) activities.

The core concepts of Configuration Management (CM) apply to both hardware and software, though implementation details differ. SCM is essential for iterative and incremental development methodologies and is closely related to Software Quality Assurance (SQA). SCM activities help achieve SQA goals by ensuring that software products and processes conform to their specified requirements.

Breakdown of Topics for Software Configuration Management

The SCM Knowledge Area (KA) is broken down into the following topics:

Management of the SCM Process
Software Configuration Identification
Software Configuration Change Control
Software Configuration Status Accounting
Software Configuration Auditing
Software Release Management and Delivery
Software Configuration Management Tools

1. Management of the SCM Process

Effective SCM requires careful planning and management, which begins with understanding the organizational context and constraints. An SCM plan (SCMP) outlines how the process will be implemented for a project.

1.1 Organizational Context for SCM

To plan an SCM process, it’s necessary to understand its interactions with other organizational elements, such as system-level CM (for hardware and firmware), QA, and development and maintenance teams. Overall responsibility for SCM often lies with a specific individual or group, but tasks can be distributed.

1.2 Constraints and Guidance for the SCM Process

The SCM process is influenced by various constraints and guidance, including:

Corporate policies and procedures.
Contractual requirements from acquirers.
Regulations from external bodies, especially for safety-critical software.
The chosen software life cycle process (SLCP).
Best practices reflected in software engineering standards.

1.3 Planning for SCM

The SCMP documents the results of planning and covers the major SCM activities, including identification, control, status accounting, auditing, and release management. It also addresses organization, responsibilities, resources, schedules, tool selection, and control over vendors and interfaces. Branching and merging strategies are a key part of this plan.

SCM Organization and Responsibilities: The plan must clearly define who is responsible for performing specific SCM tasks, along with their authority and reporting channels.
SCM Resources and Schedules: Planning identifies the necessary staff and tools and integrates SCM tasks into the overall project schedule.
Tool Selection and Implementation: Careful planning is needed to select and implement SCM tools, considering organizational needs, environment constraints, cost, and integration with other tools.
Vendor/Subcontractor Control: The plan must address how purchased or subcontracted software products will be managed and how compliance with SCM requirements will be monitored.
Interface Control: When software interfaces with other software or hardware, the SCM plan must describe how these interfaces are identified and how changes to them are managed and communicated.

1.4 SCM Plan (SCMP)

The SCMP is a living document that serves as a reference for the SCM process and is updated as needed. A typical SCMP includes:

Introduction: Purpose, scope, and terms.
SCM Management: Organization, responsibilities, and applicable policies.
SCM Activities: Details on configuration identification, control, etc.
SCM Schedules: Coordination with other project activities.
SCM Resources: Tools, physical resources, and human resources.
SCMP Maintenance: How the plan will be updated.

1.5 Monitoring of Software Configuration Management

After implementation, the SCM process must be monitored to ensure its provisions are followed. This surveillance can be part of SQA’s role or performed by the SCM authority.

SCM Measures and Measurement: SCM measures provide insight into the evolving product and the effectiveness of the SCM process itself. Analysis of these measurements can lead to process improvements.
In-Process Audits of SCM: Audits can be conducted during the project to investigate the status of specific items or assess the implementation of the SCM process.

2. Software Configuration Identification

This activity identifies the items to be controlled, establishes identification schemes for them, and sets up the tools and techniques for managing them.

2.1 Identifying Items to Be Controlled

The first step is identifying the software Configuration Items (CIs) to be controlled. A CI is an item or aggregation of hardware and/or software managed as a single entity. A Software Configuration Item (SCI) is a software entity designated as a CI. SCIs can include plans, source code, test materials, and documentation.

2.2 Configuration Item Identifiers and Attributes

A scheme is defined to track information for each CI, such as a unique identifier, name, description, date, type, and owner.

2.3 Baselines

A software baseline is a formally approved version of a CI that is fixed at a specific time and can only be changed through formal procedures. It serves as a reference point in the software’s life cycle and represents the current approved configuration.

2.4 Relationships Scheme Definition

SCM tracks relationships between CIs to understand how a change in one might affect others. Common relationships include:

Dependencies: A mutual reliance between two CIs.
Derivation: One CI is derived from another sequentially.
Succession: The evolution of a CI over time through different versions.
Variants: Alternative versions of a program resulting from different options.

A Software Bill of Materials (SBOM) is a formal record that tracks CIs and their supply chain relationships.

2.5 Software Libraries

A software library is a controlled collection of artifacts like source code, documentation, and object code. Version control systems are used to store source code, while binary objects are stored in a repository, often with cryptographic hashes to ensure integrity.

3. Software Configuration Change Control

This process manages changes to CIs throughout the software life cycle, covering how changes are requested, evaluated, approved, and implemented.

3.1 Requesting, Evaluating, and Approving Software Changes

The Software Change Request (SCR) process provides formal procedures for submitting, recording, and evaluating proposed changes. An SCR may originate from anyone at any point in the life cycle. After an SCR is submitted, a technical impact analysis is performed.

The Configuration Control Board (CCB) is the authority responsible for approving or rejecting change requests. For smaller projects, this authority might be a single leader. When its scope is limited to software, it’s known as a Software CCB (SCCB).

3.2 Implementing Software Changes

Approved SCRs are implemented according to defined procedures. Version control tools help track which SCRs are incorporated into which software versions. These tools manage a central repository, track changes, and can support parallel or distributed development.

3.3 Deviations and Waivers

A formal process exists for handling situations where project requirements cannot be met.

A deviation is a temporary, pre-approved authorization to depart from a specific requirement.
A waiver is a written authorization to accept an item that does not meet its requirements but is still considered fit for use.

4. Software Configuration Status Accounting (SCSA)

SCSA involves recording and reporting the information needed to effectively manage a configuration. This includes the status of CIs, baselines, changes, and their relationships.

4.1 Software Configuration Status Information

SCSA captures and maintains information throughout the life cycle, such as the status of changes, impacted CIs, deviations, and V&V activities. This information supports management, engineering, and other related functions.

4.2 Software Configuration Status Reporting

Information from SCSA is reported to various project stakeholders. Reports can be automated, ad hoc, or predesigned and may be used to show compliance with legal or regulatory requirements. The information also serves as a basis for measurements, like the number of change requests per SCI or the average time to implement a change.

5. Software Configuration Auditing

A software audit is an independent examination to assess compliance with specifications, standards, or other criteria. Audits determine the extent to which a CI satisfies its functional and physical requirements. Two formal audits may be required:

5.1 Software Functional Configuration Audit (FCA)

An FCA verifies that a software item’s actual behavior is consistent with its governing specifications.

5.2 Software Physical Configuration Audit (PCA)

A PCA ensures that the design and reference documentation are consistent with the as-built software product.

5.3 In-Process Audits of a Software Baseline

In-process audits are conducted during development to verify the status of specific CIs and ensure they continue to conform to specifications as they evolve.

6. Software Release Management and Delivery

This topic covers the distribution of software and its related artifacts outside of the development team. The software library is a key element in managing releases.

6.1 Software Building

Software building is the process of constructing executable software from the correct versions of SCIs. Build instructions and tools must also be under SCM control to ensure that previous releases can be reproduced accurately. In continuous integration, builds are triggered automatically whenever a change is committed to the source code repository.

6.2 Software Release Management

This encompasses the identification, packaging, and delivery of product elements such as executables, documentation, and release notes. Release management determines when to issue a release, what it should contain, and how to package it for different platforms or customers. A Version Description Document (VDD) documents the physical contents of a release. In continuous delivery, a pipeline is established to continuously build, package, and deploy software artifacts.

7. Software Configuration Management Tools

Various tools assist with SCM, ranging from individual support tools to comprehensive, company-wide systems. SCM is most effective when its tools are integrated with other processes and tools in the organization. Key tool categories include:

Version control tools: Track and store individual CIs like source code.
Build handling tools: Compile and link software, and may also run quality checks and tests.
Change control tools: Support the management of change requests.
Repository/CMDB: Stores binaries and configuration data.
Release/Deployment tools: Automate the delivery of software.
Project-related support tools: Manage workspaces for development teams, especially in distributed environments.