3. INTRODUCTION
VERFICATION - 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. VERIFICATION AND VALIDATION GOALS
Establish confidence that software is fit for its
intended purpose
The software may or may not have all defects
removed by the process
The intended use of the product will determine
the degree of confidence in product needed
5. verification
Verifies intermediary products and stages the in matches
the specifies requirement of that particular phase.
Checks whether the products is developed according to the
predetermined requirements and design particulars.
Can be done without execution of the software .
Static methods are used .
Example : Reviews , walkthrough and Inspection .
6. validation
Check whether the end product meet the need of the business .
Answers the question as to whether the software or application is
fit for usage and business requirements .
The Execution of software is necessary for doing validation .
Dynamic methods are used .
Example : Types of Testing like regression , for doing validation .
7. PROCESS
Is a whole life – cycle process – verification & validation
must be applied at each stage in the software process
.
Has two principal objectives
The discovery of defects in a system .
The assessment of whether or not the system is
usable in an operational situation .
8. The verification- model of development
Requirements
specification
System
specification
System
design
Module and
unit code and
test
Detailed
design
Sub – system
Integration
test
System
integration
test
Acceptance
test
service
.
Acceptance
test plan
System integration
test
plan
Sub – system
integration test
plan
9. Walkthroughs and Inspection
Walkthroughs and inspection can be used to systematically
examine work products throughout the ,software lifecycle.
Requirements, design specification, test plans, source code,
principle of operation, users manuals, maintenance procedures
are some of the items that can be examined in this manner.
“Walk through”, the work product ,and re-viewers raise question on
issues of concern.
10. Walkthroughs
Member of a walkthrough team may include the project leader, other members of the
project team, a representative from the quality assurance group, a technical writer, and other
technical personal who have an interest in the project.
1. This approach ensures that all work products are reviewed, Provides a vehicle of
communication among team members, and lessens the threat to individual reviews.
2. Emphasis should be placed on detecting errors. A Walkthrough session should not be used
to correct errors. It should be noted for subsequent resolution by the reviews.
3. Major problems should be addressed. It’s sometimes difficult to distinguish between
major and minor problems, Walkthrough sessions should not degenerate into detailed
discussions of minor problems.
4. It should be limited to 2 hours. A definite time limit ensures that the meeting will not
drag on for several hours.
11. Inspection
Inspection ,like walkthroughs can be used throughout the software lifecycle
to assess and improve the quality of the various work products. Inspection
work consist of one to four members who are trained for their tasks
According to Fagan , an inspection team consists of four persons, who play
the Roles of Moderator , Designer , Implementer, and Tester.
In Fagan’s initial experiment, the inspection team conducted two 2-hours
sessions /day and expended 25 hours / person. Errors found during
development, 67% were found before any unit testing was performed.
The difference in productivity between the project team using inspections
and the control group was negligible.
12. In a subsequent experiment , Fagan found that 82% of all
errors discovered during development of a software product
were found during and code inspection.
The savings in programmer resources on the project was 25% of
estimates cost because most errors were found before unit testing.
Subsequent experiments have reported 70% and grater error
removal during design and code inspections(JON78).
In walkthroughs are an excellent educational medium for new team
member . Balanced use of both inspection and walkthroughs is
recommended.
13. Software quality assurance
o Establishment of network of organizational procedure and standards
leading
to high - quality software .
o SQA often called quality Management _ ensuring that required level
of product quality is achieved .
o To ensure quality in a software product , an organization must
having 3 way
to approach quality management
Organization wide policies .
Project specific policies .
Quality must be controlled .
14. Static analysis
Static analysis is a technique for assessing the structural
characteristics
of source code , or any notational representation that conforms to
well-define syntactic rules .
The present discussion is restricted to static analysis of source
code .
Static analysis can be performed manually using walkthrough or
inspection techniques : however, the term “Static analysis” is most
often used to a program structure by an automated tool ( RAM75.
MIL75,, FOS76, SOF80, GRC83).
A static analyzer will typically construct a symbol table and a graph
15. ANALYSIS :
The symbol table contains information about each variable : It is
Type attributes .
The statement where declared .
Statements where set to a new value, and
Statement where used to provide values .
The nodes in a control-flow graph correspond to basic blocks of source
code, and the arcs represent possible transfers of control between blocks.
A basic block code of source code has the property that if the first
statement in the block is executed .
A control – flow graph and a symbol table that contains , for each variable
in a subprogram , the statement numbers where the variables are declared
, set, used, a static analyzer can determine data flow information.
16. Static analyzer typically produce list of errors, questionable
coding practices.
READY
IF Y < O then
X <- X + Y :
else
X <- Y : STOP
end if :
…………
………..
……………..
………………
start
READY
Y < O
X X + Y X Y
STOP
17. Symbolic Execution
Symbolic execution is a validation technique in which
the input variables of a program unit are symbolic
values rather than literal values.
A program is analyzed by propagating the symbolic
values of the inputs into the operands in expressions .
When that variable is used in subsequent expressions,
the current symbolic values is used . In the manner , all
computations and decisions are symbolic values of the
inputs.