SlideShare uma empresa Scribd logo
1 de 24
Critical Systems Assurance

                                               Lecture 1




Dependability and Security Assurance 1, 2013               Slide 1
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.
Dependability and Security Assurance 1, 2013                                        Slide 2
Validation costs
  •       Because of the additional activities involved, the
          validation costs for critical systems are usually
          significantly higher than for non-critical systems.
  •       Normally, V & V costs take up more than 50% of the
          total system development costs.
  •       The outcome of the validation process is a tangible
          body of evidence that demonstrates the level of
          dependability of a software system.




Dependability and Security Assurance 1, 2013                    Slide 3
Static analysis
  •       Static analysis techniques are system verification
          techniques that don’t involve executing a program.
  •       The work on a source representation of the software
          – either a model or the program code itself.
  •       Inspections and reviews are a form of static analysis
  •       Techniques covered here:
        –       Formal verification
        –       Model checking
        –       Automated program analysis


Dependability and Security Assurance 1, 2013               Slide 4
Verification and formal methods
                                               •   Formal methods can be used
                                                   when a mathematical
                                                   specification of the system is
                                                   produced.
                                               •   The specification is based on
                                                   well-understood mathematical
                                                   theories such as formal logic
                                                   and set theory
                                               •   Used in the development of
                                                   some critical systems


Dependability and Security Assurance 1, 2013                                  Slide 5
Formal methods
                                           •   Formal methods are the ultimate
                                               static verification technique that
                                               may be used at different stages in
                                               the development process:
                                               –   A formal specification may be
                                                   developed and mathematically analyzed
                                                   for consistency. This helps discover
                                                   specification errors and omissions.
                                               –   Formal arguments that a program
                                                   conforms to its mathematical
                                                   specification may be developed. This is
                                                   effective in discovering programming
                                                   and design errors.
Dependability and Security Assurance 1, 2013                                         Slide 6
Arguments for formal methods
  •       Producing a mathematical specification requires a
          detailed analysis of the requirements and this is likely
          to uncover errors.
  •       Concurrent systems can be analysed to discover race
          conditions that might lead to deadlock. Testing for
          such problems is very difficult.
  •       They can detect implementation errors before testing
          when the program is analyzed alongside the
          specification.



Dependability and Security Assurance 1, 2013                 Slide 7
Arguments against formal
                       methods
  •       They require the use of specialised notations that
          cannot be understood by domain experts.
  •       Very expensive to develop a specification and even
          more expensive to show that a program meets that
          specification.
  •       Proofs may contain errors.
  •       It may be possible to reach the same level of
          confidence in a program more cheaply using other V
          & V techniques.


Dependability and Security Assurance 1, 2013               Slide 8
Model checking




   Create an extended finite state model of a system and, using a specialized
            system (a model checker), check that model for errors.

Dependability and Security Assurance 1, 2013                            Slide 9
Model checking
  •       The model checker explores all possible paths
          through the model and checks that a user-specified
          property is valid for each path.
  •       Model checking is particularly valuable for verifying
          concurrent systems, which are hard to test.
  •       Although model checking is computationally very
          expensive, it is now practical to use it in the
          verification of small to medium sized critical systems.




Dependability and Security Assurance 1, 2013                 Slide 10
Model checking process




Dependability and Security Assurance 1, 2013   Slide 11
Automated static analysis
                                               •   Static analysers are software tools
                                                   for source text processing.
                                               •   They parse the program text and
                                                   try to discover potentially
                                                   erroneous conditions and bring
                                                   these to the attention of the V & V
                                                   team.
                                               •   They are very effective as an aid to
                                                   program inspections – but
                                                   inspections can catch errors of
                                                   understanding that tools can’t.
Dependability and Security Assurance 1, 2013                                       Slide 12
Levels of static analysis
  •       Characteristic error checking
        –       The static analyzer can check for patterns in the code that
                are characteristic of errors made by programmers using a
                particular language.

  •       User-defined error checking
        –       Users of a programming language define error patterns, thus
                extending the types of error that can be detected. This allows
                specific rules that apply to a program to be checked.

  •       Assertion checking
        –       Developers include formal assertions in their program and
                relationships that must hold. The static analyzer symbolically
                executes the code and highlights potential problems.
Dependability and Security Assurance 1, 2013                             Slide 13
Automated static analysis
                           checks
Fault class                                      Static analysis check

