Question 8 of 8: SQA and Configuration Management in Concurrent and Agile Development

Question 8: SQA and Configuration Management in Concurrent and Agile Development (10 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.

Software Configuration Management (SCM) — identifying configuration items, controlling and tracking versions, managing a formal change process, and auditing/reporting status — and SQA are two closely intertwined umbrella activities rather than independent disciplines. SCM supplies the traceable, controlled substrate (a permanent record of WHO changed WHAT, WHEN, and via commit/change-request messages, WHY) that SQA's own change-control and measurement activities (Question 2(a)) depend on to function at all; without it, SQA has no reliable way to attribute a defect to a specific change or to audit whether change control is actually being followed.

In concurrent software development — a process model in which analysis, design, coding, and testing for different subsystems proceed in parallel, each tracked through its own state-transition-like activity network against a shared project database — SCM's version and branch control becomes essential rather than merely convenient, because several team members may be modifying shared or related artifacts at the same time. Without disciplined SCM, two parallel workstreams can silently diverge or overwrite each other's work, invisible to SQA's own review and measurement activities until integration; WITH it, SQA can rely on SCM's audit trail to attribute a defect surfacing during integration to the specific concurrent change that introduced it, and the formal change-control process (Question 2's FTR-driven review) can be applied consistently across parallel streams rather than only within one.

In agile software development, SCM is embedded at a much finer grain: every commit is itself effectively a small baseline, continuous integration is triggered automatically from the version-control system on every commit and runs the automated regression suite (Question 3(b), Question 8's own test-automation discussion below) against it, and feature-branch/pull-request workflows fuse SCM's branching and merging directly with SQA's peer-review activity (Question 2(c)) into one continuous process rather than two separate ones. Because agile's commits are small and frequent, SCM's own change history makes impact analysis for regression-test selection (Question 3(b)) far more precise than it would be against large, infrequent Waterfall-style changes, since each individual change is small enough to reason about on its own.

The overall relation, in both models: the tighter and faster the development cadence becomes, the MORE — not less — SQA depends on automated, disciplined SCM to keep pace, because manual change-tracking simply cannot scale to a parallel-workstream or rapid-commit cadence; SCM is the mechanism that makes SQA's change-control and traceability activities possible at all once development stops being a single, slow, serial stream of work.