Question 4 of 8

Question 4 (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.

Part (a) — software configuration management (SCM) activities, and their relation to SQA.

• Configuration identification — selecting and uniquely naming the items to be controlled (requirements baseline, design documents, source modules, test plans) so any item can be unambiguously referenced.
• Version/baseline control — recording every change to a controlled item, and formally freezing a baseline at defined milestones so it can always be reproduced exactly as it existed at that point.
• Change control — a formal process (a change control board) that evaluates, approves or rejects, and tracks every proposed change to a baselined item before it is applied.
• Configuration status accounting — recording and reporting the status of every configuration item and every change, so at any time it is known which version of which item is in which state.
• Configuration audits — independently verifying that the actual configuration items match what the status accounting records say they should be, and that all approved changes have actually been incorporated.

These activities relate directly to SQA because SCM is what makes SQA's audits and reviews meaningful and repeatable: an SQA audit of a design document is only valid if it is auditing a known, version-controlled baseline of that document, and a defect fix verified during SQA review is only trustworthy if change control guarantees no other unreviewed change slipped in alongside it. SCM therefore provides the controlled, known-state artifacts that SQA activities (Questions 1–3) are performed against; without SCM, SQA would be reviewing a constantly shifting, unversioned target.

Part (b) — roles of Document Control Management and Source Control Management. Document Control Management is the SCM discipline applied to non-code work products — requirements specifications, design documents, test plans, user manuals — and its role is to ensure every reader is looking at the current, approved version: it assigns document identifiers and version numbers, routes documents through review/approval before release, maintains a controlled distribution list (so obsolete copies are recalled/marked superseded), and archives superseded versions for audit and historical traceability. Source Control Management (source/version control, e.g., Git) applies the same version-and-change-control discipline specifically to source code: every change is committed with an identifiable author, timestamp and rationale; branches allow parallel work to proceed without corrupting a stable baseline; merges are reviewed before being integrated; and the full history of every file is retained so any prior version can be reproduced exactly, which is what makes a defect reported against "version 3.2" reproducible and fixable rather than ambiguous. Both roles exist to guarantee that whichever artifact is being reviewed, tested, or shipped is a known, identifiable, and reproducible version — the same underlying need addressed by two different classes of work product.