Modern Software Problems - The Technical and Social History of Software Engineering - page 362

• Failure to have any effective backup plans in place
• Failure to listen to expert advice
The Denver airport luggage system is one of the most widely studied software
problems in history. In spite of numerous articles and retroactive reports, it is inter-
esting that similar problems surfaced with luggage handling at Heathrow Terminal
5.
Lessons learned: The primary lessons learned from the airport fiasco are that op-
timistic estimates, poor quality control, and poor change control will inevitably
lead to schedule delays, cost overruns, possible termination of the project, and al-
most certain litigation.
Problem avoidance: There were so many different forms of problems with the
luggage system that no single method could have found them all. A synergistic
combination of requirements modeling, pre-test requirements and design inspec-
tions, static analysis of text, static analysis of all code, formal testing based on
formal test plans, and certified test personnel probably would have reduced the
defects to tolerable levels. Pair programming in such a complex architecture that
involved both hardware and software would have probably added confusion with
little value.
1996: Ariane 5 Rocket Explosion
On its maiden flight in 1996, the Ariane 5 rocket and four onboard satellites being
carried for deployment were destroyed at a cost of perhaps $500 million.
The apparent reason for the problem was an attempt to convert velocity data
from a 64-bit format to a 16-bit format. There was not enough space and an over-
flow condition occurred, thus shutting down navigation. The flight lasted just over
36 seconds.
Lessons learned: The lesson from this problem is that all mathematical operations
in navigation systems need to be verified before actually launching a vehicle.
Problem avoidance: This problem would certainly have been found by code in-
spections, perhaps in just a few minutes. It might also have been found by static
analysis and also by requirements modeling or pair programming.
The problem was obviously not found by testing, as it should have been. In this
case, there were probably poor assumptions on the part of whoever wrote the test
scripts and test cases that overflow would not occur.