🔧 Software Configuration Management

(SCM)
Software Configuration Management (SCM) is an umbrella activity applied throughout the
software engineering process. Its primary goal is to manage the inevitable "Change" that occurs
during the development lifecycle, ensuring that quality is maintained and that every team
member is working on the correct version of the software.

✅ Definition
Software Configuration Management is the process of identifying, organizing, and controlling
changes to software during its development and lifecycle.

🎯 Main Goal
👉 Maximize productivity by minimizing mistakes caused by uncontrolled changes

🔍 Key Functions of SCM

1.​ Identify changes
○​ Recognize what needs to be modified
2.​ Control changes
○​ Approve/reject changes in a systematic way
3.​ Ensure proper implementation
○​ Verify changes are correctly applied
4.​ Report changes
○​ Inform all stakeholders about updates

🔄 Important Point
SCM is an umbrella activity, meaning:

●​ It is applied throughout the entire software process

●​ Because change can happen at any time

●​ Ensure consistency and traceability of software components​

●​ Help control changes to software​

●​ Enable versioning and release management​

●​ Support team collaboration by defining controlled items​

Software Configuration Items (SCIs) are:

“Any identifiable, discrete element of a software

system that is subject to configuration management
and can be uniquely versioned, controlled, and
tracked throughout the software lifecycle.”
In simpler technical terms

SCIs are the individual pieces of a software project that need

to be managed and controlled when changes happen.

Examples of SCIs
Software Configuration Items can include:

1.​ Source Code​

○​ Modules, classes, functions, scripts​

2.​ Executable Files​

○​ Compiled programs, libraries​

3.​ Documentation​

○​ Requirements documents, design documents, test plans, user manuals​

4.​ Test Artifacts​

○​ Test cases, test scripts, test data​

5.​ Configuration Files​

○​ Settings, parameters, deployment scripts​

6.​ Databases and Schemas​

○​ Schema definitions, initial data

The Hierarchy and Interrelationship of SCIs:

As the software process evolves, the number of SCIs grows exponentially. SCIs are rarely
isolated; they exist in a complex web:

●​ Compositional Relations: Smaller SCIs (like a specific data model) combine to form a
larger SCI (like a Design Specification).
●​ Interrelationships: A change in one item (e.g., Source Code) may necessitate a change
in another (e.g., Test Suite). Identifying these links is crucial for impact analysis.

The idea here is slightly more advanced than just defining SCIs—it explains how SCIs are
organized and managed in real systems. Breaking it down step by step in a clear, technical
way:

🔷 1. Configuration Objects (Grouping of

SCIs)
Technical meaning:

A configuration object is a logical grouping of multiple SCIs treated as a single unit in the
system.

Instead of managing hundreds of individual files separately, related SCIs are

grouped into one object.

Structure of a configuration object:

Each object has:

●​ Name → unique identifier

●​ Attributes → properties (version, author, status, etc.)
●​ Relationships → links to other objects

Example:

A “Login Module” configuration object may include:

●​ Design Specification (SCI)

●​ Data Model Component (SCI)
 ●​ Source Code (SCI)
●​ Test Specification (SCI)

All these are separately identified SCIs, but grouped as one configuration object.

Analogy:

Like a folder:

●​ Files inside = SCIs

●​ Folder itself = Configuration Object

🔷 2. Relationships Between Objects

Technical meaning:

Configuration objects are not isolated—they are linked through relationships.

Types of relationships:

●​ Dependency → one object depends on another

●​ Traceability → requirement → design → code → test
●​ Composition → object made of smaller objects

Example:

●​ Requirement → Design → Code → Test​

If requirement changes → all related objects must be updated

Why important:

●​ Helps track impact of changes

●​ Maintains consistency across system
🔷 3. Problems in Early (Paper-Based)
SCM
Before digital systems, SCIs were stored as paper documents.

Major issues:

(1) Difficulty in finding items

●​ No centralized system
●​ Searching was manual and slow

👉 Like finding one paper in a huge pile

(2) No proper change tracking

●​ Hard to know:
○​ Who changed it
○​ When it was changed
○​ What was changed
👉 No “history” of modifications

(3) Version creation was difficult

●​ Creating a new version meant:

○​ Copying documents manually
○​ Updating everything by hand

👉 High chance of errors and inconsistency

(4) Relationships were unclear

●​ Impossible to track:
○​ Which design belongs to which requirement
○​ Which test case verifies which module

👉 No traceability

🔷 4. Modern SCM Repository

Technical definition:

An SCM repository is:

“A centralized system that stores, manages, tracks, and controls all software
configuration items and their relationships.”

🔹 What it contains:
●​ All SCIs (code, documents, data)
●​ Configuration objects
●​ Version history
●​ Relationships between items
🔹 Core functions:
1. Data Integrity

●​ Ensures data is accurate and consistent

●​ Prevents corruption or loss

👉 Example: No accidental overwriting

2. Data Sharing

●​ Multiple developers can access same data

●​ Supports team collaboration

👉 Example: GitHub repository

3. Data Integration

●​ Combines different SCIs into a unified system

