Java Reference
In-Depth Information
had masked problems with the underlying software. The safety features of the
Therac-25 were dominantly software-based, and the lurking problems emerged.
It turned out that if the operator mistyped a parameter and then corrected it in a
particular way, the software allowed the machine to deliver the maximum radia-
tion dose without diffusing it properly. It was such a strange error that techni-
cians testing the machine failed to reproduce the problem. At one point, one of
the machines that had clearly caused an overdose was put back into service after
technicians could find nothing wrong with it.
Analysts say that the software problems were only part of the reason the accidents
occurred. While there were fundamental programming errors, there was also
inadequate attention to safety issues in general. And one reason the machines
were used for so long was that the problems were not reported as accurately and
thoroughly as they should have been.
Lessons Learned
Software safety is the dominant issue in this case. When human lives are on the
line, it's difficult to imagine not doing everything possible to ensure that your
software is as robust as possible. It comes down to risk analysis. How much are
you willing to risk that a particular piece of software you're developing still con-
tains an error? For many applications, a problem might cause inconvenience to
the user and may have business implications, but other applications literally have
people's lives at stake.
This case is also an example of the difficulty of isolating the problem. For hun-
dreds of patients, the Therac-25 provided excellent treatment. One of the initial
complaints was dismissed without proper investigation or reporting. Later, when
a problem had clearly occurred, it could not be replicated. This was an example
of a truly exceptional situation—one that does not occur usually or under normal
circumstances.
Source: computingcases.org, IEEE Computer
 
Search WWH ::




Custom Search