Data faults                                      Variables used before initialization
                                                 Variables declared but never used
                                                 Variables assigned twice but never used between assignments
                                                 Possible array bound violations
                                                 Undeclared variables

Control faults                                   Unreachable code
                                                 Unconditional branches into loops

Input/output faults                              Variables output twice with no intervening assignment

Interface faults                                 Parameter-type mismatches
                                                 Parameter number mismatches
                                                 Non-usage of the results of functions
                                                 Uncalled functions and procedures

Storage management faults                        Unassigned pointers
                                                 Pointer arithmetic
                                                 Memory leaks


  Dependability and Security Assurance 1, 2013                                                           Slide 14
Use of static analysis
  •       Particularly valuable when a language such as C is
          used which has weak typing and hence many errors
          are undetected by the compiler.
  •       Particularly valuable for security checking – the static
          analyzer can discover areas of vulnerability such as
          buffer overflows or unchecked inputs.
  •       Static analysis is now routinely used in the
          development of many safety and security critical
          systems.



Dependability and Security Assurance 1, 2013                 Slide 15
Reliability testing
  •       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.



Dependability and Security Assurance 1, 2013                Slide 16
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.



Dependability and Security Assurance 1, 2013                   Slide 17
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.




Dependability and Security Assurance 1, 2013                    Slide 18
Reliability measurement




Dependability and Security Assurance 1, 2013   Slide 19
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.


Dependability and Security Assurance 1, 2013                                         Slide 20
An operational profile




Dependability and Security Assurance 1, 2013      Slide 21
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.
          •      Pattern of usage of new systems is unknown.
          •      Operational profiles are not static but change as
                 users learn about a new system and change the
                 way that they use it.
Dependability and Security Assurance 1, 2013                     Slide 22
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.
 •    Recognizing failure
     –          It is not always obvious when a failure has occurred as there
                may be conflicting interpretations of a specification.
Dependability and Security Assurance 1, 2013                             Slide 23
Key points
  •       Static analysis is an approach to V & V that examines
          the source code (or other representation) of a
          system, looking for errors and anomalies. It allows all
          parts of a program to be checked, not just those parts
          that are exercised by system tests.
  •       Model checking is a formal approach to static
          analysis that exhaustively checks all states in a
          system for potential errors.
  •       Statistical testing is used to estimate software
          reliability. It relies on testing the system with a test
          data set that reflects the operational profile of the
          software.
Dependability and Security Assurance 1, 2013                    Slide 24

Mais conteúdo relacionado

Mais procurados

CS5032 L9 security engineering 1 2013
CS5032 L9 security engineering 1 2013CS5032 L9 security engineering 1 2013
CS5032 L9 security engineering 1 2013Ian Sommerville
 
CS 5032 L1 critical socio-technical systems 2013
CS 5032 L1 critical socio-technical systems 2013CS 5032 L1 critical socio-technical systems 2013
CS 5032 L1 critical socio-technical systems 2013Ian Sommerville
 
Security case buffer overflow
Security case buffer overflowSecurity case buffer overflow
Security case buffer overflowIan Sommerville
 
Security Engineering 2 (CS 5032 2012)
Security Engineering 2 (CS 5032 2012)Security Engineering 2 (CS 5032 2012)
Security Engineering 2 (CS 5032 2012)Ian Sommerville
 
Reliability and security specification (CS 5032 2012)
Reliability and security specification (CS 5032 2012)Reliability and security specification (CS 5032 2012)
Reliability and security specification (CS 5032 2012)Ian Sommerville
 
Software security engineering
Software security engineeringSoftware security engineering
Software security engineeringaizazhussain234
 
Safety specification (CS 5032 2012)
Safety specification (CS 5032 2012)Safety specification (CS 5032 2012)
Safety specification (CS 5032 2012)Ian Sommerville
 
Security Engineering 1 (CS 5032 2012)
Security Engineering 1 (CS 5032 2012)Security Engineering 1 (CS 5032 2012)
Security Engineering 1 (CS 5032 2012)Ian Sommerville
 
Ch11-Software Engineering 9
Ch11-Software Engineering 9Ch11-Software Engineering 9
Ch11-Software Engineering 9Ian Sommerville
 
Software Security Engineering
Software Security EngineeringSoftware Security Engineering
Software Security EngineeringMuhammad Asim
 
Critical systems specification
Critical systems specificationCritical systems specification
Critical systems specificationAryan Ajmer
 
