Verification and Validation

Dinesh Pasi Sybscit

Roll no 37

Verification and ValidationThe 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 uponSystem purposeUser expectationsMarketing environment

• deciding how much effort should be spent on the V & V process.

Static & Dynamic Verification and Validation

Formalspecification

High-leveldesign

Requirementsspecification

Detaileddesign

Program

PrototypeDynamicvalidation

Staticverification

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 TESTINGDefect 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

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)Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration 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 analysisControl 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 usedInterface 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.

.S

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 OVERNOW YOU MAY RELAX