1
Software Testing and Quality Assurance
Lecture 39 – Software Quality Assurance
2
Lecture Objectives Safety Engineering Approach Language of Hazard Analysis Requirements in Safety Lifecycles
3
Safety Engineering Approach Hazard analysis technique to determine
the safety aspects of the system Early in the development process, then Monitoring safety throughout the product
development process; and Ensuring that there is enough evidence to
build a safety case at the end of the product development process.
4
Safety Engineering Approach Requirements Analysis and Product
Definition Exploratory analyzes in the form a
preliminary hazard analysis (PHA). The hazards, potential situations that can
cause harm or environmental damage The potential cause list.
Good understanding of the safely aspects of the software
prior to going into the design and implementation phases.
5
Safety Engineering Approach Design and Implementation Phase
A deductive Approach – starts with potential situations of harm and works back to design or implementation elements.
An inductive Approach – Starts from components or subsystems failures and
Works back through sub-systems to see if hazard result is used to verify the safety elements in the design.
6
Safety Engineering Approach Defending in Depth - System that must
defend against situations of harm Must be ultra-reliable or There must be sufficient redundancy
Thus, safety related subsystem failure does not lead to safety related system failure.
7
Language of Hazard Analysis Hazards needs to be identified and
assessed as early in the development life cycle as possible.
First step – hazard identification Process of identifying those situations
which could lead to an accident under credible situations.
Using done as part of brainstorming methods.
8
Language of Hazard Analysis Hazards in turn are casued by failures
or failure modes. Failures – are unintended or states of
the system that can lead to a hazard. Failure mode – identify specific classes
of failures
9
Language of Hazard Analysis Error – unintended states of the system
that can lead to failure. Flaw – design/program defects that give
rise to errors when certain conditions are activated.
Fault – events that result when a flaw is activated.
10
A Case Study – The Okecie Accident Occurred because of an accident
sequence. Plane landed 750m down the runway and
traveling at 170 knots instead of the more usual 150 knots in torrential rain and heavy winds.
Aircraft failed to brake in time and hit an earthen wall at the end of the runway and burst into flames.
11
A Case Study – The Okecie Accident
12
A Case Study – The Okecie Accident
In normal conditions – A320 does not need a 2.8 KM runway to stop; Even in torrential rain it can land safely and
stop in under 1500m.
Consequences of the accident were assessed to be
major, but not catastrophic.
13
A Case Study – The Okecie Accident
Weather factors are believed to have contributed to the accident, Strong winds veered from a cross-wind to a
tail-wind on final approach. It was raining heavily.
Air Traffic Control (ATC) did not inform the crew of the change in wind direction.
14
A Case Study – The Okecie Accident
15
A Case Study – The Okecie Accident
AG is true if (WoW > 12 tonnes) and wheels spinning > 72 Km/hr) or
(wheels spinning > 72 km/hr and radio alt < 10 ft)
AG ‘at ground’WoW ‘weight on wheels’ &
Function of both wheels
Standing water on the runway caused the aircraft to
Aquaplane while braking and wheels were not spinning at
The required rate to activiate the braking logic.
16
A Case Study – The Okecie Accident
AG = False (weight on both wheels) WS = False (wheels spinning at > 72
KM/hr) Radio Alt = True (radio altimeter)
Logic was implemented correctly but the system failed.
This is quite probability a failure in requirements.
17
A Case Study – The Okecie Accident
Isolate the error, flaw and faults Error – was the assignment AG = False Flaw – we required AG = WoW > 12 tones
for both wheels Failure – arose because the flaw was
triggered in condition of wind and water on the runway.
18
Requirements in Safety Lifecycles
19
Requirements in Safety Lifecycles Initial Hazard List – the list of known
hazards in the domain or a list of hazards obtained from similar systems or prior versions etc.
Preliminary Hazard Analysis (PHA) Determining potential hazards for the new
system as well as The causes of failure leading to these
hazards
20
Requirements in Safety Lifecycles Consequence Analysis – we work from
design elements to hazards. Is predictive in nature and is carried out
before the design is completed. Used to provide information into the design
processes and is aimed to choosing between design alternatives.
Event trees, failure modes and effects analysis (FMEA) etc.
21
Requirements in Safety Lifecycles
Causal Analysis – typcially performed top-down. Working from hazards to design or model
element. Fault tree are the classic technique.
22
Key points Hazard analysis technique to determine the
safety aspects of the system Hazards needs to be identified and assessed
as early in the development life cycle as possible.
The safety lifecycle consists of a number of activities which are aimed at determining and verifying the safely functions of the system.