Ch12-Software Engineering 9
Ch12-Software Engineering 9Ch12-Software Engineering 9
Ch12-Software Engineering 9Ian Sommerville
 
A Secure Software Engineering Perspective
A Secure Software Engineering PerspectiveA Secure Software Engineering Perspective
A Secure Software Engineering Perspectiveidescitation
 
NIST Framework for Information System
NIST Framework for Information SystemNIST Framework for Information System
NIST Framework for Information Systemnewbie2019
 
Database development and security certification and accreditation plan pitwg
Database development and security certification and accreditation plan  pitwgDatabase development and security certification and accreditation plan  pitwg
Database development and security certification and accreditation plan pitwgJohn M. Kennedy
 

Mais procurados (20)

CS5032 L9 security engineering 1 2013
CS5032 L9 security engineering 1 2013CS5032 L9 security engineering 1 2013
CS5032 L9 security engineering 1 2013
 
CS 5032 L1 critical socio-technical systems 2013
CS 5032 L1 critical socio-technical systems 2013CS 5032 L1 critical socio-technical systems 2013
CS 5032 L1 critical socio-technical systems 2013
 
Security case buffer overflow
Security case buffer overflowSecurity case buffer overflow
Security case buffer overflow
 
Security Engineering 2 (CS 5032 2012)
Security Engineering 2 (CS 5032 2012)Security Engineering 2 (CS 5032 2012)
Security Engineering 2 (CS 5032 2012)
 
Reliability and security specification (CS 5032 2012)
Reliability and security specification (CS 5032 2012)Reliability and security specification (CS 5032 2012)
Reliability and security specification (CS 5032 2012)
 
Software security engineering
Software security engineeringSoftware security engineering
Software security engineering
 
Safety specification (CS 5032 2012)
Safety specification (CS 5032 2012)Safety specification (CS 5032 2012)
Safety specification (CS 5032 2012)
 
Security Engineering 1 (CS 5032 2012)
Security Engineering 1 (CS 5032 2012)Security Engineering 1 (CS 5032 2012)
Security Engineering 1 (CS 5032 2012)
 
Ch13 security engineering
Ch13 security engineeringCh13 security engineering
Ch13 security engineering
 
Ch11-Software Engineering 9
Ch11-Software Engineering 9Ch11-Software Engineering 9
Ch11-Software Engineering 9
 
Software Security Engineering
Software Security EngineeringSoftware Security Engineering
Software Security Engineering
 
Security engineering
Security engineeringSecurity engineering
Security engineering
 
Critical systems specification
Critical systems specificationCritical systems specification
Critical systems specification
 
Ch12-Software Engineering 9
Ch12-Software Engineering 9Ch12-Software Engineering 9
Ch12-Software Engineering 9
 
Ch12 safety engineering
Ch12 safety engineeringCh12 safety engineering
Ch12 safety engineering
 
Ch10 dependable systems
Ch10 dependable systemsCh10 dependable systems
Ch10 dependable systems
 
Barqa Edinburgh Final
Barqa Edinburgh FinalBarqa Edinburgh Final
Barqa Edinburgh Final
 
A Secure Software Engineering Perspective
A Secure Software Engineering PerspectiveA Secure Software Engineering Perspective
A Secure Software Engineering Perspective
 
NIST Framework for Information System
NIST Framework for Information SystemNIST Framework for Information System
NIST Framework for Information System
 
Database development and security certification and accreditation plan pitwg
Database development and security certification and accreditation plan  pitwgDatabase development and security certification and accreditation plan  pitwg
Database development and security certification and accreditation plan pitwg
 

Destaque

Critical national infrastructure
Critical national infrastructureCritical national infrastructure
Critical national infrastructuresommerville-videos
 
Agile and plan based development processes
Agile and plan based development processesAgile and plan based development processes
Agile and plan based development processessommerville-videos
 
CS 5032 L3 socio-technical systems 2013
CS 5032 L3 socio-technical systems 2013CS 5032 L3 socio-technical systems 2013
CS 5032 L3 socio-technical systems 2013Ian Sommerville
 
Requirements engineering challenges
Requirements engineering challengesRequirements engineering challenges
Requirements engineering challengessommerville-videos
 
Introducing sociotechnical systems
Introducing sociotechnical systemsIntroducing sociotechnical systems
Introducing sociotechnical systemssommerville-videos
 

Destaque (9)

Critical national infrastructure
Critical national infrastructureCritical national infrastructure
Critical national infrastructure
 
