Question 7 of 8: Configuration Management, Version Control, and Change Management

Question 7: Configuration Management, Version Control, and Change Management (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part a) — configuration management and its major tasks. Software configuration management (SCM) is the discipline of identifying, controlling, and tracking the components (and their versions) that together make up a specific, buildable/deployable instance of a system, so that at any point it is known exactly what is in a given release. Major tasks: (1) configuration identification — deciding what counts as a controlled item (source files, requirements, test cases) and naming/versioning it; (2) version control (Part b); (3) change control (Part c); (4) configuration status accounting — recording and reporting the state of each item and each baseline; (5) configuration audit — verifying a delivered baseline actually matches what its records claim; (6) release management — packaging a verified configuration for deployment.

Part b) — version control. Version control is the SCM task of tracking successive revisions of each controlled item, so any past version can be retrieved, differences between versions can be inspected, and multiple versions can coexist when needed. For configurable software systems: version control tracks not just a linear history but variants — e.g. separate, parallel branches for a "hospital A" configuration and a "hospital B" configuration of the same registration system, each independently versioned but sharing a common ancestor. For team-based development: version control lets multiple developers work on different parts of the same codebase concurrently, using branches for parallel work and merges to reconcile changes, with the shared repository as the single source of truth for "what is the current, agreed state of the code" — avoiding the classic problem of one developer's changes silently overwriting another's.

Part c) — relationship between configuration management and change management. Change management is the process of proposing, evaluating, approving, and tracking a specific change to the system; configuration management is the broader discipline that provides the infrastructure change management operates within — change management cannot function without SCM's version-controlled baselines to change from and to, and every approved change must be implemented as a new, identified configuration item version (Part b) so the change is itself trackable. In other words, change management is one of configuration management's major tasks (Part a's item 3), not a separate, parallel process: a change request is only meaningful against a known baseline, and the result of an approved change is a new baseline that SCM's status accounting and audit tasks then track.