Verification and Validation

Verification and Validation
Dinesh Pasi Sybscit Roll no 37
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
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.
Static & Dynamic Verification and Validation

Static verification
Requirements specification
High-level design
Formal specification
Detailed design
Program
Prototype
Dynamic validation
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.
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 its behavior
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.
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.
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 specification System specification System design Detailed design
Acceptance test plan
System integration test plan
Sub-system integration test plan
Module and unit code and tess
Service
Acceptance test
System integration test
Sub-system integration test
Software Test Plan Components

Testing process Requirements traceability Items tested Testing schedule Test recording procedures Testing HW and SW requirements Testing constraints
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.
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)
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
SHOW IS OVER NOW YOU MAY RELAX

Verification and Validation

Uploaded by

Copyright:

Available Formats

Verification and Validation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Verification and Validation

Uploaded by

Copyright:

Available Formats

Verification and Validation

Dinesh Pasi Sybscit Roll no 37

Verification and Validation

Verification and Validation Goals

Static & Dynamic Verification and Validation

Defect Testing and Debugging

Planning verification and validation

Acceptance test plan

System integration test plan

Sub-system integration test plan

Module and unit code and tess

System integration test

Sub-system integration test

Software Test Plan Components

Program Inspection Process

Automated static analysis

Stages of static analysis

Use of static analysis

This software development process is based on:

Cleanroom Process Teams For Large Development

Formal specification and inspections

Cleanroom Process Evaluation

SHOW IS OVER NOW YOU MAY RELAX

You might also like