System success and failure
System success and failureSystem success and failure
System success and failure
 
Critical systems engineering
Critical systems engineeringCritical systems engineering
Critical systems engineering
 
Agile and plan based development processes
Agile and plan based development processesAgile and plan based development processes
Agile and plan based development processes
 
Emergent properties
Emergent propertiesEmergent properties
Emergent properties
 
CS 5032 L3 socio-technical systems 2013
CS 5032 L3 socio-technical systems 2013CS 5032 L3 socio-technical systems 2013
CS 5032 L3 socio-technical systems 2013
 
Requirements engineering challenges
Requirements engineering challengesRequirements engineering challenges
Requirements engineering challenges
 
Introducing sociotechnical systems
Introducing sociotechnical systemsIntroducing sociotechnical systems
Introducing sociotechnical systems
 
System security
System securitySystem security
System security
 

Semelhante a CS5032 L11 validation and reliability testing 2013

Static analysis and reliability testing (CS 5032 2012)
Static analysis and reliability testing (CS 5032 2012)Static analysis and reliability testing (CS 5032 2012)
Static analysis and reliability testing (CS 5032 2012)Ian Sommerville
 
Dependablity Engineering 1 (CS 5032 2012)
Dependablity Engineering 1 (CS 5032 2012)Dependablity Engineering 1 (CS 5032 2012)
Dependablity Engineering 1 (CS 5032 2012)Ian Sommerville
 
verification and validation
verification and validationverification and validation
verification and validationDinesh Pasi
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assuranceAman Adhikari
 
Softwarequalityassurance with Abu ul hassan Sahadvi
Softwarequalityassurance with Abu ul hassan SahadviSoftwarequalityassurance with Abu ul hassan Sahadvi
Softwarequalityassurance with Abu ul hassan SahadviAbuulHassan2
 
Testing throughout the software life cycle - Testing & Implementation
Testing throughout the software life cycle - Testing & ImplementationTesting throughout the software life cycle - Testing & Implementation
Testing throughout the software life cycle - Testing & Implementationyogi syafrialdi
 
Ch15-Software Engineering 9
Ch15-Software Engineering 9Ch15-Software Engineering 9
Ch15-Software Engineering 9Ian Sommerville
 
CHAPTER 15Security Quality Assurance TestingIn this chapter yo
CHAPTER 15Security Quality Assurance TestingIn this chapter yoCHAPTER 15Security Quality Assurance TestingIn this chapter yo
CHAPTER 15Security Quality Assurance TestingIn this chapter yoJinElias52
 
Software testing
Software testingSoftware testing
Software testingfatboysec
 
testing strategies and tactics
 testing strategies and tactics testing strategies and tactics
testing strategies and tacticsPreeti Mishra
 
White Paper: Six-Step Competitive Device Evaluation
White Paper: Six-Step Competitive Device EvaluationWhite Paper: Six-Step Competitive Device Evaluation
White Paper: Six-Step Competitive Device EvaluationIxia
 
Software Quality and Testing_Se lect18 btech
Software Quality and Testing_Se lect18 btechSoftware Quality and Testing_Se lect18 btech
Software Quality and Testing_Se lect18 btechIIITA
 
eFrame® for Insurance Solvency II Stress Testing
eFrame® for Insurance Solvency II Stress TestingeFrame® for Insurance Solvency II Stress Testing
eFrame® for Insurance Solvency II Stress TestingSecondFloor
 
IT8076 – Software Testing Intro
IT8076 – Software Testing IntroIT8076 – Software Testing Intro
IT8076 – Software Testing IntroJohnSamuel280314
 

Semelhante a CS5032 L11 validation and reliability testing 2013 (20)

Static analysis and reliability testing (CS 5032 2012)
Static analysis and reliability testing (CS 5032 2012)Static analysis and reliability testing (CS 5032 2012)
Static analysis and reliability testing (CS 5032 2012)
 
Dependablity Engineering 1 (CS 5032 2012)
Dependablity Engineering 1 (CS 5032 2012)Dependablity Engineering 1 (CS 5032 2012)
Dependablity Engineering 1 (CS 5032 2012)
 
verification and validation
verification and validationverification and validation
verification and validation
 
Software quality assurance
Software quality assuranceSoftware quality assurance
Software quality assurance
 
