Software Configuration Management: Principles and Processes

Software Configuration Management

Since changes are inevitable when building software and increase confusion, Software Configuration Management (SCM) is a self-protection activity that applies throughout the entire software engineering process. Because change can occur at any time, SCM activities are used to:

• Identify changes.
• Manage these changes.
• Ensure changes are properly implemented.
• Report changes to all concerned parties.

SCM is an activity that must be performed from project initiation until the software is retired. It should not be confused with maintenance, which begins after software delivery to the customer.

Categories of Engineering Results

The results of the engineering process can be divided into the following categories: programs, documents (technical, user, etc.), and data. Software configuration items include any documents, specifications, or artifacts created during software development. This number will grow as time progresses.

An engineering law states that no matter the stage of a system's lifecycle, change will occur, and the desire to change will persist. Hence, the necessity for SCM.

Understanding Baselines

A baseline is an SCM concept that helps monitor changes without impeding justified modifications. It acts as a landmark in software development, marked by the submission and approval of configuration items obtained through a formal technical review. Typical baselines include:

• System Specifications
• Requirements Analysis
• System Design
• Coding and Testing
• Test Plans and Results
• Product Delivery

The SCM Process

The process of software configuration management consists of five tasks:

1. Identification
2. Version Control
3. Change Tracking
4. Configuration Audits
5. Reporting

Identification of Configuration Objects

To control and manage configuration items, each must be identified logically using an object-oriented approach. They are distinguished as:

• Basic Items: Text units created by a software engineer (e.g., requirements specifications, test cases).
• Compound Objects: A collection of basic objects.

Each object must have a set of characteristics that uniquely identify it:

• Name: A character string that identifies the object without ambiguity.
• Description: Includes the type of configuration item (program, document, etc.) and the project identifier with its version.
• Resources: The entity that provides, processes, or is required by reference for that object.

For any software configuration item, it should be possible to create a graph to describe the evolutionary history of the changes it has undergone.