Software engineering
- 1. Critical Systems Validation B.Sakthibala II-M.Sc .(CS) Department of CS&IT Nadar Saraswathi College Of Arts & science,Theni.
- 2. • Content., Reliability validation Safety assurance Security assessment Safety and dependability cases
- 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.
- 4. 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
- 5. 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.
- 6. Reliability measurement problems • Operational profile uncertainty – The operational profile may not be an accurate reflection of the real use of the system. • High costs of test data generation – 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.
- 7. • 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
- 8. 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.
- 9. 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.
- 10. 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
- 11. Security validation • Experience-based validation – The system is reviewed and analysed against the types of attack that are known to the validation team. • Tool-based validation – Various security tools such as password checkers are used to analyse the system in operation. • Tiger teams – 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.
- 12. 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.
- 13. 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.
- 14. 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 safety- related 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 safety cases References to other safety cases that may impact on this safety case.