NivaarExam PrepOfficial exam papers ↗

25-Comp-A6 Software Engineering · December 2014

Question 8 of 10: Software Reliability

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams — December 2014 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: ten questions, candidates answer any six (all questions equal weight — each question carries 20 marks, so the paper is marked out of 120; only the first six questions as they appear in the answer book are marked). All ten questions are solved below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, real-time systems, software testing, configuration management, dependable/critical systems, reliability engineering, component-based software engineering; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/testing/quality coverage; IEEE/ISO 12207 — software life-cycle processes; SWEBOK — body-of-knowledge cross-reference.

Question 8: Software Reliability (a) 4, (b) 4, (c) 4, (d) 4, (e) 4 — 20 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.

Approach

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.

SystemRecommended metricReasoningApproximate acceptable value
(a) ICU patient monitorPOFODEach 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 processorROCOF / MTTFContinuously 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 controlAVAIL, with POFOD on the vend transactionCommercial 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 controlPOFODEach 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 generatorMTTF / ROCOFLow-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
Check
The numeric targets above are illustrative orders of magnitude, chosen to be internally consistent with the stated criticality ranking (brake control > ICU monitor > vending machine > word processor > report generator, most to least demanding) rather than measured figures from any specific certified product; exact acceptable values are set by the applicable safety standard for each domain (e.g. automotive functional-safety standards for (d), medical-device standards for (a)).