25-Comp-A6 Software Engineering · December 2018
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2018 — 17-Comp-A6 Software Engineering. Three-hour, closed-book, no-calculator exam. Format: eight questions, candidates answer any five of the eight (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All eight questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, requirements engineering, software testing, software reuse, software reliability, client-server architectures, software verification and validation; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design/reuse vocabulary.
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.
Sommerville's standard reliability metrics measure fundamentally different kinds of dependability property, so the right metric for each fault class follows from what kind of consequence that class has — a discrete per-event failure vs. a duration-based loss of service.
| Fault class | Nature of consequence | Recommended metric | Why |
|---|---|---|---|
| (1) Faults that corrupt data | Discrete, per-transaction event with severe downstream consequences (wrong stock/price data persists) | POFOD (Probability of Failure On Demand) | Each bar-code lookup is a discrete "demand"; data corruption is a rare, high-severity discrete event best expressed as a probability per demand, e.g. target ≤10−6 corruptions per transaction, reflecting its severity |
| (2) Faults that cause the system to become unavailable | Duration-based loss of service over the trading day | AVAIL (Availability), supported by ROCOF (Rate of Occurrence of Failures) | The requirement is explicitly stated as continuous availability during opening hours — availability (% of opening hours the system is up) is the direct metric, with ROCOF (outages per hour) as a secondary target bounding how often even short outages are tolerated |
| (3) Faults that transmit incorrect information to the terminal | Discrete, per-transaction event, lower severity than data corruption (a wrong price shown is correctable at the till, not a persistent database error) | POFOD, with a looser target than class (1) | Also a discrete per-demand event, but a wrong displayed price is typically caught and corrected before money changes hands, so a materially looser POFOD target (e.g. ≤10−4) than class (1) is appropriate to its lower severity |
A single blended reliability metric for all three classes is not advisable, even though it is numerically possible to combine them (e.g. a single weighted composite score). The three classes differ in kind, not just severity: class (2) is fundamentally a duration property (what fraction of time is the system usable at all) while classes (1) and (3) are per-event probabilities conditioned on the system actually being available to process a demand in the first place — averaging a duration-based and two probability-based metrics into one number would obscure exactly the distinction the question asks for ("some faults are more serious than others"), since a system could hit an attractive blended score by being highly available while still corrupting data at an unacceptable rate, or vice versa. The better approach is to specify three separate targets, one per fault class, each with an SLA-style acceptance threshold reflecting that class's own severity, rather than one combined figure.
