NivaarExam PrepOfficial exam papers ↗

25-Comp-A6 Software Engineering · May 2013

Question 8 of 9: Software Reliability

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

Notes on this paper

National Exams — May 2013 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: nine questions, candidates answer any five of the nine (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 nine questions are solved below for completeness.

Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, software testing, dependability and critical systems, reliability metrics, configuration management, real-time software engineering; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design vocabulary.

Question 8: Software Reliability (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)).