Softwarequalityassurance with Abu ul hassan Sahadvi
Softwarequalityassurance with Abu ul hassan SahadviSoftwarequalityassurance with Abu ul hassan Sahadvi
Softwarequalityassurance with Abu ul hassan Sahadvi
 
Testing throughout the software life cycle - Testing & Implementation
Testing throughout the software life cycle - Testing & ImplementationTesting throughout the software life cycle - Testing & Implementation
Testing throughout the software life cycle - Testing & Implementation
 
Ch15-Software Engineering 9
Ch15-Software Engineering 9Ch15-Software Engineering 9
Ch15-Software Engineering 9
 
CHAPTER 15Security Quality Assurance TestingIn this chapter yo
CHAPTER 15Security Quality Assurance TestingIn this chapter yoCHAPTER 15Security Quality Assurance TestingIn this chapter yo
CHAPTER 15Security Quality Assurance TestingIn this chapter yo
 
Software testing
Software testingSoftware testing
Software testing
 
Testing Experience Magazine Vol.14 June 2011
Testing Experience Magazine Vol.14 June 2011Testing Experience Magazine Vol.14 June 2011
Testing Experience Magazine Vol.14 June 2011
 
testing strategies and tactics
 testing strategies and tactics testing strategies and tactics
testing strategies and tactics
 
White Paper: Six-Step Competitive Device Evaluation
White Paper: Six-Step Competitive Device EvaluationWhite Paper: Six-Step Competitive Device Evaluation
White Paper: Six-Step Competitive Device Evaluation
 
6. oose testing
6. oose testing6. oose testing
6. oose testing
 
Software Quality and Testing_Se lect18 btech
Software Quality and Testing_Se lect18 btechSoftware Quality and Testing_Se lect18 btech
Software Quality and Testing_Se lect18 btech
 
eFrame® for Insurance Solvency II Stress Testing
eFrame® for Insurance Solvency II Stress TestingeFrame® for Insurance Solvency II Stress Testing
eFrame® for Insurance Solvency II Stress Testing
 
SQA_Class
SQA_ClassSQA_Class
SQA_Class
 
IT8076 – Software Testing Intro
IT8076 – Software Testing IntroIT8076 – Software Testing Intro
IT8076 – Software Testing Intro
 
Ch15
Ch15Ch15
Ch15
 
Software testing
Software testingSoftware testing
Software testing
 
Testing Plan
Testing PlanTesting Plan
Testing Plan
 

Mais de Ian Sommerville

Ultra Large Scale Systems
Ultra Large Scale SystemsUltra Large Scale Systems
Ultra Large Scale SystemsIan Sommerville
 
Dependability requirements for LSCITS
Dependability requirements for LSCITSDependability requirements for LSCITS
Dependability requirements for LSCITSIan Sommerville
 
Conceptual systems design
Conceptual systems designConceptual systems design
Conceptual systems designIan Sommerville
 
Requirements Engineering for LSCITS
Requirements Engineering for LSCITSRequirements Engineering for LSCITS
Requirements Engineering for LSCITSIan Sommerville
 
An introduction to LSCITS
An introduction to LSCITSAn introduction to LSCITS
An introduction to LSCITSIan Sommerville
 
Internet worm-case-study
Internet worm-case-studyInternet worm-case-study
Internet worm-case-studyIan Sommerville
 
Designing software for a million users
Designing software for a million usersDesigning software for a million users
Designing software for a million usersIan Sommerville
 
CS5032 Case study Ariane 5 launcher failure
CS5032 Case study Ariane 5 launcher failureCS5032 Case study Ariane 5 launcher failure
CS5032 Case study Ariane 5 launcher failureIan Sommerville
 
CS5032 Case study Kegworth air disaster
CS5032 Case study Kegworth air disasterCS5032 Case study Kegworth air disaster
CS5032 Case study Kegworth air disasterIan Sommerville
 
CS5032 L19 cybersecurity 1
CS5032 L19 cybersecurity 1CS5032 L19 cybersecurity 1
CS5032 L19 cybersecurity 1Ian Sommerville
 
CS5032 L20 cybersecurity 2
CS5032 L20 cybersecurity 2CS5032 L20 cybersecurity 2
CS5032 L20 cybersecurity 2Ian Sommerville
 
L17 CS5032 critical infrastructure
L17 CS5032 critical infrastructureL17 CS5032 critical infrastructure
L17 CS5032 critical infrastructureIan Sommerville
 
