1 / 21

Verification and Validation

Verification and Validation. Yonsei University 2 nd Semester, 2014 Sanghyun Park. Topics Covered. Planning Verification And Validation Software Inspections Automated Static Analysis. Verification Vs. Validation. Verification “Are we building the product right?”

Download Presentation

Verification and Validation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Verification and Validation Yonsei University 2nd Semester, 2014 Sanghyun Park

  2. Topics Covered • Planning Verification And Validation • Software Inspections • Automated Static Analysis

  3. Verification Vs. Validation • Verification • “Are we building the product right?” • The software should conform to its specification • Validation • “Are we building the right product?” • The software should do what the user really requires

  4. V & V Goals • Verification and validation should establish confidence that the software fitsfor purpose • This does NOT mean completely free of defects • Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed

  5. V & V Confidence • The level of required confidence depends on the system’s purpose, the expectations of the system users and the current marketing environment for the system • Software function • How critical is the software to an organization? • User expectations • Users may have low expectations of certain kinds of software • Marketing environment • Getting a product to market early may be more important than finding defects in the program

  6. Two V & V Techniques • Software inspections • Analyze and check system representations such as the requirement document, design diagrams, and the program source code • Static techniques as they do not require the system to be executed • Software testing • Involves executing an implementation of the software with test data and examining the outputs of the software and its operational behaviour • Dynamic techniques as it works with an executable representation of the system

  7. Static And Dynamic V & V Softwareinspections Requirement specification High-leveldesign Formal specification Detailed design Program Softwaretesting Prototype

  8. Types Of Testing • Defect testing • Tests designed to discover system defects • A successful defect test is one which reveals the presence of defects in a system • Validation testing • Intended to show that the software is what the customer wants – that it meets its requirement • A successful test is one that shows that a requirement has been properly implemented

  9. the debugging process Testing And Debugging • Defect testing and debugging are distinct processes • Defect testing is a process that establishes the existence of defects in a software system • Debugging is a process that locates and corrects these defects

  10. V & V Planning • Careful planning is required to get the most out of inspections and testing, and to control the costs of the V & V process • Planning should start early in the development process • Planning should decide on the balance between static and dynamic approaches

  11. Test Plans As A LinkBetween Development and Testing t

  12. Software Inspections • Involve people examining the source representation with the aim of discovering anomalies and defects • Do not require execution of a system so may be used before implementation • May be applied to any representation of the system (requirements, design, configuration data, etc.) • Very effective way for discovering errors

  13. Inspection Success • Two reasons why inspections are usually more effective than testing for discovering defects: • Many different defects may be discovered in a single inspection. In testing, one defect may mask another so several executions are required • Reviewers reuse domain and programming knowledge so they are likely to have seen the types of error that commonly arise in particular programming languages and in particular types of application

  14. Program Inspections • Intended explicitly for defect DETECTION (not correction) • Defects may be logical errors, anomalies in the code that might indicate an erroneous condition (e.g. an uninitialized variable) or non-compliance with standards

  15. Inspection Pre-conditions • A precise specification of the code to be inspected must be available • The members of the inspection team must be familiar with the organizational standards • An up-to-date, syntactically correct version of the code must be available

  16. The Inspection Process

  17. Inspection Checklists • Checklist of common errors should be used to drive the inspection • Checklist varies according to programming language because of the different levels of checking provided by the language compiler • The ‘weaker’ the type checking, the ‘larger’ the checklist • Examples: Initialization, constant naming, loop termination, array bounds, etc.

  18. Inspection Rate • About 500 source code statements per hour during overview stage • About 125 source code statements per hour during individual preparation • From 90 to 125 statements per hour during the meeting • Inspection is therefore an expensive process

  19. Automated Static Analysis • Static program analyzers are software tools which scan the source text of a program and detect possible faults and anomalies • They parse the program text and then detect whether or not statements are well formed, make inferences about the control flow in the program, and in many cases, compute the set of all possible values for program data • Very effective as an aid to inspections.A supplement to but not a replacement for inspections

  20. Automated Static Analysis Checks

  21. LINT Static Analysis

More Related