The Configuration Management (CM) Process is a structured, systematic approach to managing, controlling, and tracking changes to software artifacts throughout the project lifecycle. It ensures that the software product remains consistent, traceable, and reproducible at all times.
Five Core Phases of the CM Process
┌─────────────────────────────────────────────────────────────────┐ │ CONFIGURATION MANAGEMENT PROCESS │ ├─────────────┬──────────────┬─────────────┬──────────┬───────────┤ │ 1. CM │ 2. CM │ 3. CM │ 4. CM │ 5. CM │ │ Planning │Identification│Change Ctrl │Status │ Audit & │ │ │ │ │Accounting│Verification│ └─────────────┴──────────────┴─────────────┴──────────┴───────────┘
Phase 1: CM Planning
The foundation of the entire process. A CM Plan is created and approved.
Key Activities:
- Define CM roles and responsibilities (CM Manager, Change Control Board)
- Select CM tools (version control, issue tracking, build automation)
- Establish naming conventions and version numbering schemes
- Define branching and merging strategies
- Set up baseline creation criteria
- Determine change approval thresholds
Output:
- Software Configuration Management Plan (SCMP) – A formal document approved by stakeholders
Sample SCMP Outline:
text
1. Introduction (scope, definitions) 2. CM organization (roles, CCB membership) 3. CM activities (identification, control, status, audit) 4. Tools and environment 5. Milestones and baselines 6. Change control procedure 7. Release and delivery process
Phase 2: Configuration Identification
Identifying and uniquely naming every Configuration Item (CI) that needs to be controlled.
What is a Configuration Item (CI)?
Any artifact that is subject to change control:
- Code items – Source files, header files, libraries
- Documentation – Requirements, design, user manuals, test plans
- Build items – Makefiles, scripts, dependency lists
- Environment items – Database schemas, configuration files, environment variables
- Test items – Test cases, test data, automated test scripts
- Tools – Compilers, linters, static analysis tools (with versions)
Identification Scheme Example:
text
[PROJECT]-[TYPE]-[SUBSYSTEM]-[VERSION]
Example: CRM-CODE-AUTH-v2.1.0
│ │ │ │
│ │ │ └─ Version
│ │ └──────── Subsystem (Authentication)
│ └───────────── Type (Code)
└─────────────────── Project (Customer Relationship Mgmt)
Baselining:
A baseline is a formally reviewed and approved snapshot of CIs at a specific time.
| Baseline Type | Content | When Created |
|---|---|---|
| Functional Baseline | Requirements document | After requirements approval |
| Allocated Baseline | High-level design, architecture | After design approval |
| Developmental Baseline | Source code under version control | Continuously updated |
| Product Baseline | Executable, release notes, manuals | At product release |
Phase 3: Change Control
The most critical operational phase. Manages how changes are proposed, evaluated, approved, and implemented.
Change Control Workflow:
text
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 1. Submit│───▶│2. Record │───▶│3. Assess │───▶│4. Approve│───▶│5.Implement│
│ Change │ │ in Log │ │ Impact │ │ / Reject│ │ Change │
│ Request │ │ │ │ Analysis │ │ │ │ │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
│
┌──────────┐ ┌──────────┐ ┌──────────┐ ▼
│8. Close │◀───│7. Verify │◀───│6. Update │◀────────────────────────┘
│ CR │ │ Change │ │ Baselines│
└──────────┘ └──────────┘ └──────────┘
Change Request (CR) Types:
| Type | Description | Priority Example |
|---|---|---|
| Corrective | Bug fix | Critical/High/Medium/Low |
| Perfective | Enhancement, performance | High/Medium |
| Adaptive | Environment change (OS, DB, library) | Medium |
| Preventive | Refactoring, documentation | Low |
Change Control Board (CCB):
- Composition: Project manager, technical lead, QA lead, configuration manager, customer representative (if applicable)
- Meetings: Weekly or as needed
- Decision types: Approve, Reject, Defer, Return for more info
Change Request Form Template:
text
CR Number: CR-00123 Date Submitted: 2025-03-15 Submitter: Jane Developer CI Affected: auth-module-v2.1.0 Change Type: Corrective (bug) Description: Login fails when password contains special characters Priority: High Impact Analysis: 4 files affected, 2 person-days CCB Decision: Approved (2025-03-16) Implementation Date: 2025-03-17 Verification: Passed all login tests
Phase 4: Status Accounting
Tracking and reporting the historical state and changes to all CIs.
Information Tracked:
- Version history – Who changed what, when, and why
- Baseline contents – Which versions form each baseline
- Change request status – Open, approved, implemented, verified, closed
- Build records – Which versions were in each build
- Release contents – Which builds went to which customer/environment
Typical Reports Generated:
| Report | Frequency | Purpose |
|---|---|---|
| CR Status Report | Weekly | List open/approved/completed changes |
| Baseline Summary | Per milestone | What’s in each baseline |
| Version Description Document (VDD) | Per release | Complete inventory of release contents |
| Audit Trail | Monthly | Who changed what, with approval records |
| Build Manifest | Per build | Exact versions in each build |
Example Build Manifest:
text
Build ID: BUILD-2025-03-20-001 Date: 2025-03-20 14:30 UTC Jenkins Job: project-main-release Git Commit: a3f2c91 (main branch) Components: - auth-service: v2.1.0 - payment-gateway: v1.4.2 - database-schema: v3.0.1 Environment Config: production-us-east.json Test Status: All 342 tests passed
Phase 5: Configuration Audits & Verification
Ensuring that what is documented matches what actually exists.
Two Types of Audits:
A. Functional Configuration Audit (FCA)
- Question: Does the software actually perform as specified?
- When: Before releasing a baseline
- Method: Run requirements traceability matrix + execute tests
B. Physical Configuration Audit (PCA)
- Question: Is the implemented product exactly matching the design documentation?
- When: After implementation, before baselining
- Method: Compare code against design docs, check version labels
Audit Checklist Example:
| Check Item | Status | Evidence |
|---|---|---|
| All source files under version control | ✓ | Git repo shows all files |
| No unapproved changes in baseline | ✓ | CR log matches baseline |
| Build process documented and automated | ✓ | Jenkinsfile exists |
| Release contains only approved CIs | ✓ | Manifest vs CR approval |
| No configuration drift in production | ✓ | terraform plan shows no diff |
Verification Activities:
- Build verification – Can we rebuild exactly from source?
- Environment verification – Are dev/staging/prod configs consistent?
- Change verification – Was each approved CR actually implemented?
Complete Process Flow (End-to-End Example)
Day 1: PLANNING └── CM Plan approved, tools selected (Git + Jira + Jenkins) Day 2-10: IDENTIFICATION └── All code files, configs, docs identified and labeled Day 11: BASELINE └── Requirements baseline v1.0 created Day 12: CHANGE REQUEST └── Developer submits CR-001 to add login timeout feature Day 13: CHANGE CONTROL └── CCB analyzes impact (3 files, 2 days) → Approved Day 14-15: IMPLEMENTATION └── Developer implements change in feature branch Day 16: VERIFICATION └── QA tests → Passed Day 17: BASELINE UPDATE └── Merge to main → New developmental baseline Day 18: STATUS ACCOUNTING └── Report: "CR-001 implemented in build #456" Day 19: AUDIT └── Verify: All changes match CR-001 spec → Approved Day 20: RELEASE └── Product baseline v2.0 created and released
Roles in the CM Process
| Role | Responsibilities |
|---|---|
| CM Manager | Owns CM Plan, manages CM tools, conducts audits |
| Change Control Board | Reviews and approves/rejects change requests |
| Developer | Submits CRs, implements approved changes, follows CM procedures |
| QA Engineer | Verifies changes, participates in audits |
| Release Manager | Creates builds, manages releases, maintains manifests |
| Project Manager | Allocates resources, approves CM Plan, chairs CCB meetings |
Common CM Process Metrics
| Metric | Formula | Target |
|---|---|---|
| Change Success Rate | (Successful changes / Total changes) × 100 | > 95% |
| CR Cycle Time | Implementation date – Submit date | < 5 days |
| Baseline Compliance | (CIs in baseline / Total CIs) × 100 | 100% |
| Audit Finding Density | Findings / Total CIs audited | < 1% |
| Configuration Drift | (Drifted CIs / Total CIs) × 100 | 0% |
Process Improvement (CM Maturity Levels)
Based on CMMI’s CM Process Area:
| Level | Characteristics |
|---|---|
| 1 – Initial | Ad-hoc, no formal CM, “hero” based |
| 2 – Managed | Basic version control, change requests tracked |
| 3 – Defined | Standardized CM Plan, CCB exists, baselines used |
| 4 – Quantitatively Managed | Metrics collected, process performance analyzed |
| 5 – Optimizing | Continuous improvement, automated CM everywhere |