verification and validation


Published on

Published in: Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

verification and validation

  1. 1. Verification and Validation Dinesh Pasi Sybscit Roll no 37
  2. 2. Verification and ValidationThe program being developed must be checked to ensure that it meets its specification and delivers the functionality expected by the people paying for the software.Verification• Are you building the product right?• Software must conform to its specificationValidation• Are you building the right product?• Software should do what the user really requires
  3. 3. Verification and Validation Goals• Establish confidence that the software system is ‘fit for its intended purpose’.• Level of required confidence depends uponSystem purposeUser expectationsMarketing environment• deciding how much effort should be spent on the V & V process.
  4. 4. Static & Dynamic Verification and Validation Static verificationRequirements High-level Formal Detailed specification Programspecification design design Dynamic Prototype validation
  5. 5. Software Inspection(Static)-• analyse and check the requirements document, design diagrams and the program source code.• You can use inspections at all stages of the process.Software Testing(Dynamic)-• involves running an implementation of the software with test data.• You examine the outputs of the software and its operational behavior to check that it is performing as required.
  6. 6. TYPES OF TESTINGDefect Testing- Designed to discover system defects. The goal of defect testing is to find inconsistencies between a program and its specification.Validation testing – To show that the software is what the customer wants— that it meets its requirements. Statistical testing(part of validation testing) The specification for each increment is analyzed to define a set of inputs that cause the software to change it’s behavior
  7. 7. Defect Testing and DebuggingDefect testing and debugging are distinct process.Defect Testing Verification and validation is concerned with establishing the existence of defects in a program.Debugging is concerned with locating and repairing these errors.
  8. 8. DEBUGGING PROCESS• Skilled debuggers use their knowledge for type of defect, the output pattern, the programming language & process to locate the defect.• After a defect in the program has been discovered, you have to correct it and revalidate the system.• Regression testing is used to check that the changes made to a program have not introduced new faults.• Test case- set of condition is given under which program tested.
  9. 9. Planning verification and validation Verification and Validation is an expensive process Careful planning is needed to get the most out of inspections and testing and to control the costs of the verification and validation process. The software development process model (V model) Requir ements System System Detailed specification specification design design System Sub-system Module and Acceptance integration integration unit code test plan test plan test plan and tess Acceptance System Sub-system Service test integration test integration test
  10. 10. Software Test Plan Components• Testing process• Requirements traceability• Items tested• Testing schedule• Test recording procedures• Testing HW and SW requirements• Testing constraints
  11. 11. Software Inspections• Software inspection is a static V & V process in which a software system is reviewed to find errors and anomalies.• Inspections not require execution of a system so may be used before implementation.• They may be applied to any representation of the system (requirements, design, configuration data, test data, etc.).• They have been shown to be an effective technique for discovering program errors.
  12. 12. Program Inspection Process• Program inspections are reviews whose objective is program defect detection• The program inspection is a formal process that is carried out by a team of at least four people.• 4 team members – product author(fixing defect) – inspector (looks for errors, omissions, and inconsistencies) – reader (reads the code at an inspection meeting.) – moderator (Manages the process and facilitates the inspection)
  13. 13. Inspection process• System overview presented to inspection team• Code and associated documents are distributed to team in advance• Errors discovered during the inspection are recorded• Product modifications are made to repair defects• Re-inspection may or may not be required
  14. 14. Automated static analysis• Static analyzers are software tools that scan the source text of a program and detect possible faults and anomalies.• They parse the program text and try to discover potentially erroneous conditions and bring these to the attention of the V & V team.
  15. 15. Stages of static analysisControl flow analysis Checks for loops with multiple exit or entry points, finds unreachable code, etc.Data use analysis Detects uninitialized variables, variables written twice variables which are declared but never usedInterface analysis• Checks the consistency of routine and procedure declarations and their use.
  16. 16. Stages of static analysisInformation flow analysis.• Identifies the dependencies of output variables. Does not detect anomalies itself but highlights information for code inspection or review.Path analysis• Identifies paths through the program and sets out the statements executed in that path.
  17. 17. Use of static analysis C does not have strict type rules, and the detect less errors during compilation the static analysis tool can automatically discover some of the resulting program faults. Less cost-effective for languages like Java that have strong type checking and can therefore detect many errors during compilation.
  18. 18. Verification and formal methods• Formal methods can be used when a mathematical specification of the system is produced.• They are the ultimate static verification technique.• They involve detailed mathematical analysis of the specification and may develop formal arguments that a program conforms to its mathematical specification.
  19. 19. software development Cleanroom software development is a software development philosophy that uses formal methods to support rigorous software inspection.• The objective of this approach to software development is zero-defect software.• The name ‘Cleanroom’ was derived by analogy with semiconductor fabrication units where defects are avoided by manufacturing in an ultra-clean atmosphere.
  20. 20. This software development process is based on: Formal specification• A state transition model used to express the specification. Incremental development developed and validated separately using the Cleanroom process. Structured programming Only a limited number of control and data abstraction constructs are used. Static verification The developed software is statically verified using rigorous software inspections. Statistical testing To determine program reliability.
  21. 21. Cleanroom Process Teams For Large Development Specification team. Responsible for developing and maintaining the system specification. Development team Responsible for developing and verifying the software. The software is NOT executed or even compiled during this process. Certification team. Responsible for developing a set of statistical tests to exercise the software after development. Reliability growth models used to determine when reliability is acceptable
  22. 22. Formal specification and inspections• The state based model is a system specification and the inspection process checks the program against this model• The vast majority of defects are discovered before execution and are not introduced into the developed software• Mathematical arguments (not proofs) are used to increase confidence in the inspection process.
  23. 23. Cleanroom Process Evaluation Use of the Cleanroom approach has generally led to software with very few errors. Independent assessment shows that the process is no more expensive than other approaches. The programs produced were of higher quality than those developed using traditional techniques.