By : GURU ABIRAMI.D M.sc IT DEPARTMENT OF CS & IT NADAR SARASWATHI COLLEGE OF ARTS AND SCIENCE ,THENI .
VERIFICATIONS & VALIDATIONS TOPICS  INTRODUCTION  GOALS,PROCESS  WALKTHROUGH AND INSPECTION  SOFTWARE QUALITY ASSURANCE  STATIC ANALYSIS  SYMBOLIC EXECUTION
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.
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
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 .
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 .
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 .
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
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.
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.
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.
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.
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 .
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
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.
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
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.
Thank you…

Software engineering

  • 1.
    By : GURU ABIRAMI.D M.scIT DEPARTMENT OF CS & IT NADAR SARASWATHI COLLEGE OF ARTS AND SCIENCE ,THENI .
  • 2.
    VERIFICATIONS & VALIDATIONS TOPICS INTRODUCTION  GOALS,PROCESS  WALKTHROUGH AND INSPECTION  SOFTWARE QUALITY ASSURANCE  STATIC ANALYSIS  SYMBOLIC EXECUTION
  • 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 VALIDATIONGOALS 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 productsand 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 theend 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 awhole 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- modelof 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 ofa 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 ,likewalkthroughs 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 subsequentexperiment , 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 oEstablishment 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 analysisis 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 :  Thesymbol 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 typicallyproduce 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  Symbolicexecution 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.
  • 19.