Question 3 of 8

Question 3 (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) — approaches to quality management in projects.

• Quality planning — identifying which quality standards apply to the project and how they will be satisfied, before work begins (e.g., choosing which reviews, metrics and acceptance criteria the project will use).
• Quality assurance (process-focused) — auditing the project's own processes on an ongoing basis to confirm they conform to the plan and to organizational standards, independent of any single deliverable.
• Quality control (product-focused) — inspecting and testing the actual work products against their defined acceptance criteria, recording and tracking defects to closure.
• Continuous improvement — feeding lessons learned and defect-cause data back into the process itself so the same class of defect is less likely on the next project (mirrors CMM's higher maturity levels from Question 2a).

These four approaches together span the whole project rather than any one work product: planning sets the target, assurance and control confirm the process and the products respectively are hitting it, and improvement raises the target over time.

Part (b) — a simple project monitoring and control process.

1. Establish a baseline plan. Record the agreed schedule, budget, and scope so later progress has something concrete to be measured against.
2. Collect actual progress data regularly. At a fixed cadence (e.g., weekly), record actual effort spent, tasks completed, and defects found against the baseline.
3. Compare actual against planned (variance analysis). Identify schedule slippage, cost overrun, or scope creep by comparing the collected data to the baseline.
4. Decide and apply corrective action. Where a variance exceeds an agreed threshold, take a concrete action (re-allocate resources, adjust scope, escalate a risk) rather than merely recording the variance.
5. Re-baseline if the change is significant and approved. A formally approved scope or schedule change updates the baseline itself, so future monitoring compares against the current, agreed plan rather than a stale one.

Part (c) — the objective of requirement traceability. Requirement traceability's objective is to maintain a documented, verifiable link from each requirement forward through design, code, and test cases, and back again, so that at any point in the project it is possible to answer: which design elements and code implement this requirement, which test case(s) verify it, and — the reverse question — why does this design element or test case exist (which requirement does it trace back to). This supports impact analysis (a requirement change shows exactly which design/code/tests must also change), coverage verification (every requirement has at least one corresponding test case, and no design/code element exists that traces to no requirement, i.e., no "gold-plating"), and audit/certification evidence for regulated or safety-critical work.