Chapter 7: Software
Configuration Management
Software Configuration Management
• Software Configuration Management (SCM) is a set of activities
designed to control change by identifying the work products that are
likely to change, establishing relationships among them, defining
mechanisms for managing different versions of these work products,
controlling the changes imposed, and auditing and reporting on the
changes made.
• In simpler terms, SCM is the "art of coordinating software
development to minimize confusion" when multiple people are
working on the same project and things are constantly changing.
Four Core SCM Activities
1. Identification: Deciding which parts of the project need to be
tracked.
2. Version Control: Keeping track of different versions (e.g., Version 1.0
vs. Version 2.0).
3. Change Control: A formal process to decide which changes are
allowed.
4. Configuration Auditing: Checking to ensure that the actual software
matches the documentation.
Software Configuration Items (SCIs)
• A Software Configuration Item (SCI) is information created as part of
the software engineering process.
1. Documentation Items
• System Specification: The initial project plan and scope.
• Software Requirements Specification (SRS): The "contract" of what the
software will do.
• Design Documents: Data design, architectural design, and interface
descriptions.
• User Manuals: Documentation for the end-user.
2. Code-Related Items
• Source Code: The actual programs written in languages like C++, Java, or
Python.
• Executable Programs: The compiled versions of the code that actually run.
• Database Descriptions: Schema definitions and data structures.
3. Testing Items
• Test Plans: The strategy for testing.
• Test Cases: Specific inputs and expected outputs.
• Test Results: The records of what happened during testing.
4. Tools and Environment
• Compilers/Linkers: The specific versions of tools used to build the software.
• Project Plans: Schedules and resource allocations.
Change Management Process / Change
Control
• The Change Management process (also called Change Control) is the
formal procedure used to ensure that every change made to a
software system is necessary, documented, and doesn't break existing
functionality.
• Without this process, a project quickly falls into "feature creep" or
"version chaos," where no one knows which version of the code is the
most current.
The Change Management Workflow
1. Change Request (CR)
A user, developer, or stakeholder identifies a bug or requests a new feature.
They submit a formal Change Request document that describes the "what" and
"why" of the change.
2. Impact Analysis
The configuration manager or a senior engineer evaluates the request. They
ask:
How much will this cost?
How long will it take?
Which SCIs (Source code, SRS, Design docs) will be affected?
Will this change affect the system's reliability or safety?
3. Change Evaluation
• The request goes to the Change Control Board (CCB).
• This is a group of stakeholders (Project Manager, Lead Developer, Customer
Representative) who decide to Approve, Deny, or Defer the change based on
the impact analysis.
4. Implementation
• Once approved, the developer "checks out" the relevant SCIs from the project
repository.
• The items are "locked" so no one else can edit them at the same time
(preventing conflicts).
• The developer makes the changes and performs unit testing.
5. Verification and Audit
• Before the change is finalized, it must be verified.
• SQA (Software Quality Assurance) checks if the change was implemented
correctly.
• A Configuration Audit ensures that all related documents (like the User
Manual or Design Doc) were also updated to match the new code.
6. Checking In (The New Baseline)
• The updated SCIs are "checked in" back to the repository.
• A new Version is created, and the project establishes a new Baseline.
• A change report is then sent to all stakeholders.
Version Management
• Version Management is the process of keeping track of different
versions of software configuration items (SCIs) and the systems in
which they are used.
• It ensures that changes to software are identifiable, reversible, and
controlled.
• Version management is the engine that powers Software
Configuration Management (SCM).
• It allows developers to work on the same project simultaneously
without overwriting each other's code.
Working Mechanism of Version Management
Modern version management systems (like Git, Subversion, or CVS) generally
use a concept of a Codeline and a Baseline.
• Codeline: It is a sequence of versions of source code where later versions in
the sequence are derived from earlier ones.
• Baseline: It is a specific version of the system that is formally reviewed and
agreed upon. It serves as a stable point of reference for further
development.
• Branching: Creating a parallel codeline to work on a new feature or fix a
bug without affecting the main system.
• Merging: Combining the changes from a branch back into the main
codeline.
Importance of Version Management
1. Collaboration
• Multiple developers can work on the same file simultaneously.
• The system automatically manages and merges their changes.
2. History & Traceability
• Tracks who made a change, when it was made, and why.
• Helps identify and fix bugs caused by recent modifications.
3. Recovery (Rollback)
• Allows reverting to a previous working version if a new update causes problems.
• Ensures system stability and quick error correction.
4. Parallel Development
• Enables teams to develop new features (e.g., Version 2.0) while fixing bugs in an older version
• Uses branches to manage different development paths.
[Link]
• The repository serves as a central backup system.
• Protects code from loss if a developer’s computer fails.