Scribd
Upload
48 views

Software Verification & Validation

This document discusses software verification and validation (V&V). It defines validation as ensuring the right system is being built by accounting for stakeholder needs, and verification as ensuring the system is built right by checking that requirements, design, and implementation are consistent. Several V&V techniques are described, including prototyping to get early customer feedback, inspection of specifications by domain experts, and formal modeling and analysis. The document stresses that validation requires communication with stakeholders, while verification checks engineering soundness through consistency checking, traceability between artifacts, and using independent V&V for safety-critical systems.

Uploaded by

Zaryaab Ahmed
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
48 views

Software Verification & Validation

This document discusses software verification and validation (V&V). It defines validation as ensuring the right system is being built by accounting for stakeholder needs, and verification as ensuring the system is built right by checking that requirements, design, and implementation are consistent. Several V&V techniques are described, including prototyping to get early customer feedback, inspection of specifications by domain experts, and formal modeling and analysis. The document stresses that validation requires communication with stakeholders, while verification checks engineering soundness through consistency checking, traceability between artifacts, and using independent V&V for safety-critical systems.

Uploaded by

Zaryaab Ahmed
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

SOFTWARE

VERIFICATION &
VALIDATION
Professor M Zaryaab Ahmed
Email: [email protected]
Contents
◦ Refresher:
◦ Definitions for V&V
◦ Validation Techniques
◦ Verification Techniques
◦ Making Specifications Traceable (see lecture 20)
◦ Testing (not covered in this course)
◦ Code Inspection (not covered in this course)
◦ Code analysis (not covered in this course)
◦ Independent V&V
◦ Contents
◦ Prototyping
◦ Model Analysis (e.g., Model Checking)
◦ Inspection
◦ Managerial Independence:
◦ Financial Independence:
◦ Technical Independence:
Verification and Validation
◦ Validation:
◦ “Are we building the right system?”
◦ Does our problem statement accurately capture the real problem?
◦ Did we account for the needs of all the stakeholders?
◦ Verification:
◦ “Are we building the system, right?”
◦ Does our design meet the spec?
◦ Does our implementation meet the spec?
◦ Does the delivered system do what we said it would do?
◦ Are our requirements models consistent with one another?
V&V Example
◦ Example:
◦ Requirement R:
◦ “Reverse thrust shall only be enabled when the aircraft is moving on the runway”
◦ Domain Properties D:
◦ Wheel pulses on if and only if wheels turning
◦ Wheels turning if and only if moving on runway
◦ Specification S:
◦ Reverse thrust enabled if and only if wheel pulses on
◦ Verification
◦ Does the flight software, P, running on the aircraft flight computer, C, correctly implement S?
◦ Does S, in the context of assumptions D, satisfy R?
◦ Validation
◦ Are our assumptions, D, about the domain correct? Did we miss any?
◦ Are the requirements, R, what is really needed? Did we miss any?
Inquiry Cycle
Shortcuts in the inquiry cycle
Prototyping
◦ “A software prototype is a partial implementation constructed primarily to enable customers, users, or developers to learn more about a
problem or its solution.” [Davis 1990]
◦ “Prototyping is the process of building a working model of the system” [Agresti 1986]
◦ Approaches to prototyping
◦ Presentation Prototypes
◦ used for proof of concept; explaining design features; etc.
◦ explain, demonstrate and inform – then throw away
◦ Exploratory Prototypes
◦ used to determine problems, elicit needs, clarify goals, compare design options
◦ informal, unstructured and thrown away.
◦ Breadboards or Experimental Prototypes
◦ explore technical feasibility; test suitability of a technology
◦ Typically, no user/customer involvement
◦ Evolutionary (e.g., “operational prototypes”, “pilot systems”):
◦ development seen as continuous process of adapting the system
◦ “prototype” is an early deliverable, to be continually improved.
Throwaway or Evolve?
Model Analysis (e.g., model checking)
◦ Verification
◦ “Is the model well-formed?”
◦ Are the parts of the model consistent with one another?
◦ Validation:
◦ Animation of the model on small examples
◦ Formal challenges:
◦ “if the model is correct then the following property should hold...”
◦ ‘What if’ questions:
◦ reasoning about the consequences of particular requirements;
◦ reasoning about the effect of possible changes
◦ “will the system ever do the following...”
◦ State exploration
◦ E.g., use model checking to find traces that satisfy some property
Basic Cross-Checks for UML
Reviews, Walkthroughs, Inspections…
Benefits of formal inspection
Roles
Structuring the inspection
◦ Checklist
◦ uses a checklist of questions/issues
◦ review structured by issue on the list
◦ Walkthrough
◦ one person presents the product step-by-step
◦ review is structured by the product
◦ Round Robin
◦ each reviewer in turn gets to raise an issue
◦ review is structured by the review team
◦ Speed Review
◦ each reviewer gets 3 minutes to review a chunk, then passes to the next person
◦ good for assessing comprehensibility!
Why use inspection?
Independent V&V
Summary
◦ Validation checks you are solving the right problem
◦ Prototyping - gets customer feedback early
◦ Inspection - domain experts read the spec carefully
◦ Formal Analysis - mathematical analysis of your models
◦ plus, meetings & regular communication with stakeholders
◦ Verification checks your engineering steps are sound
◦ Consistency checking - do the models agree with one another?
◦ Traceability - do the design/code/test cases reflect the requirements?
◦ Use appropriate V&V:
◦ Early customer feedback if your models are just sketches
◦ Analysis and consistency checking if your models are specifications
◦ Independence important if your system is safety-critical
Thank You!

You might also like