●​ Maintains relationships between them

👉 Example: Linking code with test cases and requirements

4. Change Management

●​ Tracks:
○​ Who made changes
○​ What changed
○​ When it changed

5. Version Control

●​ Maintains multiple versions

●​ Allows rollback
🔷 5. Real-Life Example
Modern tools acting as SCM repositories:

●​ Git + GitHub
●​ GitLab
●​ Bitbucket

Here’s a deeper, technical explanation of each characteristic of Software Configuration Items

(SCIs):

1. Identifiable
Technical meaning:​
Each SCI must be uniquely distinguishable from every other item in the system using a
defined identification scheme.

How it is done:

●​ Unique name or label (e.g., LoginModule_v1.2)

●​ Version number or ID
●​ Metadata (author, creation date, type)

Why it matters:​
Without identification, tracking changes becomes impossible. In large systems with thousands
of files, confusion would occur.

Example:​
Instead of just “main file”, it becomes:

○​ main_v1.0.c
○​ main_v1.1.c

Analogy:​
Like student IDs in a college—names can repeat, but IDs are always unique.

2. Version-Controlled
Technical meaning:​
Every SCI is maintained under a version control system (VCS) that records:

●​ Changes made
●​ Who made them
●​ When they were made
●​ Why they were made

Key concepts:

●​ Version history
●​ Branching (parallel development)
●​ Merging (combining changes)

Why it matters:

●​ Enables rollback to previous versions

 ●​ Prevents overwriting others’ work
●​ Supports team collaboration

Example tools:

●​ Git
●​ SVN

Example scenario:​
If a bug appears in version 3.0, developers can go back to version 2.9 to check what changed.

Analogy:​
Like Google Docs “version history”—every edit is saved and recoverable.

3. Managed
Technical meaning:​
SCIs are governed by Software Configuration Management (SCM) processes, ensuring
controlled handling of:

●​ Creation
●​ Modification
●​ Review
●​ Approval
●​ Release

Includes:

●​ Change control procedures

●​ Access control (who can modify what)
●​ Status tracking (e.g., draft, approved, obsolete)

Why it matters:​
Prevents unauthorized or accidental changes that could break the system.

Example:​
Before modifying a requirement document:

1.​ Submit a change request

2.​ Get approval
3.​ Apply change
4.​ Record it
Analogy:​
Like a bank system—transactions don’t happen freely; they go through authorization and
logging.

4. Baselined

Technical meaning:​
A baseline is a formally approved version of one or more SCIs that:

●​ Serves as a reference point

●​ Can only be changed through formal procedures
Types of baselines:

●​ Requirements baseline
●​ Design baseline
 ●​ Product baseline

Why it matters:

●​ Provides stability in development

●​ Ensures everyone works on the same “frozen” version
●​ Changes become controlled, not random

Example:​
Version 1.0 of a system is baselined.​
Any change after that must go through change control.

Analogy:​
Like submitting an exam paper—once submitted, changes are not allowed unless officially
permitted.

○​

Subject to Formal Change Control Procedures

○​ Any modification to an SCI must follow formal procedures.

○​ Includes:
■​ Request for change
■​ Impact analysis
■​ Approval
■​ Documentation of the change
○​ Purpose: Avoid uncontrolled changes that could break the system.

4.​ Part of a Larger Configuration

○​ SCIs are not standalone; they are components of a system or subsystem.
○​ Proper arrangement and integration of SCIs define the overall system
configuration.
○​ Example:
■​ Login module + Payment module + Database schema → E-commerce
system

Here’s a clear and structured explanation of Software Configuration Management (SCM)

activities:
Software Configuration Management
(SCM) Activities
SCM is a process that controls, tracks, and manages changes in software systems to ensure
consistency, reliability, and traceability.

The main activities of SCM include:

1. Configuration Management Activities

These are the overall tasks to manage SCIs (Software Configuration Items) throughout the
software lifecycle:

●​ Identification of SCIs
○​ Determine which items (source code, documents, libraries, test scripts) need to
be managed.
●​ Control
○​ Ensure changes to SCIs are performed in a controlled manner.
●​ Status Accounting
○​ Track the current version, location, and status of each SCI.
●​ Audit and Review
○​ Verify that SCIs conform to requirements and that changes are correctly
implemented.

2. Change Management
Definition: Process of handling requested changes to SCIs in a structured way.

Steps in Change Management:

1.​ Change Request – A developer, tester, or user submits a request.

2.​ Impact Analysis – Evaluate the effect of the change on the system.
3.​ Approval/Rejection – Decide whether the change should be made.
4.​ Implementation – Make the approved change in the relevant SCI.
5.​ Documentation – Record what was changed and why.

Purpose: Avoid uncontrolled modifications that could break the system.

3. Version Management
Definition: Process of tracking and controlling different versions of SCIs.

Key Points:

●​ Assign unique version numbers to each item

●​ Keep a history of changes for each version
●​ Enable rollback to previous versions if problems arise

Example:

●​ LoginModule_v1.0 → LoginModule_v1.1 → LoginModule_v2.0

