19-Soft-A6 Software Quality Assurance · December 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, December 2014 — 04-Soft-A6, Software Quality Assurance (open book, non-communicating calculator permitted, 3 hours). Per the paper's own notes, FIVE of the EIGHT questions constitute a complete exam and each is of equal value; all eight are answered in full below as a complete study resource.
Reference texts. Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 3 (agile and concurrent process models), Ch. 15 (SQA, cost of quality, configuration management), Ch. 17–18 (unit/integration/validation/system testing strategy, verification vs. validation), Ch. 19–20 (white-box basis-path testing, black-box equivalence partitioning & boundary value analysis); Sommerville, Software Engineering, 10th ed., Ch. 8 (Software Testing) and Ch. 24 (Quality Management); SWEBOK v4, Software Quality KA, Software Testing KA, and Software Configuration Management KA; ISO/IEC 25010 (SQuaRE) for the product quality model; ISO/IEC/IEEE 12207 (Software life cycle processes) for the SQA and configuration management process framework referenced in Questions 1 and 8.
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.
An FTR is a structured peer meeting (walkthrough or inspection) held on a work product — a requirements document, a design, a piece of code — with a defined moderator, recorder, and reviewers besides the producer. Its objectives are: to uncover errors in function, logic, or implementation for any representation of the software while the cost of fixing them is still low; to verify that the software under review actually meets its stated requirements; to ensure the software has been represented according to predefined standards (coding standards, documentation templates); to achieve software that is developed in a more uniform manner across a team or organisation; and to make projects more manageable by surfacing problems and status early rather than letting them stay hidden until a later, more expensive point. A secondary but real objective is that FTRs serve as a training ground, letting junior engineers observe how senior engineers approach analysis, design, and coding.
Agile software development is an iterative, incremental approach to building software in short, time-boxed cycles (sprints/iterations), guided by the Agile Manifesto's values — individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a fixed plan. Each iteration delivers a working, testable increment of the product, and requirements and priorities are re-evaluated and adapted continuously based on feedback rather than being frozen up front.
Under the Waterfall model, the FTR is a discrete, scheduled, heavily documented event at the boundary of each phase — a requirements review, a design review, a code review — run by a formal moderator with a recorder producing minutes and a tracked issues list, and the project does not formally proceed past the gate until the review's action items are closed. Because reviews are infrequent and phase-scoped, a defect rooted in an early phase can survive undetected across several later reviews if the review itself missed it.
Under agile development, the same underlying objectives from part (a) are pursued far more frequently and far less formally: pair programming functions as a continuous, real-time FTR of every line as it is written; a pull-request code review before merge substitutes for a scheduled design/code review, run by whichever teammate is available rather than a designated moderator; and the sprint review plus retrospective function as a lightweight, recurring audit that replaces a single project-end review. Formal minutes and a tracked issues list are usually replaced by lightweight tooling (PR comments, an issue tracker), but the review cadence is dramatically tighter — every commit or every sprint, rather than every phase — so a defect is typically caught within the same short cycle it was introduced in.
