Critical Systems Validation

Critical Systems Validation

Critical Systems Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 1 Objectives To explain how system reliability can be measured and how reliability growth models can be used for reliability prediction To describe safety arguments and how these are used To discuss the problems of safety assurance To introduce safety cases and how these are used in safety validation

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 2 Topics covered Reliability validation Safety assurance Security assessment Safety and dependability cases Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 3 Validation of critical systems

The verification and validation costs for critical systems involves additional validation processes and analysis than for non-critical systems: The costs and consequences of failure are high so it is cheaper to find and remove faults than to pay for system failure; You may have to make a formal case to customers or to a regulator that the system meets its dependability requirements. This dependability case may require specific V & V activities to be carried out. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 4 Validation costs

Because of the additional activities involved, the validation costs for critical systems are usually significantly higher than for noncritical systems. Normally, V & V costs take up more than 50% of the total system development costs. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 5 Reliability validation Reliability validation involves exercising the program to assess whether or not it has reached the required level of reliability. This cannot normally be included as part of a normal

defect testing process because data for defect testing is (usually) atypical of actual usage data. Reliability measurement therefore requires a specially designed data set that replicates the pattern of inputs to be processed by the system. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 6 The reliability measurement process Identify operational profiles Ian Sommerville 2004 Prepare test data set Apply tests to system

Software Engineering, 7th edition. Chapter 24 Compute observed reliability Slide 7 Reliability validation activities Establish the operational profile for the system. Construct test data reflecting the operational profile. Test the system and observe the number of failures and the times of these failures. Compute the reliability after a statistically

significant number of failures have been observed. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 8 Statistical testing Testing software for reliability rather than fault detection. Measuring the number of errors allows the reliability of the software to be predicted. Note that, for statistical reasons, more errors than are allowed for in the reliability specification must be induced. An acceptable level of reliability should be specified and the software tested and amended until that level of reliability is reached.

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 9 Reliability measurement problems Operational profile uncertainty High costs of test data generation The operational profile may not be an accurate reflection of the real use of the system. Costs can be very high if the test data for the system cannot be generated automatically.

Statistical uncertainty You need a statistically significant number of failures to compute the reliability but highly reliable systems will rarely fail. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 10 Operational profiles An operational profile is a set of test data whose frequency matches the actual frequency of these inputs from normal usage of the system. A close match with actual usage is necessary otherwise the measured reliability will not be reflected in the actual usage of the system. It can be generated from real data collected from an

existing system or (more often) depends on assumptions made about the pattern of usage of a system. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 11 An operational profile Number of inputs ... Input classes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 12 Operational profile generation

Should be generated automatically whenever possible. Automatic profile generation is difficult for interactive systems. May be straightforward for normal inputs but it is difficult to predict unlikely inputs and to create test data for them. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 13 Reliability prediction A reliability growth model is a mathematical model of

the system reliability change as it is tested and faults are removed. It is used as a means of reliability prediction by extrapolating from current data Simplifies test planning and customer negotiations. You can predict when testing will be completed and demonstrate to customers whether or not the reliability growth will ever be achieved. Prediction depends on the use of statistical testing to measure the reliability of a system version. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 14 Equal-step reliability growth Reliability

(ROCOF) t1 t2 t3 t4 t5 Time Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 15 Observed reliability growth

The equal-step growth model is simple but it does not normally reflect reality. Reliability does not necessarily increase with change as the change can introduce new faults. The rate of reliability growth tends to slow down with time as frequently occurring faults are discovered and removed from the software. A random-growth model where reliability changes fluctuate may be a more accurate reflection of real changes to reliability. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 16 Random-step reliability growth Note different reliability improvements

Reliability (ROCOF) Fault repair ad ds new fault and decreases reliability (increases ROC OF) t1 t2 t3 t4 t5 Time Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24

Slide 17 Growth model selection Many different reliability growth models have been proposed. There is no universally applicable growth model. Reliability should be measured and observed data should be fitted to several models. The best-fit model can then be used for reliability prediction. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 18

Reliability prediction Reliability = Measur ed reliability Fitted reliability model curv e Required reliability Estimated time ofreliability achievement Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Time Slide 19 Safety assurance

Safety assurance and reliability measurement are quite different: Within the limits of measurement error, you know whether or not a required level of reliability has been achieved; However, quantitative measurement of safety is impossible. Safety assurance is concerned with establishing a confidence level in the system. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 20 Safety confidence

Confidence in the safety of a system can vary from very low to very high. Confidence is developed through: Past experience with the company developing the software; The use of dependable processes and process activities geared to safety; Extensive V & V including both static and dynamic validation techniques. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 21 Safety reviews

