25-Comp-A6 Software Engineering · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — 17-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: eight questions, candidates answer any five (all questions equal weight — each of the five counted questions is worth 20%; any five questions constitute a complete paper, and only the first five as they appear in the answer book are marked). All eight questions are solved below for completeness. The page-1 heading reads "National Exams.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software reuse and portability, dependable/critical systems, distributed software engineering, configuration management, reliability metrics; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Leveson, Safeware — hazard and fault-tree analysis for safety-critical software.
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.
The two consequences stated in the question — short-term hypoglycemia (brain damage, death) from too much insulin, and long-term hyperglycemia (eye, kidney, heart damage) from too little — fix the two ends of the risk spectrum; hazard analysis works outward from them to the specific system-level failures capable of producing each. Because a demanded action here is a discrete, safety-relevant event (each computed dose is a "demand" on the pump), risk is assessed per hazard as likelihood of occurrence × severity of consequence, consistent with the POFOD-style reasoning used for demand-driven safety systems in Question 8(d) below.
| Hazard | Description | Severity | Risk classification |
|---|---|---|---|
| H1 | Insulin overdose delivered (commanded or actual dose too high) | Catastrophic — acute hypoglycemia, brain damage, death within minutes to hours | Intolerable — must be reduced by design, not accepted at any residual software-only probability |
| H2 | Insufficient insulin delivered, or no delivery at all, over a sustained period | Serious but not acute — long-term hyperglycemia damage accrues over days/weeks, not minutes | Undesirable — must be reduced, but the longer time-to-harm allows a detection/alarm window H1 does not |
| H3 | System fails to respond to a manual stop/override command from clinical staff | Catastrophic — removes the last line of defence against H1 or H2 once either is under way | Intolerable — the override path must not depend on the same software that might be malfunctioning |
| H4 | Power loss or reset stops the pump mid-dose, leaving the delivered amount unknown | Marginal to serious — ambiguous partial dose complicates the next correct dose calculation | Tolerable if annunciated — requires the resumed system to treat the interrupted dose as unknown, not zero |
| H5 | Spurious sensor/fault alarm causes an unnecessary pump shutdown | Marginal on its own; becomes an instance of H2 if not corrected promptly | Tolerable — acceptable provided it fails safe (stops dosing) and is promptly annunciated to staff |
H1 (insulin overdose) is both the most severe hazard and the one with the richest set of distinct root causes, so it is used as the top event for the fault tree below; H2 and H4/H5 share several of the same base events (a stuck sensor can cause either an overdose or, read the other way, an underdose) but are direct mirror images of the branches shown and are summarised in prose beneath the diagram.
Reading the tree bottom-up: an overdose (top event) results if either the controller is given a falsely low blood-sugar reading or its dosing algorithm itself miscalculates from a correct reading (C1), or the pump physically delivers more than whatever dose was correctly commanded because its actuator sticks open or its firmware ignores a stop signal (C2), or a dose that was itself computed and commanded correctly is nonetheless delivered a second time because of a spurious command retry or a communications fault that duplicates the message (C3). Every gate in this tree is an OR gate rather than an AND gate: because a single fault in any one basic event is sufficient, on its own, to cause the hazard, there is no combination of independent faults required, which is exactly why H1 is classed intolerable in part (a) rather than merely undesirable — a single-point failure in six different low-level places can each independently kill the patient. This is also the design implication of the tree, and the reasoning directly behind Question 2(b)'s interposed SafetyLimiter: reducing the risk to tolerable requires either converting one or more of these OR branches into an AND (e.g. requiring two independent sensors to agree, or an independent hardware watchdog to corroborate the software's dose calculation before the pump acts) or physically limiting the pump's maximum deliverable dose regardless of what any single component commands.
H2 (insufficient/no delivery) is the structural mirror of C1/C2 above — "sensor reports falsely high blood-sugar level," "dosing algorithm under-computes," "pump actuator stuck closed/occluded needle," "firmware fails to execute a deliver command" — combined with a distinct branch not present in the overdose tree: "system halts entirely" (power loss, watchdog reset, unhandled software exception), which produces zero delivery rather than a wrong non-zero delivery. H3 (fails to respond to manual override) traces to the override control sharing a single point of failure with the main controller (e.g. the stop button routed through the same microprocessor and firmware that may already be malfunctioning) — the fault-tree analysis itself is what surfaces the requirement, applied in the design, that the manual override must be wired through independent hardware that bypasses the main controller entirely.
