Software configuration management is often reduced to Git commands, so versions, baselines, releases and approved changes blur together. One CampusLib change request, CR-17, pulls them apart: impact analysis, then branching, then a reproducible build, then an audit, then a new baseline.
What software configuration management controls
Software configuration management, or SCM, identifies configuration items, controls versions and changes, records status, and verifies approved configurations across the software life cycle. Source control is only one mechanism inside SCM.
SCM protects product integrity and traceability. Project management plans people, schedules and costs. The six SCM activities are:
Configuration identification: name items and baseline
B1.0.Version control: preserve states such as
C2 v2.1andv2.2.Change control: analyse and approve
CR-17.Status accounting: report which change entered a baseline.
Configuration audits: check behaviour and delivered contents.
Build and release management: reproduce
build 42from its manifest.
The GATE CS Exam category collects the broader preparation material for this syllabus, and GATE Guidance by Sanchit Sir is the structured route through it.
Configuration items, versions and baselines
A configuration item, or CI, is an artifact under formal control. Examples include requirement R2, design D2, source modules C2 and C3, tests T17, T18, T29 and T30, BScript v3.0, and Config v1.4. Selection depends on the need for control and traceability, not on whether it is a file.
Term | Meaning |
|---|---|
Version | A distinguishable state of an item |
Revision | A later modification in one line of development |
Variant | A parallel form for a different environment or customer |
Baseline | A reviewed and authorised set of CIs that changes only through formal control |
Every commit may identify a version, but every commit is not a baseline.
Starting baseline B1.0, tagged at a13f, contains R2 v1.0, which says, "a standard member may borrow at most 4 books"; D2 v2.2 named LoanPolicy; C2 loan_limit.py v2.1; BScript v3.0; and Config v1.4. Build 41 passes 28/28 tests.
Worked example: take CR-17 from request to approval
CR-17 proposes two rules: raise the standard-member limit from 4 to 6 books, and require librarian approval when any current loan is more than 7 days overdue. Impact analysis follows R2 -> D2; D2 -> C2, C3; C2 -> T17, T18; and C3 -> T29, T30. C3 approval.py, T29 and T30 are new. The other five items are revised, so the impact set has exactly eight changed or new CIs: R2, D2, C2, C3, T17, T18, T29, T30.
Change control is a decision, not an automatic edit. A three-member board reviews impact, tests and rollback. Two approve and one rejects, so CR-17 passes this example's simple majority rule. Real rules come from the SCM plan. Its status is Submitted -> Analysed -> Approved -> Implemented -> Audited -> Closed.
CI | Before | Change | After |
|---|---|---|---|
|
| revise borrowing rule |
|
|
| revise |
|
|
| revise |
|
| not present | add |
|
| existing test | revise |
|
| existing test | revise |
|
| not present | add test |
|
| not present | add test |
|
Version control, branching, builds and the new baseline
Branch cr-17 starts from B1.0 at a13f, receives b271 for the limit change and c904 for overdue approval. Main receives hotfix d5aa. They merge at e777, whose parents are d5aa and c904. Branches and commits support version control. Approval and audit create a baseline.
Build 42 uses e777, BScript v3.0 and Config v1.4. The revised 28-test suite and new tests T29 and T30 pass, giving 30/30. Its manifest records e777, all eight CI versions, the script, configuration and result. After audit, it becomes release-1.1 and baseline B1.1.
Restoring only C2 v2.1 is insufficient. Rollback to B1.0 needs tag a13f, build 41, BScript v3.0, Config v1.4 and its full manifest. A build is a generated executable package, a release is a build delivered to users, and a baseline is the authorised reference set.
Status accounting and configuration audits
Status accounting answers: what CIs exist, which versions are approved, what state each request is in, and which baseline or build contains each change. One record is CR-17 | Approved in B1.1 | implemented at e777 | build 42 | 30/30 tests | Closed. A Git log cannot prove approval or audit completion.
For CR-17, the functional configuration audit checks that build 42 satisfies R2 v1.1: six books are allowed, a seventh is rejected, and a loan overdue by 8 days triggers librarian approval. The physical configuration audit checks that the delivered package matches the B1.1 manifest, including commit e777, the recorded CI versions, BScript v3.0, Config v1.4 and expected packaged files.
Passing 30/30 tests gives behavioural evidence. The trace matrix and audits connect the approved requirement, implementation, tests and package. Neither verification nor traceability replaces the other.
Common SCM traps and their corrections
Mistake | What goes wrong | Do this instead |
|---|---|---|
Calling every commit a baseline | Unreviewed states appear authorised | Require formal approval |
Changing | Dependent design, code or tests are missed | Maintain trace links |
Using | Labels carry no consistent meaning | Apply a version policy |
Rebuilding without scripts and configuration | The result cannot be reproduced | Keep a complete build manifest |
Treating passed tests as a physical audit | Package contents remain unchecked | Run separate functional and physical checks |
Change control evaluates and authorises a proposed modification. Version control stores and relates multiple states. Status accounting reports what happened, while an audit independently checks conformance. In this scenario, reporting CR-17 as Approved is status accounting. Deciding approval through the 2-1 vote is change control.
A small team may combine roles and automate records, but it still needs unambiguous baselines, change ownership, traceability and reproducible releases. Installing a version-control product does not create an SCM process.
How exams and interviews test SCM
Common questions ask you to identify an SCM activity, count the eight impacted items, recognise B1.0 and B1.1 as baselines but not c904, select status accounting for the CR-17 report, or distinguish the audits. GATE CS subject weightage helps you decide how much revision time software engineering deserves alongside the heavier subjects.
The SCM Concepts: Change Control and Version Control lesson holds more than 20 practice questions on identification, change control, versioning and audits, which is where to test this CR-17 walkthrough against real stems.
An interview may ask, "How would you reproduce or roll back build 42?" For reproduction, name e777, BScript v3.0, Config v1.4, the eight CI versions and the 30/30 test record. For rollback, select baseline B1.0, tag a13f and build 41. CS Fundamentals for Placements is the interview-oriented route for core CS subjects including software engineering.
The short version
Identify CIs, establish a baseline, analyse and approve changes, version the work, record status, build reproducibly, audit, then create the next baseline. Cover the traceability diagram and reconstruct CR-17 from B1.0 to B1.1. Check that your impact set contains eight items and that the final record says 30/30.
Work the next change request the same way: name the CIs before touching code, write the impact set down, and refuse to call anything a baseline until it has been approved and audited. GATE Guidance by Sanchit Sir teaches software engineering in that order, and the GATE CS Exam category lists the other routes into the subject.