Purpose: Maintain traceability and reliability across system updates.

4. System Building
Definition: Process of assembling SCIs to create a working system.

Steps:

●​ Compile source code modules

●​ Link libraries and components
●​ Configure the system according to specifications
●​ Produce a build that can be tested

Purpose: Ensure that all components work together correctly in an integrated system.

5. System Release
Definition: Process of deploying a stable version of the system for use by customers or
end-users.

Key Points:

●​ Includes documentation, executables, and configuration files

●​ Ensures that the released version is tested, verified, and validated
 ●​ Often includes version labeling and archiving for future reference

Purpose: Deliver a reliable, well-documented, and reproducible system to users.

Summary Table
Activity Purpose

Configuration Management Identify, control, and track SCIs

Change Management Handle change requests systematically

Version Management Track versions and maintain history

System Building Assemble SCIs into a working system

System Release Deliver stable, tested, and documented system to

users

🔷 Layers in Software Configuration

Management (SCM)
SCM is divided into key layers (activities):
 1.​ Identification of Objects
2.​ Change Control
3.​ Version Control
4.​ Configuration Audit
5.​ Status Reporting (Status Accounting)

🔶 1. Identification of Objects
Technical idea:

Every Software Configuration Item (SCI) must be:

●​ Named
●​ Described
●​ Organized
🔹 Types of Objects
●​ Basic Objects → individual SCIs (code file, document)
●​ Aggregated Objects → group of SCIs (complete module/system)

🔹 Object Features
Each object has:

●​ Name → unique identifier

●​ Description → what it does
●​ Resources → files, tools, inputs
●​ Realization → actual implementation

🔹 Evolution of Objects
Objects change over time, even after baseline.

Example evolution:

●​ 1.0 → initial version

●​ 1.1 → revision
●​ 1.1.1, 1.1.2 → minor fixes
●​ 1.2 → major update
●​ 2.0 → new branch (major change)

👉 This is represented using an evolution graph

🔹 Key idea:
●​ Software is not static
●​ It continuously evolves
●​ SCM tracks this evolution

This is a full set of SCM layers, but it’s written in a dense way. Let’s organize and explain it
clearly so it’s easy to understand and write in exams.

🔶 2. Change Control
Technical definition:

A formal process to manage and approve changes in SCIs.

🔹 Steps:
1. Change Request

●​ Someone proposes a change

2. Evaluation

Checks:

●​ Technical feasibility
●​ Side effects
●​ Cost
●​ Impact on system

3. Change Control Authority (CCA)

●​ Final decision maker (person/team)

4. Engineering Change Order (ECO)

Document that includes:

●​ What to change
●​ Constraints
●​ Review criteria

5. Implementation

●​ Developer makes change in controlled environment

●​ Version system updates it
🔹 Key idea:
👉 No change is made without approval

🔶 3. Version Control
Technical definition:

A system that manages multiple versions of SCIs.

🔹 Core capabilities:
1. Project Database

Stores all SCIs

2. Version Management

Stores all versions

3. Make Facility

Builds a specific version of software

4. Change Set Management

Tracks group of changes

🔹 Change Set
A change set includes:

●​ What changed
●​ Who changed it
●​ When
●​ Why
👉 Helps recreate any version easily

🔹 Versions vs Variants vs Entities

✔ Entity

●​ Collection of objects at same revision

✔ Variant

●​ Different versions for different environments

Example:

●​ Version with color display → uses Entity 4

●​ Version with monochrome → uses Entity 5

✔ Version (Revision)

●​ Major update in system

🔹 Simple understanding:
●​ Entity = components
●​ Variant = different configurations
●​ Version = major release

🔶 4. Configuration Audit
Purpose:

To verify that changes are correct and properly applied

🔹 Two types:
1. Formal Technical Review

Checks:

●​ Technical correctness
●​ Missing elements
●​ Side effects

2. SCM Audit

Checks process compliance:

Questions asked:

●​ Was change implemented correctly?

●​ Was ECO followed?
●​ Were all related SCIs updated?
●​ Were standards followed?

🔹 Key idea:
👉 Ensures quality + correctness + process compliance

🔶 5. Status Reporting (Status

Accounting)
Technical definition:

Tracking and reporting the status of configuration items and changes

🔹 Answers 4 key questions:
1.​ What happened?
2.​ Who did it?
3.​ When did it happen?
4.​ What else is affected?

🔹 Purpose:
●​ Provides transparency
●​ Helps in project tracking
●​ Supports decision making

🔷 Final Summary (Easy Memory)

Layer Purpose

Identification Define and organize SCIs

Change Control Approve and manage

changes

Version Control Manage different versions

Audit Verify correctness

Status Track and report changes

Reporting

🔷 Simple Analogy
Think of SCM like managing a big school project:

●​ Identification → label all files

●​ Change Control → teacher approves edits
●​ Version Control → keep old copies
●​ Audit → check if work is correct
 ●​ Status Reporting → track who did what

If needed, a flow diagram or short exam notes (5–6 mark answer format) can be prepared
from this.