Question 7 of 8: Software Configuration and the Change-Management Process

Question 7: Software Configuration and the Change-Management Process (9 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) — software configuration, illustrated on the Question-4 system. The configuration of a software system is the specific, consistent combination of versioned work products — source code modules, design documents, test cases, build/deployment scripts, and data schemas — that together constitute one identifiable, buildable and traceable version of the system at a point in time (Sommerville Ch. 25, "software configuration management"). Each individual versioned item is a configuration item (CI). For the Question-4 search & delivery tool, a representative configuration is:

A given release of the tool is a specific, recorded combination of exact versions of every one of these CIs; changing any one CI (e.g. bumping SearchEngine to v1.5) produces a new configuration, which is precisely why every CI must be independently version-controlled and why a release is only reproducible if the full set of CI versions it was built from is recorded.

Part b) — main activities of the change process. Change request (CR) submission — a stakeholder formally records a proposed change with its rationale. Impact analysis — the team assesses which CIs the change touches and what it costs/risks to make. Evaluation and approval — a change control authority (an individual PM on a small team, or a Change Control Board on a larger one) accepts, rejects, or defers the CR based on the impact analysis. Implementation — the approved change is made to the affected CIs. Verification and re-baselining — the changed CIs are re-tested and, once accepted, the configuration baseline is updated to reflect the new, current set of CI versions, with the change communicated to affected stakeholders.

Part c) — the change process under Waterfall vs. agile. Under Waterfall, the change process is deliberately heavyweight: a formal CR is submitted against a frozen baseline, a Change Control Board conducts a rigorous impact analysis (often touching multiple already-signed-off phase documents), and approval can take days to weeks — change is treated as an exception to be controlled and minimised, because it threatens a plan built on the assumption of stability. Under agile, the same five activities still occur, but far more lightly: a proposed change is simply a new or re-worded backlog item, "impact analysis" is a quick estimate/re-prioritisation conversation with the product owner during backlog refinement, "approval" is the product owner accepting it into a future sprint, and "re-baselining" happens automatically as the next sprint's increment supersedes the old one — change is treated as the expected, welcomed norm rather than an exception, consistent with the Agile Manifesto value of "responding to change over following a plan" already invoked in Question 2(b).