Verification and Validation

Slides:



Advertisements
Similar presentations
Quality Assurance Of An Expert System.
Advertisements

Test process essentials Riitta Viitamäki,
©G. Millbery 2003Data, Information, Knowledge and Processing Slide 1 Validation  Making sure that the data value entered is sensible and reasonable 
Rulebase Expert System and Uncertainty. Rule-based ES Rules as a knowledge representation technique Type of rules :- relation, recommendation, directive,
2.2 Validation & Verification
CS62S: Expert Systems Knowledge acquisition and system implementation Based on Chap. 12: The Engineering of Knowledge-based Systems: Theory and Practice,
Inferences The Reasoning Power of Expert Systems.
Database Integrity, Security and Recovery Database integrity Database integrity Database security Database security Database recovery Database recovery.
1 Chapter 9 Rules and Expert Systems. 2 Chapter 9 Contents (1) l Rules for Knowledge Representation l Rule Based Production Systems l Forward Chaining.
EXPERT SYSTEMS Part I.
SYSTEM TESTING AND DEPLOYMENT
OHT 3.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The need for comprehensive software quality requirements Classification.
1 Software Requirements Specification Lecture 14.
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
Knowledge Acquisition. Concepts of Knowledge Engineering Knowledge engineering The engineering discipline in which knowledge is integrated into computer.
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Defining Digital Forensic Examination & Analysis Tools Brian Carrier.
I-9, Immigration, E-Verify Compliance Matters. Immigration Compliance Policy  The purpose of this policy is to comply with the U.S. Immigration Law by.
Verification and Validation Overview References: Shach, Object Oriented and Classical Software Engineering Pressman, Software Engineering: a Practitioner’s.
Testing Theory cont. Introduction Categories of Metrics Review of several OO metrics Format of Presentation CEN 5076 Class 6 – 10/10.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
The First in GPON Verification Classic Mistakes Verification Leadership Seminar Racheli Ganot FlexLight Networks.
 Architecture and Description Of Module Architecture and Description Of Module  KNOWLEDGE BASE KNOWLEDGE BASE  PRODUCTION RULES PRODUCTION RULES 
Verification and Validation in the Context of Domain-Specific Modelling Janne Merilinna.
BE-SECBS FISA 2003 November 13th 2003 page 1 DSR/SAMS/BASP IRSN BE SECBS – IRSN assessment Context application of IRSN methodology to the reference case.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
ES Design, Development and Operation Dr. Ahmed Elfaig Knowledge model, knowledge structure, presentation and organization are the bottleneck of expert.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
SYSTEM TESTING AND DEPLOYMENT CHAPTER 8. Chapter 8: System Testing and Deployment 2 KNOWLEDGE CAPTURE (Creation) KNOWLEDGE TRANSFER KNOWLEDGE SHARING.
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
CS62S: Expert Systems Requirements Specification and Design Based on Chap. 12: The Engineering of Knowledge-based Systems: Theory and Practice, A. J. Gonzalez.
Object-Oriented Software Engineering using Java, Patterns &UML. Presented by: E.S. Mbokane Department of System Development Faculty of ICT Tshwane University.
Chap. 5 Building Valid, Credible, and Appropriately Detailed Simulation Models.
Loop Analysis and Repair Nafi Diallo Computer Science NJIT Advisor: Dr. Ali Mili.
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
ES component and structure Dr. Ahmed Elfaig The production system or rule-based system has three main component and subcomponents shown in Figure 1. 1.Knowledge.
CS62S: Expert Systems Based on: The Engineering of Knowledge-based Systems: Theory and Practice, A. J. Gonzalez and D. D. Dankel.
1 Quality Attributes of Requirements Documents Lecture # 25.
Requirements Validation
Software Engineering Saeed Akhtar The University of Lahore.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
 Software Testing Software Testing  Characteristics of Testable Software Characteristics of Testable Software  A Testing Life Cycle A Testing Life.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Learning Procedural Knowledge through Observation -Michael van Lent, John E. Laird – 인터넷 기술 전공 022ITI02 성유진.
Oversight “The NPPO of the exporting country has the responsibility for ensuring that systems for exports meet the requirements …”
Lecture 20. Recap The main components of an ES are –Knowledge Base (LTM) –Working Memory (STM) –Inference Engine (Reasoning)
Knowledge Representation. A knowledge base can be organised in several different configurations to facilitate fast inferencing Knowledge Representation.
Software Testing.
Advanced AI Session 2 Rule Based Expert System
Requirements Engineering (continued)
Verification and Testing
IEEE Std 1074: Standard for Software Lifecycle
Verification and Validation Overview
Verification and Validation
Entry-Task-Validation-Exit (ETVX)
CS62S: Expert Systems Based on:
Introduction to Problem Solving
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Function Rules and Tables.
Business and IT Architecture for ESS validation
SYSTEM TESTING AND DEPLOYMENT
Requirements Validation – I
Validation and Verification
Computer Science 340 Software Design & Testing
Unit IV – Chapter 2 V-Test Model.
Presentation transcript:

Verification and Validation To ensure quality in expert system verificaion and validation are important steps in the development lifecycle. Based on Chap. 16: The Engineering of Knowledge-based Systems: Theory and Practice, A. J. Gonzalez and D. D. Dankel

Not Complying with the system specs. Semantic and syntactic errors Errors may stem from: Not Complying with the system specs. Semantic and syntactic errors Incorrect representation of the knowledge domain

Verification and validation in expert systems is different from that of conventional expert system ES are not purely objective Uncertainty is accepted and may even be encouraged ES output cannot be easily verified through experiments Expert (or group of experts) decide on the accuracy of the system

Verification The adherence to the system specification and correct implementation process.

Compliance with specs Knowledge representation Reasoning technique Modularity Interfaces Explanation facility Performance Maintainability Security

Redundant rules If a is true and b is true then the temp is -40 0 C Identical rules or rules that have the same meaning: If a is true and b is true then the temp is -40 0 C then the temp is -40 0 F

Conflicting rules If a is true and b is true then x then ~x Identical premises with conflicting conclusions: If a is true and b is true then x then ~x

Subsumed rules If a is true and b is true then x All the premises of one rule is a subset of another rule, and both have identical conclusion: If a is true and b is true then x If a is true and b is true and c is true

Circular rules If a is true and b is true then x and y Conclusion of rule1 leads to rule2 firing, whose conclusion leads to rul1 firing: If a is true and b is true then x and y If x is true and y is true then a and b

Unnecessary IF conditions Two rules have identical conclusion, but one of the premises is conflicting: If a is true and b is true and ~c is true then x If a is true and b is true and c is true

Dead-end rules A rule whose action is not one of the conclusions of the system or whose conclusion is not used in the premise of any other rule.

Missing rules Dead end rules could be caused by the removal of rules or the failure of the knowledge engineer to include a rule.

Unreachable rules The premise of the rule will never ever be true.

Validation Checks to see if the system is correct, i.e. the output is consistent with input.

Validation issues What is being validated? Method Criteria When should validation occur?