Forensic Software Engineering: Are Software Failures Symptomatic of Systemic Problems?

1. Forensic Software Engineering: Are Software Failures Symptomatic of Systemic Problems? Chris Johnson, University of Glasgow My name is Elisabeth

2. Software Induced Failures • Failure of software to perform an intended function • Includes elicitation and specification problems • Includes • Guam crash • Therac 25 • Ariane 5 • London Ambulance Computer-Aided Dispatch

3. Problem of Supporting Systemic Approaches to Software Failure • Theorem proving • Specification can be wrong • Environment can be wrong • Many possible paths • Model checking can help

4. Other Problems • Human factors • KA 801 captain/crew • Organizational issues • FAA oversight • SE techniques say what to do, not what happened

5. Problems of Framing Any Analysis of Software Failure • Stopping point? • CFIT • Aircraft was below minimum altitude • ATC personnel failed to notice altitude • Warning system was misconfigured • FAA did not ensure proper system function • FAA doesn’t certify ground-based systems • Public doesn’t pressure FAA to certify them • Researchers don’t inform public well enough

6. Existing Techniques • Fault trees • Specific software failure • Requirements engineering • Problems with requirements capture • Organizational issues • ? • Therac 25 • Flaws in software or bug-fixing process?

7. Further Problems • So, use all of them • Chooser may be biased • Tools find causal factors suited to them • Tools may be selectively deployed to show certain things

8. Problems of Assessing Intention in Software Development • Why did the software fail? • Why was the software erroneous? • Why was the whole island inhibited? • Why did Dulles look just like Tampa?

9. Intent Specifications • Developers include why as well as what • Extension of safety case (?) • External certification vs. internal development • Shows why sw is built this way • Shows why changes were made • Helps match code to design • Possibly better than current maintenance certification procedures

10. Problems of Assessing Human and Environmental Factors • Environment often hard to simulate • Mars • It is true because the experts say so? • SW often proprietary, can’t check • Can’t learn from mistakes

11. And Operator Error… • Who knows what people are thinking • Can’t recreate situation very well • People react differently, same people may not be available • Knowing what people did does not show why they did it • London Ambulance Report: what was or wasn’t intentional?

12. Problems of Making Adequate Recommendations • What about software process? • What in the process is bad? • Is other code built by this process okay? • Recommendations should be feasible & should include guidance • “Identify all implicit assumptions made by the code” • Shouldn’t set silly goals • “Totally reliable software”

13. Summary • No techniques involving systemic factors • No agreement about scope of cause • No guidance about analytical tools • All assumptions must be questioned for reused software • Want to know why as well as what

14. Summary (cont.) • Can’t always simulate conditions • Must consider human factors • Problems with scope because of consequences of recommendations • Must educate investigators & public

15. And a Few More Things… • Problem paper, not solution paper • Intent specifications can help • Maintaining safety cases & design docs • Especially for reuse • NTSB’s accident investigation academy • What will we teach them?

16. Mars Climate Orbiter & Mars Polar Lander • Faster, Better, Cheaper • Decided not to collect telemetry data • Signal was lost (expectedly) • Causes included • Long working hours • Communications problems • Deadline pressure

17. Goldin’s speech • Acknowledges environmental issues • Points to emergent problems • “System failed them”