CS5032 Case study Maroochy water breach
CS5032 Case study Maroochy water breachCS5032 Case study Maroochy water breach
CS5032 Case study Maroochy water breachIan Sommerville
 
CS 5032 L18 Critical infrastructure 2: SCADA systems
CS 5032 L18 Critical infrastructure 2: SCADA systemsCS 5032 L18 Critical infrastructure 2: SCADA systems
CS 5032 L18 Critical infrastructure 2: SCADA systemsIan Sommerville
 

Mais de Ian Sommerville (18)

Ultra Large Scale Systems
Ultra Large Scale SystemsUltra Large Scale Systems
Ultra Large Scale Systems
 
Resp modellingintro
Resp modellingintroResp modellingintro
Resp modellingintro
 
Resilience and recovery
Resilience and recoveryResilience and recovery
Resilience and recovery
 
LSCITS-engineering
LSCITS-engineeringLSCITS-engineering
LSCITS-engineering
 
Requirements reality
Requirements realityRequirements reality
Requirements reality
 
Dependability requirements for LSCITS
Dependability requirements for LSCITSDependability requirements for LSCITS
Dependability requirements for LSCITS
 
Conceptual systems design
Conceptual systems designConceptual systems design
Conceptual systems design
 
Requirements Engineering for LSCITS
Requirements Engineering for LSCITSRequirements Engineering for LSCITS
Requirements Engineering for LSCITS
 
An introduction to LSCITS
An introduction to LSCITSAn introduction to LSCITS
An introduction to LSCITS
 
Internet worm-case-study
Internet worm-case-studyInternet worm-case-study
Internet worm-case-study
 
Designing software for a million users
Designing software for a million usersDesigning software for a million users
Designing software for a million users
 
CS5032 Case study Ariane 5 launcher failure
CS5032 Case study Ariane 5 launcher failureCS5032 Case study Ariane 5 launcher failure
CS5032 Case study Ariane 5 launcher failure
 
CS5032 Case study Kegworth air disaster
CS5032 Case study Kegworth air disasterCS5032 Case study Kegworth air disaster
CS5032 Case study Kegworth air disaster
 
CS5032 L19 cybersecurity 1
CS5032 L19 cybersecurity 1CS5032 L19 cybersecurity 1
CS5032 L19 cybersecurity 1
 
CS5032 L20 cybersecurity 2
CS5032 L20 cybersecurity 2CS5032 L20 cybersecurity 2
CS5032 L20 cybersecurity 2
 
L17 CS5032 critical infrastructure
L17 CS5032 critical infrastructureL17 CS5032 critical infrastructure
L17 CS5032 critical infrastructure
 
CS5032 Case study Maroochy water breach
CS5032 Case study Maroochy water breachCS5032 Case study Maroochy water breach
CS5032 Case study Maroochy water breach
 
CS 5032 L18 Critical infrastructure 2: SCADA systems
CS 5032 L18 Critical infrastructure 2: SCADA systemsCS 5032 L18 Critical infrastructure 2: SCADA systems
CS 5032 L18 Critical infrastructure 2: SCADA systems
 

