Software Configuration Management: Change Control & Version Control Explained
A project can have the right code and still release the wrong version. Software Configuration Management gives the team a clear record of what exists, what may change, and what was actually released.
Open chapter contents
Why does a software project need configuration management?
Students often hear “SCM means Git.” Git is useful, but it solves only part of the problem. In a real project, a change to one rule can affect source code, requirements, tests, database scripts, user instructions and the release package. The team must know which items changed, why they changed, who accepted the change, and which versions users received.
One example for the whole chapter: A college library app has a rule that a book returned on its due date must have a late fee of ₹0. Staff find that the current release sometimes charges ₹10. A developer can edit the fee function quickly, but the team also needs to check the approved rule, nearby tests, receipts and the release version. SCM helps keep this whole change controlled and traceable.
“On the due date, the fee is ₹0.”
Fee logic, boundary cases and receipt checks.
Which approved versions were tested and delivered?
These items should agree. Otherwise users may receive code that does not match the documented rule or a release note that describes a feature not actually present.
Definition for exams: SCM is a supporting software engineering process that identifies software configuration items, manages controlled changes, records status and versions, checks consistency, and supports reliable releases during development and maintenance.
Memory trick: SCM asks four questions: What is controlled? Who approved the change? Which version contains it? Does the release match the record?
Configuration item, version and baseline in simple words
These three terms appear together in semester exams. Learn them through the library example instead of memorising separate definitions.
An identified item placed under control, such as a requirements document, fee-calculation module, test suite or build script. It may be a single item or an agreed group of items. Decide its owner, identity and level of control.
One identifiable state of an item at a point in its history. The fee module before a correction and the fee module after it are different versions. A repository can record how those states are related.
A formally approved reference version of one or more CIs at a particular point. Further changes to that approved reference follow the project's change-control rules. It is like a marked checkpoint against which later work can be compared.
A selected, built and delivered product version, with supporting records. A release may contain many CIs and depends on an agreed combination of their versions. It is more than one developer's latest file.
Library example: The team marks the approved rule, fee module and associated test cases as the reference for release 1.0. After the due-date error is reported, the team does not silently change this reference. It records a request, decides the change, creates new versions, tests them and establishes the next approved release state.
Very important: Every commit is a version-history event, but every commit is not automatically a formal baseline. A Git tag can help identify a release, but the team's approval and verification process decides whether it is an accepted baseline.
Configuration control may also cover documentation, schemas, dependencies and build settings. Private student records are not source-code items to casually place in Git. Manage sensitive operational data with suitable access and data procedures while keeping its schema and migration scripts controlled.
Main activities of Software Configuration Management
SCM is a complete discipline. The six cards below are a student-friendly learning map: the SWEBOK guide groups version-control tools under SCM tools, while identification, change control, status accounting, auditing and release management are separate areas. For exams, explain the purpose of each job instead of memorising only labels.
Name and select controlled items, their relationships and baselines.
Submit, assess, approve or reject changes and control implementation.
Keep file history, branches, merges and identifiable versions.
Show each request, item, version and baseline's current state.
Verify that approved items and documentation match what was built.
Build from known versions, verify them and record what users received.
Teams also plan responsibilities, tools and procedures. The six cards explain the operational ideas; they do not force every project to use a six-department organisation.
Why identify items before changing them?
If the team cannot name the fee module, test suite and document version, it cannot reliably answer “What changed in release 1.0.1?” Identification gives each controlled item a clear name and relationship. A baseline then gives a known approved starting point.
The user-facing rule should be clear before a developer changes it. The requirement documentation and management chapter explains how a user need becomes a reviewed requirement and how later requirement changes are traced.
What is change control? Complete process
Change control is the controlled path from a proposed change to an approved decision, implementation and verification. It answers “Should we change this item, what will it affect, and who accepts the result?” A request may be a bug fix, a new feature, a policy change or an environment update.
- 01Record the request (CR).
Write the problem, expected behaviour, affected version, requester, reason and example input. Here: “Due-date return charged ₹10; expected ₹0.”
- 02Check and analyse impact.
Reproduce the issue. Look at the fee module, receipts, account balance, reports, tests, effort and release risk. Do not guess that only one line needs changing.
- 03Make a decision.
The authorised person or Configuration Control Board (CCB) accepts, changes, defers or rejects the request. Record the reason, priority and scope.
- 04Implement the approved scope.
Update the controlled items in a working branch or equivalent workspace. Link work and commits to the request so the reason remains visible.
- 05Review and test.
Check the exact reported case, boundary cases and connected features. Confirm that the implementation follows the approved rule and that unrelated behaviour remains correct.
- 06Record, release and close.
Update request status, changed-item versions, release notes and baseline information; build and deliver the selected tested version.
Impact analysis matters because one module may be connected to several others. If a late fee is used by both the receipt and student account, changing its logic can affect both. The coupling and cohesion chapter helps explain why tightly dependent modules make impact analysis harder.
CCB does not mean a big committee for every commit. A small project may assign the decision to a lead or owner. A larger or critical project may use a formal board. The level of review should match the baseline, impact and risk. Urgent fixes may use a documented emergency path with review afterward.
What is version control and how does Git help?
Version control records the history of controlled files so developers can identify earlier states, compare changes, collaborate and manage parallel work. Git is a widely used version control system. It can record source code, tests and text documents, but a Git repository by itself does not decide business approval or guarantee that a release was tested.
The project history and controlled files are stored together. Team members can inspect recorded changes instead of passing around “final-new-last” folders.
A recorded snapshot with a message and identity. “Correct due-date boundary test” explains a change better than “update files.” A commit is evidence of what was recorded, not approval by itself.
A separate line of work. The fee fix can be developed and tested before it is brought into the team's main line. Branch names and merge rules are team choices.
A merge combines work histories; a tag can name a selected commit. Both help identify versions, but the team still has to check review, tests and release records.
What can version control answer?
- Which version of the fee function was present before the fix?
- What changed between the earlier and later commits?
- Who recorded a change, and what reason did the message give?
- Which branch contains the proposed fix?
- Which selected commit was used for a particular release record?
Good traceability links a request ID, requirement, relevant tests, commit or merge, and release version. The tool stores history; the team's procedure gives that history meaning.
Worked example: fix a wrong late fee safely
Approved baseline: Library app release 1.0 says “Return on due date → ₹0 fee.” Reported result: a due-date return charges ₹10. The request is logged as CR-17. The code may contain a boundary comparison mistake; the team confirms this through inspection and a reproducible test.
What does each control contribute?
The lead confirms R-04 and approves CR-17 after checking its effect on receipts, balances and reports. A new fee policy is outside this request.
A developer works on the fee correction and tests in a branch, records the changes with a meaningful commit and links the work to CR-17.
Before due date → ₹0; exactly on due date → ₹0; one day late → approved one-day fee. Receipt and student balance must show the same amount.
The reviewed and tested code, test evidence and release note are linked to the version delivered as 1.0.1. The team can later identify what users actually received.
If the project instead discovers that the entire old fee module needs restructuring, the team may plan a wider change. The software re-engineering chapter explains how understanding an existing system supports a planned transformation. That larger job needs its own scope, impact review and verification.
Exam insight: “The developer committed the fix” answers only the version-history part. A complete SCM answer also identifies the approved request, affected items, tests and released baseline.
Change control vs version control: main differences
| Point | Change control | Version control |
|---|---|---|
| Main question | Should this change be made, and under what conditions? | Which file states and histories exist? |
| Main purpose | Evaluate, authorise and verify a proposed change | Record versions and support parallel development |
| Typical input | Change request with reason and impact | Changed files and commit information |
| Typical decision | Accept, modify, defer or reject | Record, compare, branch, merge or select a version |
| People | Requester, analyst, authorised lead or CCB, reviewers | Developers and others recording controlled files |
| Evidence | Approval, scope, impact and test/closure record | Commit history, diffs, branches and tags |
| Library example | Approve CR-17 to correct the due-date error | Record the fee and test changes in Git |
| Relationship | Sets the permitted change path | Helps implement and trace that path |
One-line answer: Change control manages the decision and approval; version control manages the recorded versions and history. Both support SCM.
CCB, status accounting, audit and release
These terms make SCM sound difficult, but each answers a practical question.
The assigned authority reviews proposed changes to controlled items. In a small project, an authorised individual can fill this role; in a larger one, several stakeholders may be involved.
Record and report what happened to CR-17, the affected CIs and the baseline: proposed, accepted, implemented, tested, released or closed.
Check whether the selected product and supporting items match their approved description and whether the required evidence exists.
Two audit questions students can remember
- Functional check: Does the product perform the approved behaviour? For the due-date case, does it return ₹0?
- Physical/configuration check: Are the expected code, test, document and build versions actually present in the selected release?
A release record should identify the selected version, important approved requests, test result and delivery state. Merely saying “latest branch deployed” is weak because the latest branch can change again.
Practical limit: SCM increases control and traceability, but it cannot replace careful testing, good design or an honest decision about whether a requested change is useful.
Small Git illustration: the tool side of version control
This is an illustration of commands inside an existing Git project, not a complete approval process. File paths are examples; use your project's actual names. The branch can be brought into the release line only after the required review and tests.
git switch -c fix/cr-17-due-date
# Edit the fee logic and its test files.
git status
git add src/fee.js tests/fee.test.js
git commit -m "Fix due-date fee for CR-17"
git log --oneline -3Read it step by step: The branch separates the proposed correction. git status shows local changes. git add selects the files for the next commit. git commit records a snapshot with a meaningful message. git log shows recent commits. A review or release process must still decide whether the change is acceptable.
Never write this in an exam: “Git automatically approves every change.” Git stores and helps manage versions; approval comes from the team's change-control rules.
Exam-ready answers and quick revision
Define SCM, change control and version control.
SCM identifies and controls software items and their changes, records their status and versions, and supports verified releases. Change control evaluates and authorises proposed changes. Version control records and manages the history of files and their versions.
Explain the difference between change control and version control with an example.
Software Configuration Management keeps changes to important software items identifiable and controlled. Change control and version control perform different jobs within it.
Change control starts with a change request. The team records the reason, studies the impact on requirements, code, tests, cost and schedule, and an authorised person or CCB accepts, changes, defers or rejects the proposal. Approved work is then reviewed, tested and recorded. Version control stores the history of files, including commits, branches and selected versions. It helps developers compare and combine work, but a commit alone does not approve a change.
For example, the library team approves CR-17 to correct a due-date late-fee bug. That decision belongs to change control. The developer records the fee-module and test changes in Git; that belongs to version control. The release record connects the approved request to the tested version.
Explain Software Configuration Management and its major activities in detail.
Introduction: A software product includes code, requirements, tests, documents, build instructions and release information. These items change throughout development and after delivery. Software Configuration Management (SCM) identifies selected items, controls their changes, records their versions and status, checks consistency, and helps the team deliver an identifiable product.
Configuration identification: The team selects software configuration items (CIs) such as modules, requirement documents and test suites. Each item receives an identity and version. A baseline is an approved reference state of one or more related items at a defined point. Later modifications to a baseline are controlled.
Change control: A requester submits a change request with a reason and example. The team analyses how the proposal will affect other items, effort, risk and schedule. The authorised lead or Configuration Control Board (CCB) decides whether to accept, modify, defer or reject it. Approved changes are implemented, reviewed, tested and recorded. The level of formality should match the importance of the system.
Version control: A version control system keeps identifiable file histories. Commits record changes; branches support separate work; merges combine work; tags may help identify selected versions. Version control provides useful evidence and collaboration support, but it does not replace approval.
Status accounting: The team records and reports the status of CIs, baselines and change requests. For example, it should be possible to tell whether CR-17 is proposed, approved, implemented, tested or included in a release.
Auditing and release: A configuration audit checks that approved behaviour and selected product items agree with their records. Release management builds and delivers a known combination of tested versions, along with its release information.
Example and conclusion: If a library app wrongly charges ₹10 on a due-date return, the team checks the approved ₹0 rule, logs CR-17, analyses the effects on fees and receipts, approves the correction, records code and test changes in version control, verifies the cases, and releases the selected version. Thus SCM answers what was controlled, why it changed, which version contains the change and what was delivered.
Last-minute revision cards
Frequently asked questions
Is SCM only another name for Git?
No. Git is a version control tool. SCM also involves identifying controlled items, approving and tracking changes, baselines, status reporting, audits and release records.
Is every commit a new baseline?
No. A commit is a recorded version-history event. A baseline is a formally approved reference state; it follows the project's control procedure.
Must every change go to a large CCB meeting?
No. The decision authority depends on project size, risk and the affected baseline. A small project can have an authorised lead, while a critical change may need broader review.
Can change control reject a proposed improvement?
Yes. A proposal can be rejected or deferred if it is unclear, too risky, outside scope or not worth the cost at that point. Record the reason so the requester understands the decision.
What is the difference between a branch and a release?
A branch is a line of development work. A release is a selected, checked product version delivered to users, with its own record. Not every branch becomes a release.
Final thought: A good SCM record lets a new teammate answer one simple question without guessing: “Why is this exact version in the hands of users?” The answer should connect the approved rule, change request, file versions, tests and release.
