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

Question 7: Software Configuration, Variant Management, and the Change 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) — configuration and variant management. The configuration of a software system is the specific, consistent combination of versioned work products — source code modules, design documents (Figures 1–2), 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). Each individually versioned item is a configuration item (CI). Variant management is the discipline of managing several concurrently-maintained variants of the same product — e.g. an emergency reporting system deployed with a fire-department variant, a police variant, and an ambulance variant, each sharing a common core (Report/Record/Allocate) but differing in specific resource-type data and workflow rules — keeping track of which CIs are shared across variants and which are variant-specific, so a shared-core fix can be propagated to every variant without accidentally overwriting a variant-specific customisation.

Part b) — main configuration management activities. Configuration identification — naming and defining every CI that must be independently versioned. Change control — the formal (or lightweight, Part c) process by which a proposed change to a CI is evaluated, approved and applied. Version control — recording and retrieving the history of every CI's revisions, supporting concurrent, multi-developer work. Configuration auditing — verifying that a built/released configuration actually matches its recorded set of CI versions. Status accounting/reporting — recording and reporting, at any time, the current state of every CI and every pending change, so the exact contents of any given release remain traceable.

Part c) — the change process under Waterfall vs. agile. Under Waterfall, the change process is deliberately heavyweight: a formal change request (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. Under agile, the same 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, consistent with the Agile Manifesto's value of "responding to change over following a plan."