1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

22
1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance
  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    240
  • download

    3

Transcript of 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

Page 1: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

1

Software Testing and Quality Assurance

Lecture 39 – Software Quality Assurance

Page 2: 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

Page 3: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 4: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 5: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 6: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 7: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 8: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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

Page 9: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 10: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 11: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

11

A Case Study – The Okecie Accident

Page 12: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 13: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 14: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

14

A Case Study – The Okecie Accident

Page 15: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 16: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 17: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 18: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

18

Requirements in Safety Lifecycles

Page 19: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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

Page 20: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 21: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.

Page 22: 1 Software Testing and Quality Assurance Lecture 39 – Software Quality Assurance.

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.