Question 6 of 8

Question 6 (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) — five software quality metrics.

• Defect density — number of confirmed defects per KLOC (or per function point) found during a defined period, e.g. testing or the first N months in production.
• Cyclomatic complexity (Q5b) — a structural complexity metric that correlates with defect-proneness and required test-case count.
• Review/inspection effectiveness — the percentage of total defects found by FTRs before test, indicating how much escapes to later, costlier stages.
• Mean time between failures (MTBF) — a reliability metric (Q1b) measured from operational failure data.
• Customer-reported problems (CRP) / fix backlog and average age — how many defects reach the customer and how long fixes take, a direct measure of field quality.

Part (b) — quality and maintainability. Maintainability — ease of correcting, adapting, and enhancing software after delivery — is itself one of the core software quality characteristics (alongside functionality, reliability, usability, efficiency and portability, per ISO/IEC 25010's product quality model). Higher overall quality (clear structure, low complexity, good documentation, adherence to coding standards) directly produces higher maintainability, because a maintainer must first understand code before safely changing it; conversely, poor quality (high complexity, poor cohesion, undocumented interfaces) makes every later change slower and riskier, and each rushed maintenance change tends to further erode structure — so quality and maintainability reinforce each other over the software's life cycle, not just at initial release.

Part (c) — software configuration management (SCM) and quality. SCM is the set of activities (identification, version control, change control, status accounting, audits) that manage change throughout the software life cycle by establishing controlled baselines. It affects quality in several concrete ways:

• Traceability and control of change — every change is requested, evaluated, approved, and recorded, preventing untracked/unauthorized modifications from silently degrading a working baseline.
• Reproducibility — a defect can always be traced to the exact baseline/version in which it was introduced, and a known-good baseline can always be restored, which is essential to both debugging and rollback.
• Consistency across the product — SCM ensures that documentation, tests, and source stay synchronized to the same baseline, so quality checks (reviews, tests) are always run against a coherent, identified configuration rather than a moving/ambiguous target.
• Supports parallel development safely — branch/merge and access-control discipline prevent one developer's in-progress change from corrupting another's, which matters directly for concurrent/agile development (a link back to Q8/the general SQA-plan question).