Review for correct intended function. Review for maintainable, understandable structure. Review to verify algorithm and data structure design against specification. Review to check code consistency with algorithm and data structure design. Review adequacy of system testing. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 22 Review guidance

Make software as simple as possible. Use simple techniques for software development avoiding error-prone constructs such as pointers and recursion. Use information hiding to localise the effect of any data corruption. Make appropriate use of fault-tolerant techniques but do not be seduced into thinking that fault-tolerant software is necessarily safe. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 23 Safety arguments

Safety arguments are intended to show that the system cannot reach in unsafe state. These are weaker than correctness arguments which must show that the system code conforms to its specification. They are generally based on proof by contradiction Assume that an unsafe state can be reached; Show that this is contradicted by the program code. A graphical model of the safety argument may be developed. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 24

Construction of a safety argument Establish the safe exit conditions for a component or a program. Starting from the END of the code, work backwards until you have identified all paths that lead to the exit of the code. Assume that the exit condition is false. Show that, for each path leading to the exit that the assignments made in that path contradict the assumption of an unsafe exit from the component. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 25 Insulin delivery code

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 26 Safety argument model Overdose administer ed administerInsulin currentDose > maxDose Pre-condition for unsafe sta te or Contradiction currentDose >= mini

mumDose and currentDose <= maxDose Contradiction currentDose = 0 assign if statement 2 not executed Ian Sommerville 2004 Contradiction currentDose = maxDose assign currentDose= 0 currentDose= maxDose if statement 2 then branch executed if statement 2

else branch executed Software Engineering, 7th edition. Chapter 24 Slide 27 Program paths Neither branch of if-statement 2 is executed then branch of if-statement 2 is executed currentDose = 0. else branch of if-statement 2 is executed

Can only happen if CurrentDose is >= minimumDose and <= maxDose. currentDose = maxDose. In all cases, the post conditions contradict the unsafe condition that the dose administered is greater than maxDose. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 28 Process assurance Process assurance involves defining a dependable process and ensuring that this process is followed during the system development.

As discussed in Chapter 20, the use of a safe process is a mechanism for reducing the chances that errors are introduced into a system. Accidents are rare events so testing may not find all problems; Safety requirements are sometimes shall not requirements so cannot be demonstrated through testing. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 29 Safety related process activities

Creation of a hazard logging and monitoring system. Appointment of project safety engineers. Extensive use of safety reviews. Creation of a safety certification system. Detailed configuration management (see Chapter 29). Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 30 Hazard analysis Hazard analysis involves identifying hazards and their root causes. There should be clear traceability from identified hazards through their analysis to

the actions taken during the process to ensure that these hazards have been covered. A hazard log may be used to track hazards throughout the process. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 31 Hazard log entry Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 32 Run-time safety checking

During program execution, safety checks can be incorporated as assertions to check that the program is executing within a safe operating envelope. Assertions can be included as comments (or using an assert statement in some languages). Code can be generated automatically to check these assertions. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 33 Insulin administration with assertions Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 34 Security assessment

Security assessment has something in common with safety assessment. It is intended to demonstrate that the system cannot enter some state (an unsafe or an insecure state) rather than to demonstrate that the system can do something. However, there are differences Safety problems are accidental; security problems are deliberate; Security problems are more generic - many systems suffer from the same problems; Safety problems are mostly related to the application domain Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24

Slide 35 Security validation Experience-based validation Tool-based validation Various security tools such as password checkers are used to analyse the system in operation. Tiger teams The system is reviewed and analysed against the types of attack that are known to the validation team.

A team is established whose goal is to breach the security of the system by simulating attacks on the system. Formal verification The system is verified against a formal security specification. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 36 Security checklist Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 37 Safety and dependability cases

Safety and dependability cases are structured documents that set out detailed arguments and evidence that a required level of safety or dependability has been achieved. They are normally required by regulators before a system can be certified for operational use. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 38 The system safety case It is now normal practice for a formal safety case to

be required for all safety-critical computer-based systems e.g. railway signalling, air traffic control, etc. A safety case is: A documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given environment. Arguments in a safety or dependability case can be based on formal proof, design rationale, safety proofs, etc. Process factors may also be included. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 39 Components of a safety case Component

Description System description An overview of the system and a description of its critical components. Safety requirements The safety requirements abstracted from the system requirements specification. Hazard and risk analysis Documents describing the hazards and risks that have been identified and the measures taken to reduce risk. Design analysis A set of structured arguments that justify why the design is safe. Verification and validation A description of the V & V procedures used and, where appropriate,

