Скачать презентацию Critical Systems Specification IS 301 Software Engineering Скачать презентацию Critical Systems Specification IS 301 Software Engineering

78f7066edd81919de42e59ccc0b0a45d.ppt

  • Количество слайдов: 21

Critical Systems Specification IS 301 – Software Engineering Lecture # 9 – 2004 -09 Critical Systems Specification IS 301 – Software Engineering Lecture # 9 – 2004 -09 -20 M. E. Kabay, Ph. D, CISSP Assoc. Prof. Information Assurance Division of Business & Management, Norwich University mailto: [email protected] edu V: 802. 479. 7937 1 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Topics covered Ø Risk-driven specification Ø Safety specification Ø Security specification Ø Software reliability Topics covered Ø Risk-driven specification Ø Safety specification Ø Security specification Ø Software reliability specification Today we will use 18 of Prof. Sommerville’s slides in class 3 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Dependability requirements Ø Functional requirements to define error checking and recovery facilities and protection 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. 4 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Risk-driven specification 7 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © Risk-driven specification 7 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Levels of risk Unacceptable region Risk cannot be tolerated Risk tolerated only if risk Levels of risk Unacceptable region Risk cannot be tolerated Risk tolerated only if risk reduction is impractical or grossly expensive ALARP region Acceptable region Neglible risk 11 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Risk assessment - insulin pump 14 Notes content copyright © 2004 Ian Sommerville. NU-specific Risk assessment - insulin pump 14 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Fault-tree analysis Ø A deductive top-down technique. Ø Put the risk or hazard at 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. 16 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Insulin pump fault tree 17 Notes content copyright © 2004 Ian Sommerville. NU-specific content Insulin pump fault tree 17 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Control system safety requirements 24 Notes content copyright © 2004 Ian Sommerville. NU-specific content Control system safety requirements 24 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

The safety life -cycle 25 Notes content copyright © 2004 Ian Sommerville. NU-specific content The safety life -cycle 25 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

The security specification process 29 Notes content copyright © 2004 Ian Sommerville. NU-specific content The security specification process 29 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Types of security requirement Ø Identification requirements. Ø Authentication requirements. Ø Authorization requirements. Ø Types of security requirement Ø Identification requirements. Ø Authentication requirements. Ø Authorization requirements. Ø Immunity requirements. Ø Integrity requirements. Ø Intrusion detection requirements. Ø Non-repudiation requirements. Ø Privacy requirements. Ø Security auditing requirements. Ø System maintenance security requirements. 32 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Reliability metrics Ø Reliability metrics are units of measurement of system reliability. Ø System Reliability metrics Ø Reliability metrics are units of measurement of system reliability. Ø System reliability is measured by counting the number of operational failures and, where appropriate, relating these to the demands made on the system and the time that the system has been operational. Ø A long-term measurement program is required to assess the reliability of critical systems. 37 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Reliability metrics 38 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © Reliability metrics 38 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Probability of failure on demand Ø This is the probability that the system will Probability of failure on demand Ø This is the probability that the system will fail when a service request is made. Useful when demands for service are intermittent and relatively infrequent. Ø Appropriate for protection systems where services are demanded occasionally and where there are serious consequence if the service is not delivered. Ø Relevant for many safety-critical systems with exception management components q. Emergency shutdown system in a chemical plant. 39 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Rate of fault occurrence (ROCOF) Ø Reflects the rate of occurrence of failure in Rate of fault occurrence (ROCOF) Ø Reflects the rate of occurrence of failure in the system. Ø ROCOF of 0. 002 means 2 failures are likely in each 1000 operational time units e. g. 2 failures per 1000 hours of operation. Ø Relevant for operating systems, transaction processing systems where the system has to process a large number of similar requests that are relatively frequent q. Credit card processing system, airline booking system. 40 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Mean time to failure Ø Measure of the time between observed failures of the Mean time to failure Ø Measure of the time between observed failures of the system. Is the reciprocal of ROCOF for stable systems. Ø MTTF of 500 means that the mean time between failures is 500 time units. Ø Relevant for systems with long transactions i. e. where system processing takes a long time. MTTF should be longer than transaction length q. Computer-aided design systems where a designer will work on a design for several hours, word processor systems. 41 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Availability Ø Measure of the fraction of the time that the system is available Availability Ø Measure of the fraction of the time that the system is available for use. Ø Takes repair and restart time into account Ø Availability of 0. 998 means software is available for 998 out of 1000 time units. Ø Relevant for non-stop, continuously running systems qtelephone switching systems, railway signaling systems. 42 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

Homework Ø Required q. By Mon 27 Sep 2004 q. Write an essay of Homework Ø Required q. By Mon 27 Sep 2004 q. Write an essay of 100 -200 words discussing question 9. 1 for 15 points q. Answer questions 9. 2, 9. 3 & 9. 6 for 10 points each q. For 20 points, answer question 9. 9 in detail. Note the phrase “Giving reasons…” Ø Optional q. By Monday 4 Oct 2004 q. Q. 9. 8 for 12 points with reasons q. Q. 9. 10 and/or 9. 12 @ 2 points each 52 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

REMINDER QUIZ #1 IN CLASS WED 22 SEP 2004 Chapters 1 - 5 53 REMINDER QUIZ #1 IN CLASS WED 22 SEP 2004 Chapters 1 - 5 53 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.

DISCUSSION 54 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 DISCUSSION 54 Notes content copyright © 2004 Ian Sommerville. NU-specific content copyright © 2004 M. E. Kabay. All rights reserved.