CS5032 L11 validation and reliability testing 2013

  • 1. Critical Systems Assurance Lecture 1 Dependability and Security Assurance 1, 2013 Slide 1
  • 2. 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. Dependability and Security Assurance 1, 2013 Slide 2
  • 3. Validation costs • Because of the additional activities involved, the validation costs for critical systems are usually significantly higher than for non-critical systems. • Normally, V & V costs take up more than 50% of the total system development costs. • The outcome of the validation process is a tangible body of evidence that demonstrates the level of dependability of a software system. Dependability and Security Assurance 1, 2013 Slide 3
  • 4. Static analysis • Static analysis techniques are system verification techniques that don’t involve executing a program. • The work on a source representation of the software – either a model or the program code itself. • Inspections and reviews are a form of static analysis • Techniques covered here: – Formal verification – Model checking – Automated program analysis Dependability and Security Assurance 1, 2013 Slide 4
  • 5. Verification and formal methods • Formal methods can be used when a mathematical specification of the system is produced. • The specification is based on well-understood mathematical theories such as formal logic and set theory • Used in the development of some critical systems Dependability and Security Assurance 1, 2013 Slide 5
  • 6. Formal methods • Formal methods are the ultimate static verification technique that may be used at different stages in the development process: – A formal specification may be developed and mathematically analyzed for consistency. This helps discover specification errors and omissions. – Formal arguments that a program conforms to its mathematical specification may be developed. This is effective in discovering programming and design errors. Dependability and Security Assurance 1, 2013 Slide 6
  • 7. Arguments for formal methods • Producing a mathematical specification requires a detailed analysis of the requirements and this is likely to uncover errors. • Concurrent systems can be analysed to discover race conditions that might lead to deadlock. Testing for such problems is very difficult. • They can detect implementation errors before testing when the program is analyzed alongside the specification. Dependability and Security Assurance 1, 2013 Slide 7
  • 8. Arguments against formal methods • They require the use of specialised notations that cannot be understood by domain experts. • Very expensive to develop a specification and even more expensive to show that a program meets that specification. • Proofs may contain errors. • It may be possible to reach the same level of confidence in a program more cheaply using other V & V techniques. Dependability and Security Assurance 1, 2013 Slide 8
  • 9. Model checking Create an extended finite state model of a system and, using a specialized system (a model checker), check that model for errors. Dependability and Security Assurance 1, 2013 Slide 9
  • 10. Model checking • The model checker explores all possible paths through the model and checks that a user-specified property is valid for each path. • Model checking is particularly valuable for verifying concurrent systems, which are hard to test. • Although model checking is computationally very expensive, it is now practical to use it in the verification of small to medium sized critical systems. Dependability and Security Assurance 1, 2013 Slide 10
  • 11. Model checking process Dependability and Security Assurance 1, 2013 Slide 11
  • 12. Automated static analysis • Static analysers are software tools for source text processing. • They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team. • They are very effective as an aid to program inspections – but inspections can catch errors of understanding that tools can’t. Dependability and Security Assurance 1, 2013 Slide 12
  • 13. Levels of static analysis • Characteristic error checking – The static analyzer can check for patterns in the code that are characteristic of errors made by programmers using a particular language. • User-defined error checking – Users of a programming language define error patterns, thus extending the types of error that can be detected. This allows specific rules that apply to a program to be checked. • Assertion checking – Developers include formal assertions in their program and relationships that must hold. The static analyzer symbolically executes the code and highlights potential problems. Dependability and Security Assurance 1, 2013 Slide 13
  • 14. Automated static analysis checks Fault class Static analysis check Data faults Variables used before initialization Variables declared but never used Variables assigned twice but never used between assignments Possible array bound violations Undeclared variables Control faults Unreachable code Unconditional branches into loops Input/output faults Variables output twice with no intervening assignment Interface faults Parameter-type mismatches Parameter number mismatches Non-usage of the results of functions Uncalled functions and procedures Storage management faults Unassigned pointers Pointer arithmetic Memory leaks Dependability and Security Assurance 1, 2013 Slide 14
  • 15. Use of static analysis • Particularly valuable when a language such as C is used which has weak typing and hence many errors are undetected by the compiler. • Particularly valuable for security checking – the static analyzer can discover areas of vulnerability such as buffer overflows or unchecked inputs. • Static analysis is now routinely used in the development of many safety and security critical systems. Dependability and Security Assurance 1, 2013 Slide 15
  • 16. Reliability testing • 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. Dependability and Security Assurance 1, 2013 Slide 16
  • 17. 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. Dependability and Security Assurance 1, 2013 Slide 17
  • 18. 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. Dependability and Security Assurance 1, 2013 Slide 18
  • 19. Reliability measurement Dependability and Security Assurance 1, 2013 Slide 19
  • 20. 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. Dependability and Security Assurance 1, 2013 Slide 20
  • 21. An operational profile Dependability and Security Assurance 1, 2013 Slide 21
  • 22. 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. • Pattern of usage of new systems is unknown. • Operational profiles are not static but change as users learn about a new system and change the way that they use it. Dependability and Security Assurance 1, 2013 Slide 22
  • 23. 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. • Recognizing failure – It is not always obvious when a failure has occurred as there may be conflicting interpretations of a specification. Dependability and Security Assurance 1, 2013 Slide 23
  • 24. Key points • Static analysis is an approach to V & V that examines the source code (or other representation) of a system, looking for errors and anomalies. It allows all parts of a program to be checked, not just those parts that are exercised by system tests. • Model checking is a formal approach to static analysis that exhaustively checks all states in a system for potential errors. • Statistical testing is used to estimate software reliability. It relies on testing the system with a test data set that reflects the operational profile of the software. Dependability and Security Assurance 1, 2013 Slide 24