Question 8 of 8

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 maintainability. Software maintainability is the ease with which a software system or component can be modified — to correct defects (corrective maintenance), improve performance or other attributes (perfective maintenance), adapt to a changed environment (adaptive maintenance), or prevent future problems (preventive maintenance) — without introducing new defects. It is one of the six ISO 9126 characteristics from Question 1(a), and is usually assessed through its sub-characteristics: analysability (how easily the cause of a deficiency can be diagnosed), changeability (how easily a specified modification can be implemented), stability (how much a change risks unexpected side effects elsewhere), and testability (how easily the modified software can be verified).

Part (b) — techniques to increase maintainability.

• High cohesion, low coupling in the design (Question 6b's design-quality factors) — a change localized to one well-defined module is far less likely to have unintended side effects elsewhere than a change to a module tangled with many others.
• Enforced coding standards and consistent style — a maintainer unfamiliar with a given module can read and understand it faster if it follows the same conventions as the rest of the codebase.
• Comprehensive, current documentation (design rationale, not just what the code does but why) — reduces the analysability effort of diagnosing where a defect or required change belongs.
• Automated regression test suites (Question 6) — let a maintainer verify a change has not broken existing behaviour quickly and with confidence, directly improving the "stability" sub-characteristic.
• Requirement/design traceability (Question 3c) — lets a maintainer see immediately which other artifacts (tests, other design elements) a given requirement or module touches before making a change.
• Refactoring as ongoing practice — deliberately improving internal structure without changing external behaviour, so complexity does not accumulate unchecked as the system evolves ("technical debt").

Part (c) — safety-critical vs. safety-related systems. A safety-critical system is one whose own failure can directly and immediately cause loss of life, serious injury, or major environmental/financial harm — e.g., aircraft flight-control software or a medical infusion-pump controller, where the software failure is itself the proximate cause of the hazard. A safety-related system contributes to overall safety but is not, by itself, the direct or sole cause of a catastrophic outcome if it fails — e.g., a monitoring/alarm subsystem that alerts a human operator: its failure removes a safety margin (the operator loses their warning) rather than directly causing the hazardous event. The main difference is therefore the directness and immediacy of the causal link between the software's own failure and a catastrophic outcome, and this distinction drives how much assurance effort (formal hazard analysis, independent verification, architectural redundancy) each class of system warrants: safety-critical systems require the highest achievable assurance level, while safety-related systems require above-average, but correspondingly lower, rigor.