Enviar búsqueda
Cargar
Software Engineering - Ch9
•
5 recomendaciones
•
3,444 vistas
S
Siddharth Ayer
Seguir
Tecnología
Empresariales
Denunciar
Compartir
Denunciar
Compartir
1 de 50
Descargar ahora
Descargar para leer sin conexión
Recomendados
Software Engineering - Ch3
Software Engineering - Ch3
Siddharth Ayer
Software Engineering - Ch6
Software Engineering - Ch6
Siddharth Ayer
System Design
System Design
university of education,Lahore
Software Engineering - Ch12
Software Engineering - Ch12
Siddharth Ayer
Software reliability
Software reliability
Anand Kumar
Sdlc 4
Sdlc 4
university of education,Lahore
Introduction to Software Enigneering
Introduction to Software Enigneering
university of education,Lahore
Ch14-Software Engineering 9
Ch14-Software Engineering 9
Ian Sommerville
Recomendados
Software Engineering - Ch3
Software Engineering - Ch3
Siddharth Ayer
Software Engineering - Ch6
Software Engineering - Ch6
Siddharth Ayer
System Design
System Design
university of education,Lahore
Software Engineering - Ch12
Software Engineering - Ch12
Siddharth Ayer
Software reliability
Software reliability
Anand Kumar
Sdlc 4
Sdlc 4
university of education,Lahore
Introduction to Software Enigneering
Introduction to Software Enigneering
university of education,Lahore
Ch14-Software Engineering 9
Ch14-Software Engineering 9
Ian Sommerville
Software maintenance
Software maintenance
NancyBeaulah_R
Software maintenance ppt
Software maintenance ppt
Anas Usman
Chapter 7 software reliability
Chapter 7 software reliability
despicable me
3 introduction
3 introduction
AlenaDion
12 software maintenance
12 software maintenance
University of Computer Science and Technology
Software reliability & quality
Software reliability & quality
Nur Islam
Software Processes
Software Processes
university of education,Lahore
Software reliability tools and common software errors
Software reliability tools and common software errors
Himanshu
Quality & Reliability in Software Engineering
Quality & Reliability in Software Engineering
SivaRamaSundar Devasubramaniam
Ch15 software reliability
Ch15 software reliability
Abraham Paul
Software Engineering - Ch8
Software Engineering - Ch8
Siddharth Ayer
Ch8.testing
Ch8.testing
software-engineering-book
Software Evolution
Software Evolution
Muhammad Asim
Ch13-Software Engineering 9
Ch13-Software Engineering 9
Ian Sommerville
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
Mohammed Romi
Software Engineering - Ch5
Software Engineering - Ch5
Siddharth Ayer
Software and Hardware Reliability
Software and Hardware Reliability
Sandeep Patalay
Software Reliability
Software Reliability
Gurkamal Rakhra
Software Verification & Validation
Software Verification & Validation
university of education,Lahore
Software reliability engineering process
Software reliability engineering process
Himanshu
Software Engineering - Ch2
Software Engineering - Ch2
Siddharth Ayer
Software Engineering - Ch11
Software Engineering - Ch11
Siddharth Ayer
Más contenido relacionado
La actualidad más candente
Software maintenance
Software maintenance
NancyBeaulah_R
Software maintenance ppt
Software maintenance ppt
Anas Usman
Chapter 7 software reliability
Chapter 7 software reliability
despicable me
3 introduction
3 introduction
AlenaDion
12 software maintenance
12 software maintenance
University of Computer Science and Technology
Software reliability & quality
Software reliability & quality
Nur Islam
Software Processes
Software Processes
university of education,Lahore
Software reliability tools and common software errors
Software reliability tools and common software errors
Himanshu
Quality & Reliability in Software Engineering
Quality & Reliability in Software Engineering
SivaRamaSundar Devasubramaniam
Ch15 software reliability
Ch15 software reliability
Abraham Paul
Software Engineering - Ch8
Software Engineering - Ch8
Siddharth Ayer
Ch8.testing
Ch8.testing
software-engineering-book
Software Evolution
Software Evolution
Muhammad Asim
Ch13-Software Engineering 9
Ch13-Software Engineering 9
Ian Sommerville
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
Mohammed Romi
Software Engineering - Ch5
Software Engineering - Ch5
Siddharth Ayer
Software and Hardware Reliability
Software and Hardware Reliability
Sandeep Patalay
Software Reliability
Software Reliability
Gurkamal Rakhra
Software Verification & Validation
Software Verification & Validation
university of education,Lahore
Software reliability engineering process
Software reliability engineering process
Himanshu
La actualidad más candente
(20)
Software maintenance
Software maintenance
Software maintenance ppt
Software maintenance ppt
Chapter 7 software reliability
Chapter 7 software reliability
3 introduction
3 introduction
12 software maintenance
12 software maintenance
Software reliability & quality
Software reliability & quality
Software Processes
Software Processes
Software reliability tools and common software errors
Software reliability tools and common software errors
Quality & Reliability in Software Engineering
Quality & Reliability in Software Engineering
Ch15 software reliability
Ch15 software reliability
Software Engineering - Ch8
Software Engineering - Ch8
Ch8.testing
Ch8.testing
Software Evolution
Software Evolution
Ch13-Software Engineering 9
Ch13-Software Engineering 9
Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
Software Engineering - Ch5
Software Engineering - Ch5
Software and Hardware Reliability
Software and Hardware Reliability
Software Reliability
Software Reliability
Software Verification & Validation
Software Verification & Validation
Software reliability engineering process
Software reliability engineering process
Destacado
Software Engineering - Ch2
Software Engineering - Ch2
Siddharth Ayer
Software Engineering - Ch11
Software Engineering - Ch11
Siddharth Ayer
Software Engineering - Ch4
Software Engineering - Ch4
Siddharth Ayer
Software Engineering - Ch17
Software Engineering - Ch17
Siddharth Ayer
Slides chapters 6-7
Slides chapters 6-7
Priyanka Shetty
Software Engineering - Ch1
Software Engineering - Ch1
Siddharth Ayer
Ch2-Software Engineering 9
Ch2-Software Engineering 9
Ian Sommerville
Software Engineering UPTU
Software Engineering UPTU
Rishi Shukla
Ch1-Software Engineering 9
Ch1-Software Engineering 9
Ian Sommerville
Destacado
(9)
Software Engineering - Ch2
Software Engineering - Ch2
Software Engineering - Ch11
Software Engineering - Ch11
Software Engineering - Ch4
Software Engineering - Ch4
Software Engineering - Ch17
Software Engineering - Ch17
Slides chapters 6-7
Slides chapters 6-7
Software Engineering - Ch1
Software Engineering - Ch1
Ch2-Software Engineering 9
Ch2-Software Engineering 9
Software Engineering UPTU
Software Engineering UPTU
Ch1-Software Engineering 9
Ch1-Software Engineering 9
Similar a Software Engineering - Ch9
Ch12
Ch12
Keith Jasper Mier
Ch12-Software Engineering 9
Ch12-Software Engineering 9
Ian Sommerville
Sil explained in valve actuators
Sil explained in valve actuators
John Kingsley
T89 introductiontofunctionalsafetyformachinery
T89 introductiontofunctionalsafetyformachinery
Vo Quoc Hieu
Ch9
Ch9
phanleson
Ch12 safety engineering
Ch12 safety engineering
software-engineering-book
Ch3
Ch3
Tashaf Mukhtar
Ch12 - Safety Engineering
Ch12 - Safety Engineering
Harsh Verdhan Raj
System safety
System safety
sommerville-videos
CS 5032 L5 safety specification 2013
CS 5032 L5 safety specification 2013
Ian Sommerville
Understanding sil
Understanding sil
rajesh kumar ramaswamy
Critical systems specification
Critical systems specification
Aryan Ajmer
HAZARD IDENTIFICATION AND RISK ASSESSMENT IN WATCH MANUFACTURING PROCESS
HAZARD IDENTIFICATION AND RISK ASSESSMENT IN WATCH MANUFACTURING PROCESS
IRJET Journal
Vijeo citect quick start tutorial - part 1 ver d
Vijeo citect quick start tutorial - part 1 ver d
Abdul Budiman
1. safety instrumented systems
1. safety instrumented systems
Saiful Chowdhury
A Novel Approach to Derive the Average-Case Behavior of Distributed Embedded ...
A Novel Approach to Derive the Average-Case Behavior of Distributed Embedded ...
ijccmsjournal
SIL.ppt
SIL.ppt
Krishna Yadav
Iec61508 guide
Iec61508 guide
ronnyalex2013
Health apps regulation and quality control case studies and session 2 present...
Health apps regulation and quality control case studies and session 2 present...
3GDR
Health apps regulation and quality control case studies and session 2 present...
Health apps regulation and quality control case studies and session 2 present...
3GDR
Similar a Software Engineering - Ch9
(20)
Ch12
Ch12
Ch12-Software Engineering 9
Ch12-Software Engineering 9
Sil explained in valve actuators
Sil explained in valve actuators
T89 introductiontofunctionalsafetyformachinery
T89 introductiontofunctionalsafetyformachinery
Ch9
Ch9
Ch12 safety engineering
Ch12 safety engineering
Ch3
Ch3
Ch12 - Safety Engineering
Ch12 - Safety Engineering
System safety
System safety
CS 5032 L5 safety specification 2013
CS 5032 L5 safety specification 2013
Understanding sil
Understanding sil
Critical systems specification
Critical systems specification
HAZARD IDENTIFICATION AND RISK ASSESSMENT IN WATCH MANUFACTURING PROCESS
HAZARD IDENTIFICATION AND RISK ASSESSMENT IN WATCH MANUFACTURING PROCESS
Vijeo citect quick start tutorial - part 1 ver d
Vijeo citect quick start tutorial - part 1 ver d
1. safety instrumented systems
1. safety instrumented systems
A Novel Approach to Derive the Average-Case Behavior of Distributed Embedded ...
A Novel Approach to Derive the Average-Case Behavior of Distributed Embedded ...
SIL.ppt
SIL.ppt
Iec61508 guide
Iec61508 guide
Health apps regulation and quality control case studies and session 2 present...
Health apps regulation and quality control case studies and session 2 present...
Health apps regulation and quality control case studies and session 2 present...
Health apps regulation and quality control case studies and session 2 present...
Último
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
Martijn de Jong
Slack Application Development 101 Slides
Slack Application Development 101 Slides
praypatel2
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
Delhi Call girls
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
sudhanshuwaghmare1
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
ThousandEyes
Breaking the Kubernetes Kill Chain: Host Path Mount
Breaking the Kubernetes Kill Chain: Host Path Mount
Puma Security, LLC
A Call to Action for Generative AI in 2024
A Call to Action for Generative AI in 2024
Results
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
The Digital Insurer
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
hans926745
Handwritten Text Recognition for manuscripts and early printed texts
Handwritten Text Recognition for manuscripts and early printed texts
Maria Levchenko
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024
Rafal Los
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Drew Madelung
CNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of Service
giselly40
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
wesley chun
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
Delhi Call girls
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
Delhi Call girls
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
Safe Software
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024
The Digital Insurer
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
UK Journal
IAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI Solutions
Enterprise Knowledge
Último
(20)
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
Slack Application Development 101 Slides
Slack Application Development 101 Slides
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
Breaking the Kubernetes Kill Chain: Host Path Mount
Breaking the Kubernetes Kill Chain: Host Path Mount
A Call to Action for Generative AI in 2024
A Call to Action for Generative AI in 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
Handwritten Text Recognition for manuscripts and early printed texts
Handwritten Text Recognition for manuscripts and early printed texts
The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
CNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of Service
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
08448380779 Call Girls In Greater Kailash - I Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
IAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI Solutions
Software Engineering - Ch9
1.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification
2.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 2 Objectives ● To explain how dependability requirements may be identified by analysing the risks faced by critical systems ● To explain how safety requirements are generated from the system risk analysis ● To explain the derivation of security requirements ● To describe metrics used for reliability specification
3.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 3 Topics covered ● Risk-driven specification ● Safety specification ● Security specification ● Software reliability specification
4.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 4 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.
5.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 5 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.
6.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 6 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.
7.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 7 Risk-driven specification
8.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 8 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; • …
9.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 9 Insulin pump risks ● Insulin overdose (service failure). ● Insulin underdose (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).
10.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 10 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. ● Risks may be categorised 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
11.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 11 Levels of risk
12.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 12 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.
13.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 13 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.
14.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 14 Risk assessment - insulin pump Identified hazard Hazard probability Hazard severity Estimated risk Acceptability 1. Insulin overdose Medium High High Intolerable 2. Insulin underdose Medium Low Low Acceptable 3. Power failure High Low Low Acceptable 4. Machine incorrectly fitted High High High Intolerable 5. Machine breaks in patient Low High Medium ALARP 6. Machine causes infection Medium Medium Medium ALARP 7. Electrical interference Low High Medium ALARP 8. Allergic reaction Low Low Low Acceptable
15.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 15 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.
16.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 16 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 minimise the number of single causes of system failure.
17.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 17 Insulin pump fault tree
18.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 18 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.
19.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 19 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.
20.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 20 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.
21.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 21 Safety requirements - insulin pump SR1: The system shall not deliver a single dose of insulin that is greater than a specified maximum dose for a system user. SR2: The system shall not deliver a daily cumulative dose of insulin that is greater than a specified maximum for a system user. SR3: The system shall include a hardware diagnostic facility that shall be executed at least 4 times per hour. SR4: The system shall include an exception handler for all of the exceptions that are identified in Table 3. SR5: The audible alarm shall be sounded when any hardware or software anomaly is discovered and a diagnostic message as defined in Table 4 should be displayed. SR6: In the event of an alarm in the system, insulin delivery shall be suspended until the user has reset the system and cleared the alarm.
22.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 22 Safety specification ● The safety requirements of a system should be separately specified. ● These requirements should be based on an analysis of the possible hazards and risks as previously discussed. ● Safety requirements usually apply to the system as a whole rather than to individual sub-systems. In systems engineering terms, the safety of a system is an emergent property.
23.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 23 IEC 61508 ● An international standard for safety management that was specifically designed for protection systems - it is not applicable to all safety-critical systems. ● Incorporates a model of the safety life cycle and covers all aspects of safety management from scope definition to system decommissioning.
24.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 24 Control system safety requirements
25.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 25©Ian Sommerville 2000 Dependable systems specification Slide 25 The safety life-cycle
26.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 26 Safety requirements ● Functional safety requirements • These define the safety functions of the protection system i.e. the define how the system should provide protection. ● Safety integrity requirements • These define the reliability and availability of the protection system. They are based on expected usage and are classified using a safety integrity level from 1 to 4.
27.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 27 Security specification ● Has some similarities to safety specification • Not possible to specify security requirements quantitatively; • The requirements are often ‘shall not’ rather than ‘shall’ requirements. ● Differences • No well-defined notion of a security life cycle for security management; No standards; • Generic threats rather than system specific hazards; • Mature security technology (encryption, etc.). However, there are problems in transferring this into general use; • The dominance of a single supplier (Microsoft) means that huge numbers of systems may be affected by security failure.
28.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 28 The security specification process
29.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 29 Stages in security specification ● Asset identification and evaluation • The assets (data and programs) and their required degree of protection are identified. The degree of required protection depends on the asset value so that a password file (say) is more valuable than a set of public web pages. ● Threat analysis and risk assessment • Possible security threats are identified and the risks associated with each of these threats is estimated. ● Threat assignment • Identified threats are related to the assets so that, for each identified asset, there is a list of associated threats.
30.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 30 Stages in security specification ● Technology analysis • Available security technologies and their applicability against the identified threats are assessed. ● Security requirements specification • The security requirements are specified. Where appropriate, these will explicitly identified the security technologies that may be used to protect against different threats to the system.
31.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 31 Types of security requirement ● Identification requirements. ● Authentication requirements. ● Authorisation requirements. ● Immunity requirements. ● Integrity requirements. ● Intrusion detection requirements. ● Non-repudiation requirements. ● Privacy requirements. ● Security auditing requirements. ● System maintenance security requirements.
32.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 32 LIBSYS security requirements SEC1: All system users shall be identified using their library card number and personal password. SEC2: Users privileges shall be assigned according to the class of user (student, staff, library staff). SEC3: Before execution of any command, LIBSYS shall check that the user has sufficient privileges to access and execute that command. SEC4: When a user orders a document, the order request shall be logged. The log data maintained shall include the time of order, the user’s identification and the articles ordered. SEC5: All system data shall be backed up once per day and backups stored off-site in a secure storage area. SEC6: Users shall not be permitted to have more than 1 simultaneous login to LIBSYS.
33.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 33 System reliability specification ● Hardware reliability • What is the probability of a hardware component failing and how long does it take to repair that component? ● Software reliability • How likely is it that a software component will produce an incorrect output. Software failures are different from hardware failures in that software does not wear out. It can continue in operation even after an incorrect result has been produced. ● Operator reliability • How likely is it that the operator of a system will make an error?
34.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 34 Functional reliability requirements ● A predefined range for all values that are input by the operator shall be defined and the system shall check that all operator inputs fall within this predefined range. ● The system shall check all disks for bad blocks when it is initialised. ● The system must use N-version programming to implement the braking control system. ● The system must be implemented in a safe subset of Ada and checked using static analysis.
35.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 35 ● The required level of system reliability required should be expressed quantitatively. ● Reliability is a dynamic system attribute- reliability specifications related to the source code are meaningless. • No more than N faults/1000 lines; • This is only useful for a post-delivery process analysis where you are trying to assess how good your development techniques are. ● An appropriate reliability metric should be chosen to specify the overall system reliability. Non-functional reliability specification
36.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 36 ● 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 programme is required to assess the reliability of critical systems. Reliability metrics
37.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 37 Reliability metrics Metric Explanation POFOD Probability of failure on demand The likelihood that the system will fail when a service request is made. A POFOD of 0.001 means that 1 out of a thousand service requests may result in failure. ROCOF Rate of failure occurrence The frequency of occurrence with which unexpected behaviour is likely to occur. A R OCOF of 2/100 means that 2 f ailures are likely to occur in each 100 operational time units. This metric is sometimes called the failure intensity. MTTF Mean time to failure The average time between observed system failures. An MTTF of 500 means that 1 failure can be expected every 500 time units. AVAIL Availability The probability that the system is available for use at a given time. Availability of 0.998 means that in every 1000 time units, the system is likely to be available for 998 of these.
38.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 38 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 • Emergency shutdown system in a chemical plant.
39.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 39 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 • Credit card processing system, airline booking system.
40.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 40 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 • Computer-aided design systems where a designer will work on a design for several hours, word processor systems.
41.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 41 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 • telephone switching systems, railway signalling systems.
42.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 42 Non-functional requirements spec. ● Reliability measurements do NOT take the consequences of failure into account. ● Transient faults may have no real consequences but other faults may cause data loss or corruption and loss of system service. ● May be necessary to identify different failure classes and use different metrics for each of these. The reliability specification must be structured.
43.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 43 Failure consequences ● When specifying reliability, it is not just the number of system failures that matter but the consequences of these failures. ● Failures that have serious consequences are clearly more damaging than those where repair and recovery is straightforward. ● In some cases, therefore, different reliability specifications for different types of failure may be defined.
44.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 44 Failure classification Failure class Description Transient Occurs only with certain inputs Permanent Occurs with all inputs Recoverable System can recover without operator intervention Unrecoverable Operator intervention needed to recover from failure Non-corrupting Failure does not corrupt system state or data Corrupting Failure corrupts system state or data
45.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 45 ● For each sub-system, analyse the consequences of possible system failures. ● From the system failure analysis, partition failures into appropriate classes. ● For each failure class identified, set out the reliability using an appropriate metric. Different metrics may be used for different reliability requirements. ● Identify functional reliability requirements to reduce the chances of critical failures. Steps to a reliability specification
46.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 46 Bank auto-teller system ● Each machine in a network is used 300 times a day ● Bank has 1000 machines ● Lifetime of software release is 2 years ● Each machine handles about 200, 000 transactions ● About 300, 000 database transactions in total per day
47.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 47 Reliability specification for an ATM Failure class Example Reliability metric Permanent, non-corrupting. The system fails to operate with any card that is input. Software must be restarted to correct failure. ROCOF 1 occurrence/1000 days Transient, non- corrupting The magnetic stripe data cannot be read on an undamaged card that is input. ROCOF 1 in 1000 transactions Transient, corrupting A p attern of transactions across the network causes database corruption. Unquantifiable! Should never happen in the lifetime of the system
48.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 48 Specification validation ● It is impossible to empirically validate very high reliability specifications. ● No database corruptions means POFOD of less than 1 in 200 million. ● If a transaction takes 1 second, then simulating one day’s transactions takes 3.5 days. ● It would take longer than the system’s lifetime to test it for reliability.
49.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 49 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. ● Security requirements should identify assets and define how these should be protected. ● Reliability requirements may be defined quantitatively.
50.
©Ian Sommerville 2004
Software Engineering, 7th edition. Chapter 9 Slide 50 Key points ● Reliability metrics include POFOD, ROCOF, MTTF and availability. ● Non-functional reliability specifications can lead to functional system requirements to reduce failures or deal with their occurrence.
Descargar ahora