WHY THEY FAILED AND LESSONS TO BE DRAWN

Samuel FranklinG53QAT: Quality Assurance and Testing

Famous Software Failures

Overview Three Software Failures

Patriot Missile Russian Satellite Missile Detection London Ambulance Service

Summary of Findings Questions

The Patriot Missile Failure

Feb 1991 – Gulf War Failed to intercept

Scud missile from Iraq 28 dead 100 injured Error from storing

value in fixed point register

The Patriot Failing The Patriot in action

Why it went wrongHours Seconds Calculated Time (sec) Inaccuracy (sec) Approx. shift in Range Gate

(meters)

0 0 0 0 01 3600 3599.9966        .0034 78 28800 8799.9725        .0025 55

20(a) 72000 71999.9313        .0687 13748 172800 172799.8352        .1648 33072 259200 259199.7528        .2472 494

100(b) 360000 359999.6667        .3433 687

The system had been running for 100 hours

The calculations were out by 0.34 seconds

Missed the Scud by over 600 metersWOULD MISS AFTER 20 HOURS

What American learnt from this USA knew of the fault from Israeli Military American’s did not reboot regularly enough Software update arrived day after the death of

the soldiers

Russian Satellite Missile Detection System

Put in place to detect threats from America during cold war

Stanislav Petrov monitored system on 26th September 1983

Oko alerted Petrov that 5 missiles were heading towards Russia.

Petrov had to choose: Declare it a false alarm Start a counterstrike and probably

a Nuclear war

Stanislav Petrov The Man Who Saved the World

What Russia learnt from this The Russians dissected the Oko

System Found the software full of bugs Launched the SPRN-2 Prognoz to

supplement the Oko system Cost of this failure could have been:

World War III

London Ambulance Fiasco London Ambulance

Service (LAS) introuduced a Computer Aided Dispatch System (CAD) on 26th October 1992

LAS:• Carry over 5000 patients per

day• Receive approx 2500 calls per

day• 65% of calls are emergency

New system needed to have near 100% accuracy and full cooperation from all LAS to succeed

26th October 1992

The new CAD system could not handle the volume of call – regular use

Response time became several hours Communications between ambulance

and LAS lost System had:

Poor interface between crews and the system

Number of technical problems: Failed to identify duplicate calls Did not prioritise exception messages

What London learnt from thisDo not use direct conversion

Implement in step-by-step fashion Full consultation Quality assurance and testing User training

Conclusion Testing is essential All critical systems Rush to get system in place is bad Training Value of humans in the process

Any questions?

Questions and Discussion