0% found this document useful (0 votes)
11 views4 pages

Therac-25 Software Failures Analysis

Uploaded by

mhassanaziz.2005
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views4 pages

Therac-25 Software Failures Analysis

Uploaded by

mhassanaziz.2005
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

ASSIGNMENT 01

BSCS-4B

SOFTWARE ENGINEERING
231678_BSCS-3B

AROOBA
231678@[Link]
QUESTION NO 1:
Summarize the key events and technical details surrounding the
Therac-25 Incidents. Describe the functionalities of the Therac-25
machine and the role of software in its Operation?
The Therac-25 was a radiation therapy machine that caused six overdoses (1985-1987) due to
software errors and lack of hardware safety interlocks, leading to severe injuries and deaths. A
race condition in the software allowed unsafe configurations, and misleading error messages hid
critical failures. The machine lacked independent safety checks, relying entirely on faulty
software. AECL’s poor testing and failure to investigate early incidents worsened the problem.
The tragedy emphasized the need for defensive software design, rigorous testing, and
independent safety mechanisms in critical systems.

QUESTION NO 2:
Analyze the software-related failures that occurred in the Therac-25
system. Discuss issues such as software design flaws, inadequate
testing procedures, and insufficient error handling mechanisms.
The Therac-25 software failures stemmed from poor design, inadequate testing, and lack of
error handling. A race condition in the software caused incorrect mode settings, leading to
radiation overdoses. AECL did minimal unit testing and relied on system testing, failing to
catch critical bugs. Error messages were misleading, preventing operators from recognizing
dangerous malfunctions. The software lacked self-checks and defensive mechanisms, making
it the sole point of failure without hardware safeguards.

QUESTION NO 3:
Explore the root causes behind the software failures identified in the
Therac-25 incidents. Investigate factors such as organizational
culture, lack of communication between software developers and
users, and regulatory oversight.
The root causes of the Therac-25 failures included overconfidence in software, assuming it
was infallible. Poor communication between developers and operators led to
misunderstandings of system behavior. AECL’s lack of rigorous testing and quality
assurance resulted in undetected critical bugs. Regulatory oversight was weak, delaying
necessary interventions. A complacent organizational culture ignored early warning signs,
failing to prioritize safety in software design.

QUESTION NO 4:
Evaluate the consequences of the Therac-25 incidents on various
stakeholders, including patients, medical professionals, and the
manufacturer. Discuss the ethical, legal, and financial implications of
the software failures.
The Therac-25 incidents had severe consequences: Patients suffered radiation overdoses,
leading to injuries and deaths. Medical professionals faced trust issues and operational risks
due to unreliable equipment. AECL, the manufacturer, faced lawsuits, financial losses, and
reputational damage. Ethically, AECL failed in ensuring patient safety by neglecting
rigorous testing. Legally, the case highlighted the need for stricter regulations in medical
device software.

QUESTION NO 5:
Identify key lessons that can be learned from the Therac-25 incident
regarding software safety, risk management, and quality assurance
practices in engineering projects. Discuss strategies for preventing
similar incidents in the future.
Key lessons from the Therac-25 incident include:

Software Safety – Never rely solely on software for critical safety functions; implement
hardware interlocks as backups.

Risk Management – Conduct thorough hazard analysis, considering worst-case scenarios


and eliminating single points of failure.

Quality Assurance – Enforce rigorous testing, including unit testing, system testing, and
regression testing, to catch hidden flaws.

Clear Communication – Ensure collaboration between developers, engineers, and operators


to identify risks early.
Regulatory Compliance – Strengthen oversight, reporting, and auditing of software in safety-
critical systems.

To prevent similar incidents, organizations must adopt defensive programming, independent


verification, and continuous monitoring of software performance.

You might also like