1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance

2 Lecture Objectives Software Safety

3 Safety in systems involving software is becoming important. For example, Computer Aided Dispatch Systems (CAD); Electronic Flight Control Systems (EFCS). Train Protection Systems; Chemical Plant control systems.

4 Software Safety We wish to avoid in engineering and operating our platforms is Accidents. The system that we build must avoid the hazards that lead to accidents.

5 Software Safety Accident – an event of sequence of events leading to harm; that is, death, injury, environmental damage or financial loss. Hazard – a physical situation or state of the platform that can lead to an accident.

6 Software Safety To understand the safely of a system Understand how they can fail. Investigate accidents and accident sequences To understand the sequence of events leading to the accident and to try and determine which subsystem failed. Accidents are usually caused by combination of failures and circumstances.

7 Software Safety Hazards are really accidents “waiting to happen”. They are the pre-conditions for an accident. In hazard identification We are concerned with thinking about the safety of the personal or the platform. Start from known accidents or consider possible accidents and work back to hazards. Brainstorming exercise.

8 Software safety is not just software Reliability Failure is key to understanding software reliability. Failure is deviation from the specified behavior of the system. For safely, it is always a deviation from the intended behavior; and where the deviation can lead to harm or damage.

9 Software safety is not just software Reliability In normal usage of word failure A system may be unreliable but still safe; It may be completely reliable but totally unsafe. What failure of the system lead to an unsafe system?

10 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.

11 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.

12 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.

13 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.

14 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.

15 Language of Hazard Analysis Hazards in turn are caused 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

16 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.

17 Key points Accidents and Hazards Accidents are usually caused by combination of failures and circumstances. Hazards are really accidents “waiting to happen”. Safety Engineering Approach