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 four standard software reliability metrics are the Probability of Failure on Demand (POFOD), appropriate when a system responds to discrete, safety- or business-relevant demands and a single missed demand matters; the Rate of Occurrence of Failures (ROCOF), appropriate for continuously operating systems where the concern is how often failures happen per unit of operating time; Mean Time To Failure (MTTF), the reciprocal-style view of ROCOF, useful when what matters to the user is the typical length of an uninterrupted working session; and Availability (AVAIL), the proportion of time the system is usable, appropriate when what matters commercially is simply whether the system is up and earning/serving when a user approaches it. The right metric for each system below follows directly from what a failure actually costs and how the system is used.
| System | Recommended metric | Reasoning | Approximate acceptable value |
|---|---|---|---|
| (a) ICU patient monitor | POFOD | Each abnormal-vital-sign event is a discrete "demand" for a correct alarm; a missed alarm can be fatal. | POFOD ≈ 10-5–10-6 per demand |
| (b) Word processor | ROCOF / MTTF | Continuously used interactive tool; occasional recoverable crashes (with autosave) are an inconvenience, not a safety issue. | ROCOF ≈ 1 failure per 100–500 hours of use |
| (c) Vending machine control | AVAIL, with POFOD on the vend transaction | Commercial concern is uptime for sales; a failed individual vend-on-payment is a costly but non-hazardous demand failure. | AVAIL ≈ 99–99.5%; POFOD ≈ 10-2–10-3 per vend |
| (d) Automotive brake control | POFOD | Each brake application is a discrete, life-critical demand; failure risks fatal injury, so the target must approach aviation-grade flight-critical levels. | POFOD ≈ 10-8–10-9 per demand |
| (e) Management report generator | MTTF / ROCOF | Low-consequence, periodic/batch use; a failure only delays a report and can simply be re-run. | MTTF measured in weeks of typical use is adequate |
