19-Soft-A6 Software Quality Assurance · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
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) — CMM and its relation to software quality. The Capability Maturity Model describes five levels of organizational process maturity that an organization progresses through, each level defined by a set of Key Process Areas it must have institutionalized:
| Level | Name | Process characteristic |
|---|---|---|
| 1 | Initial | Ad hoc, even chaotic; success depends on individual heroics, not a repeatable process. |
| 2 | Repeatable | Basic project management (planning, tracking, requirements management) is in place, so past successes can be repeated on similar projects. |
| 3 | Defined | The software process is documented, standardized, and integrated into a organization-wide standard process used consistently across projects. |
| 4 | Managed | Detailed process and product quality measures are collected and used to quantitatively control the process. |
| 5 | Optimizing | Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas/technologies. |
CMM relates directly to software quality because it is process quality used as a predictor of product quality: an organization operating at Level 1 has no institutionalized mechanism to catch or prevent defects consistently across projects, so its product quality is unpredictable project to project, whereas a Level 4/5 organization measures defect data quantitatively and feeds it back to reduce defect injection rates over time. Each successive level effectively adds the process discipline (planning → standardization → measurement → optimization) needed to make quality outcomes repeatable rather than accidental, which is why CMM level is often used as a proxy for an organization's ability to reliably deliver quality software, particularly by customers selecting a contractor/vendor.
Part (b) — the Waterfall V-lifecycle model, and how it achieves quality. The V-model is a variant of the classic waterfall model that makes verification and validation explicit by pairing every development (specification) phase on the descending left leg of the "V" with a corresponding testing phase on the ascending right leg, joined at the bottom by coding. Each test phase verifies the software against the artifact produced by its paired development phase, rather than testing being deferred to a single phase at the very end.
High quality is achieved through the V-model in three ways. First, test planning starts early: because each right-leg phase is planned against its paired left-leg artifact, the acceptance test plan can be drafted as soon as requirements are baselined, long before any code exists, so test design defects (an untestable or ambiguous requirement) surface while they are still cheap to fix. Second, each level of testing targets the defects that level's paired phase is prone to — unit testing catches module-design/coding defects, integration testing catches architecture-design (interface) defects, system testing catches system-design defects, and acceptance testing catches requirements-level defects (is this what the customer actually needed) — so no single class of defect is left uncovered by a generic "test everything at the end" approach. Third, the explicit horizontal pairing forces traceability: a defect found during, say, integration testing points directly back to the architecture-design artifact it is meant to verify, making root-cause analysis and fix faster than an undifferentiated end-of-project test phase would allow.