the test plans for the system. Results of system V &V. Review reports Records of all design and safety reviews. Team competences Evidence of the competence of all of the team involved in safetyrelated systems development and validation. Process QA Records of the quality assurance processes carried out during system development. Change management processes Records of all changes proposed, actions taken and, where appropriate, justification of the safety of these changes. Associated cases

safety Ian Sommerville 2004 References to other safety cases that may impact on this safety case. Software Engineering, 7th edition. Chapter 24 Slide 40 Argument structure EVIDENCE EVIDENCE << ARGUMENT >> CLAIM EVIDENCE Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24

Slide 41 Insulin pump argument Claim: Evidence: Evidence: Evidence: Argument: The maximum single dose computed by the insulin pump will not exceed maxDose. Safety argument for insulin pump as shown in Figure 24.7 Test data sets for insulin pump Static analysis report for insulin pump software The safety argument presented shows that the maximum dose of insulin that can be computed is equal to maxDose. In 400 tests, the value of Dose was correctly computed and never exceeded maxDose. The static analysis of the control software revealed no anomalies. Overall, it is reasonable to assume that the claim is justified. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24

Slide 42 Claim hierarchy The insulin pump will not deliver a single dose of insulin that is unsafe The maximum single dose computed by the pump software will not exceed maxDose In normal operation, the maximum dose computed will not exceed maxDose Ian Sommerville 2004 maxDose is set up correctly when the pump is configured

maxDose is a safe dose for the user of the insulin pump If the software fails, the maximum dose computed will not exceed maxDose Software Engineering, 7th edition. Chapter 24 Slide 43 Key points Reliability measurement relies on exercising the system using an operational profile - a simulated input set which matches the actual usage of the system.

Reliability growth modelling is concerned with modelling how the reliability of a software system improves as it is tested and faults are removed. Safety arguments or proofs are a way of demonstrating that a hazardous condition can never occur. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 44 Key points It is important to have a dependable process for safety-critical systems development. The process should include hazard identification and monitoring activities. Security validation may involve experiencebased analysis, tool-based analysis or the

use of tiger teams to attack the system. Safety cases collect together the evidence that a system is safe. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 24 Slide 45

Recently Viewed Presentations

  • B.S. Business Administration (120 Units) Accounting Accounting Management

    B.S. Business Administration (120 Units) Accounting Accounting Management

    Business Administration (120 Units) ... Student Clubs. Website Resources. 163 1:1 sessions. Most need resume review help or are looking for internships. Info session topics include learning about a specific career path, working at a company or organization,
  • Chapter 15 Bookkeeping 2013 Delmar, Cengage Learning. All

    Chapter 15 Bookkeeping 2013 Delmar, Cengage Learning. All

    Objectives. Review the learning and performance objectives for this chapter. By the end of this chapter, demonstrate the procedures in the textbook and the job skills in the workbook
  • IntelSim - The Quilt

    IntelSim - The Quilt

    This research was a cross-institutional collaboration. While the research was primarily conducted at GU across several departments, there were other collaborators at U of Rochester, UC Irvine, and numerous affiliated hospitals. Federoff's lab made a supplemental request for 10TB storage...
  • Comparative advantage - Pierre-Louis Vézina

    Comparative advantage - Pierre-Louis Vézina

    Jacob Viner on Ricardo's theory (1937) Taking the theory to the data. Do productivity differences explain why countries trade in the real world? ... The bad-institution country has a comparative advantage in goods with a low contract intensity.
  • Learning How to Tell Time - Education portfolio:Rachel Taney

    Learning How to Tell Time - Education portfolio:Rachel Taney

    The Two ways to use the numbers on the clock. Mrs. Taney- "All clocks are labeled 1-12, when the short hand is pointing at a number, like the red hand in the picture, it states the hour. Student 5- "So...
  • Battle of Thermopylae

    Battle of Thermopylae

    Under Xerxes I, the Persian army moved south through Greece on the eastern coast, accompanied by the Persian navy moving parallel to the shore. To reach its destination at Attica, the region controlled by the city-state of Athens, the Persians...
  • BALTIMORE CITY ZIKA AMBASSADOR PROGRAM ZAP! Stephanie Rawlings-Blake

    BALTIMORE CITY ZIKA AMBASSADOR PROGRAM ZAP! Stephanie Rawlings-Blake

    Mosquito season starts at the beginning of May- be prepared! Prevention is the best method to treat Zika. This includes measures to reduce the breeding grounds for mosquitoes, preventing mosquitoes from entering your home, preventing being bitten by mosquitoes, and...
  • The Crusades

    The Crusades

    Only the First Crusade was successful from a Christian standpoint. In the long history of the Crusades, thousands of knights, soldiers, merchants, and peasants lost their lives on the march or in battle. Don't Write This. The Beginning. The time...