1. Verification and Validation
Dinesh Pasi
Sybscit
Roll no 37

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. 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. Static & Dynamic Verification and Validation
Static
verification
Requirements High-level Formal Detailed
specification Program
specification design design
Dynamic
Prototype
validation

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. 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. 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. 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. 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. Software Test Plan Components
• Testing process
• Requirements traceability
• Items tested
• Testing schedule
• Test recording procedures
• Testing HW and SW requirements
• Testing constraints

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

24. SHOW IS OVER
NOW YOU MAY RELAX