SWE Introduction to Software Engineering

Slides:



Advertisements
Similar presentations
Critical Systems Specification
Advertisements

Critical Systems Specification
Risk Management Introduction Risk Management Fundamentals
Chapter 12 – Dependability and Security Specification
Chapter 12 – Dependability and Security Specification
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 24 Slide 1 Critical Systems Validation 2.
TMS-RA04-A-01-02Page 1 of 20 The Risk Assessment Process.
Figures – Chapter 12.
Mr. R. R. Diwanji Techniques for Safety Improvements.
SWE Introduction to Software Engineering
Critical Systems Specification
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 30 Slide 1 Security Engineering.
1 Risk evaluation Risk treatment. 2 Risk Management Process Risk Management Process.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 9 Slide 1 Critical Systems Specification.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems.
©Ian Sommerville 2004Software Engineering, 7th edition. Insulin Pump Slide 1 An automated insulin pump.
©Ian Sommerville 2004Software Engineering, 7th edition. Insulin Pump Slide 1 The portable insulin pump Developing a dependability specification for the.
The embedded control software for a personal insulin pump
CIS 376 Bruce R. Maxim UM-Dearborn
 Lionel Briand Safety Analysis.  Lionel Briand Safety-critical Software Systems whose failure can threaten human life or cause serious.
Safety and Loss Control
The Mental Health Care Patient Management System
Software Dependability CIS 376 Bruce R. Maxim UM-Dearborn.
©Ian Sommerville 2006Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
Component-Based Software Engineering and Software Assurance SSW-540, Unit 12.
1 Copyright © 2003 M. E. Kabay. All rights reserved. Critical Systems Specification IS301 – Software Engineering Lecture #18 – M. E. Kabay,
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Concerned with activities involved in ensuring that software is delivered: on.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 2.
ERT 312 SAFETY & LOSS PREVENTION IN BIOPROCESS RISK ASSESSMENT Prepared by: Miss Hairul Nazirah Abdul Halim.
ERT 322 SAFETY AND LOSS PREVENTION RISK ASSESSMENT
Chapter 12 – Dependability and Security Specification
1 Chapter 3 Critical Systems. 2 Objectives To explain what is meant by a critical system where system failure can have severe human or economic consequence.
1 Chapter 5 Project management. 2 Project management : Is Organizing, planning and scheduling software projects.
Job Safety Analysis (JSA)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 3 Slide 1 Critical Systems 1.
FAULT TREE ANALYSIS (FTA). QUANTITATIVE RISK ANALYSIS Some of the commonly used quantitative risk assessment methods are; 1.Fault tree analysis (FTA)
Chapter 15: Risk Management
GE 116 Lecture 1 ENGR. MARVIN JAY T. SERRANO Lecturer.
Software Testing and Quality Assurance Software Quality Assurance 1.
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
Software Engineering, 8th edition. Chapter 5 1 Courtesy: ©Ian Sommerville 2006 Oct 13 th, 2008 Lecture # 6 Project management.
Risk management and disaster preparedness
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
Slide 1 Security Engineering. Slide 2 Objectives l To introduce issues that must be considered in the specification and design of secure software l To.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
©Ian Sommerville 2000Dependability Slide 1 Chapter 16 Dependability.
1 Software Testing and Quality Assurance Lecture 38 – Software Quality Assurance.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 4 Slide 1 Chapter 4: Project management l Organising, planning and scheduling software.
Lecturer: Eng. Mohamed Adam Isak PH.D Researcher in CS M.Sc. and B.Sc. of Information Technology Engineering, Lecturer in University of Somalia and Mogadishu.
ON “SOFTWARE ENGINEERING” SUBJECT TOPIC “RISK ANALYSIS AND MANAGEMENT” MASTER OF COMPUTER APPLICATION (5th Semester) Presented by: ANOOP GANGWAR SRMSCET,
1 Project management Organising, planning and scheduling software projects.
Chapter 12 – Safety Engineering
Critical Systems Specification
Dept. of Nuclear and Quantum Engineering
Safety and Risk.
Critical Systems Specification
JOB HAZARD ANALYSIS (JHA)
Chapter 12 – Safety Engineering
Computer in Safety-Critical Systems
Presentation transcript:

SWE 205 - Introduction to Software Engineering Lecture 17 – Critical System Specifications (Chapter 9)

Lecture Objectives Critical System Specifications To explain how dependability requirements may be identified by analyzing the risks faced by critical systems. Risk driven specifications

An Example A plane landed at Warsaw, Poland during a thunder storm. For nine seconds, the brakes on the computer-controlled braking system did not work. The investigation showed that the braking system has worked correctly according to its specification.

Dependability requirements Functional requirements to define error checking and recovery facilities and protection against system failures. Non-functional requirements defining the required reliability and availability of the system. Excluding requirements that define states and conditions that must not arise.

Risk-driven specification Critical systems specification should be risk-driven. This approach has been widely used in safety and security-critical systems. The aim of the specification process should be to understand the risks (safety, security, etc.) faced by the system; and to define requirements that reduce these risks.

Stages of risk-based analysis Risk identification Identify potential risks that may arise. Risk analysis and classification Assess the seriousness of each risk. Risk decomposition Decompose risks to discover their potential root causes. Risk reduction assessment Define how each risk must be taken into eliminated or reduced when the system is designed.

Risk identification Identify the risks faced by the critical system. In safety-critical systems, the risks are the hazards that can lead to accidents. In security-critical systems, the risks are the potential attacks on the system. In risk identification, you should identify risk classes and position risks in these classes Service failure; Electrical risks; …

Insulin pump risks Insulin overdose (service failure). Insulin under-dose (service failure). Power failure due to exhausted battery (electrical). Electrical interference with other medical equipment (electrical). Poor sensor and actuator contact (physical). Parts of machine break off in body (physical). Infection caused by introduction of machine (biological). Allergic reaction to materials or insulin (biological).

Risk analysis and classification The process is concerned with understanding the likelihood that a risk will arise and the potential consequences if an accident or incident should occur.

Risk analysis and classification Risks may be categorized as: Intolerable. Must never arise or result in an accident As low as reasonably practical (ALARP). Must minimise the possibility of risk given cost and schedule constraints Acceptable. The consequences of the risk are acceptable and no extra costs should be incurred to reduce hazard probability

Levels of risk

Social acceptability of risk The acceptability of a risk is determined by human, social and political considerations. In most societies, the boundaries between the regions are pushed upwards with time i.e. society is less willing to accept risk For example, the costs of cleaning up pollution may be less than the costs of preventing it but this may not be socially acceptable. Risk assessment is subjective Risks are identified as probable, unlikely, etc. This depends on who is making the assessment.

Risk assessment Estimate the risk probability and the risk severity. It is not normally possible to do this precisely so relative values are used such as ‘unlikely’, ‘rare’, ‘very high’, etc. The aim must be to exclude risks that are likely to arise or that have high severity.

Risk assessment - insulin pump

Risk decomposition Concerned with discovering the root causes of risks in a particular system. Techniques have been mostly derived from safety-critical systems and can be Inductive, bottom-up techniques. Start with a proposed system failure and assess the hazards that could arise from that failure; Deductive, top-down techniques. Start with a hazard and deduce what the causes of this could be.

Fault-tree analysis A deductive top-down technique. Put the risk or hazard at the root of the tree and identify the system states that could lead to that hazard. Where appropriate, link these with ‘and’ or ‘or’ conditions. A goal should be to minimize the number of single causes of system failure.

Insulin pump fault tree Let’s Draw a example together.

Risk reduction assessment The aim of this process is to identify dependability requirements that specify how the risks should be managed and ensure that accidents/incidents do not arise. Risk reduction strategies Risk avoidance; Risk detection and removal; Damage limitation.

Strategy use Normally, in critical systems, a mix of risk reduction strategies are used. In a chemical plant control system, the system will include sensors to detect and correct excess pressure in the reactor. However, it will also include an independent protection system that opens a relief valve if dangerously high pressure is detected.

Insulin pump - software risks Arithmetic error A computation causes the value of a variable to overflow or underflow; Maybe include an exception handler for each type of arithmetic error. Algorithmic error Compare dose to be delivered with previous dose or safe maximum doses. Reduce dose if too high.

Safety requirements - insulin pump

Key points Risk analysis is the basis for identifying system reliability requirements. Risk analysis is concerned with assessing the chances of a risk arising and classifying risks according to their seriousness.