19-Soft-A6 Software Quality Assurance, May 2018, Q8

Question 8 (10 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.

Part (a) — software reliability. Software reliability is the probability of failure-free operation of a computer program, in a specified environment, for a specified period of time (Musa's classic definition). It is a statistical property measured against actual usage — not a binary "works/doesn't work" judgment — because the same program with the same latent defects can appear perfectly reliable to one user population (whose inputs never trigger the defect) and unreliable to another (whose usage profile exercises exactly the code path containing it).

Part (b) — techniques to increase reliability.

Fault avoidance/prevention. Rigorous requirements and design reviews, formal methods where warranted, and enforced coding standards reduce the number of latent defects introduced in the first place.
Fault tolerance. Redundancy techniques (N-version programming, recovery blocks), defensive input validation, and structured exception handling let the system survive a fault that does trigger without failing outright.
Operational-profile-driven testing. Testing weighted toward how the system will actually be used in the field (its operational profile) finds the defects most likely to be hit in practice, giving the best reliability improvement per hour of testing.
Systematic fault removal. Root-cause defect tracking, ensuring every found fault is actually fixed (not just worked around) and regression-tested, so the defect count genuinely decreases over successive releases rather than merely being hidden.
Reliability-aware design. Modularity that limits how far a single fault's effects can propagate, and simplicity that reduces the surface area for defects to hide in.

Part (c) — safety-critical vs. safety-related systems. A safety-critical system is one whose failure could directly cause loss of life, serious injury, or major environmental/financial damage — e.g., flight-control software or a medical infusion-pump controller, where the software's own failure is the proximate cause of the hazard. A safety-related (safety-involved) system contributes to an overall safety function without itself being the sole or direct cause of catastrophic harm if it fails — e.g., a monitoring or alarm subsystem that alerts a human operator to intervene: its failure degrades the safety margin (the operator loses their warning) but does not, by itself, directly cause the hazard the way a safety-critical control loop's failure would. The distinction matters practically because safety-critical systems warrant the heaviest reliability/verification investment (independent verification, formal hazard analysis, redundant architectures), while safety-related systems still need above-average rigor but can be engineered to a correspondingly lower (though still elevated) assurance level.

Topic: Reliability as a usage-weighted statistical property, layered reliability techniques, and the safety-critical/safety-related distinction.

Key relations: Reliability = P(no failure over duration t | specified environment). Reliability-improvement techniques = prevention + tolerance + operational-profile testing + fault removal + design. Safety-critical (direct hazard cause) vs. safety-related (contributes to, but is not the sole cause of, a hazard).

Why this works: reliability and safety are related but answer different questions — "how often does it fail?" (reliability) versus "how bad is it when it does?" (safety) — which is why a highly reliable system can still be classified safety-critical (a rare failure with catastrophic consequences still demands the highest assurance level), and why the reliability-improvement techniques in part (b) are necessary but not sufficient for a safety-critical system, which additionally needs hazard analysis targeting the specific failure modes that matter for safety.

Common pitfall: equating "reliable" with "safe" — a system that almost never fails (high reliability) can still be safety-critical if its rare failure is catastrophic, so safety-critical systems add hazard analysis and often architectural redundancy on top of, not instead of, standard reliability engineering.

Source: Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 15 (Quality Concepts, reliability & safety) & Ch. 26 (Product Metrics).

Question 8 of 8

Question 8 (10 marks)