Question 7 of 8

Question 7 (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) — the three principles: Quality, Management, Engineering. Software Engineering practice is commonly understood as the combination of three concerns operating together on every project, none of which is sufficient alone:

• Quality is the concern that the product actually conforms to its specified and implicit requirements throughout development — realized through SQA activities, standards, and reviews layered onto every phase, as described in Questions 1–3.
• Management is the concern of planning, organizing, staffing, directing and controlling the project — scheduling, resource allocation, risk management, and progress tracking — so that the quality and engineering activities actually get executed within the available budget and schedule (directly the subject of Question 5b's delayed-schedule scenario).
• Engineering is the systematic, disciplined and quantifiable technical approach applied to development itself — the methods, techniques and tools used to elicit requirements, design, construct and verify the software.

A project that is strong on Engineering but weak on Management typically slips schedule and budget even though the eventual product is technically sound; a project strong on Management but weak on Quality delivers on time but with defects that surface expensively after release; and a project weak on Engineering cannot be rescued by either of the other two, since there is no sound technical work to manage or assure the quality of. All three must be present together.

Part (b) — the role of procurement in quality control. When part of a system is bought rather than built — a COTS component, a subcontracted module, an outsourced service — the delivered product's overall quality still depends on that purchased piece, so procurement itself becomes a quality-control activity. This means: vendor selection and qualification (does the supplier have a track record and process maturity that supports the required quality level), specifying measurable acceptance criteria in the contract/statement of work (not just a functional description), incoming inspection and acceptance testing of the delivered component before it is integrated (treating a purchased component exactly like an internally produced work product that must pass its own quality gate), and ongoing monitoring/audit of vendor performance across the relationship. A defect in a purchased component is still a defect in the delivered system from the customer's point of view, so the organization remains accountable for the quality of everything it procures, not only what it builds itself.

Part (c) — the role of training in maintaining software quality. Training keeps engineers, reviewers and testers current on the tools, techniques, standards and domain knowledge the project actually needs, and it is what makes the earlier answers achievable in practice rather than only on paper: a coding standard only prevents defects if the developers applying it were trained on it; a code review only catches defects if the reviewer was trained to recognize them; a test plan only executes correctly if testers understand the technique being applied (e.g., state-based testing from Question 4). Training also reduces the variance between individual engineers' output, which is itself a quality factor — a team relying on one or two experienced "heroes" to catch defects the rest of the team cannot see has a quality process that does not scale and does not survive staff turnover, whereas institutionalized training embeds the needed skill across the whole team.