Many of the methods and techniques mentioned in the previous sections are product oriented, in the sense that the V&V activities are oriented mainly toward the knowledge base, and to some extent to the inference engine and user interface. The process-oriented approach to V&V is connected with the more sophisticated methodologies and environments for the construction of expert systems. Central to these more principled methodologies has been one of the fundamental premises of SE, which distinguishes clearly the functional specification of a system from its design and implementation. Instead of directly encoding the knowledge gathered from the human expert, the aim is to build an equivalent of the functional specification, i.e., a knowledge level description or a conceptual model. Consequently, the focus of verification and validation has been concentrated on these models and their refinements rather
your e-mail
subscribe
Go!
ITLibrary
EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info
than on the executable representation.
Some methodologies and environments, such as MEKAS, MAKE, and KADS, are described in Vermesan and Bench-Capon (1995) and Wielinga et al. (1992). They are concerned with developing a knowledge level model and transforming it to the symbol level. A major contribution of these approaches is that the V&V techniques are not isolated from the overall expert system development life cycle, but are part of safe and well-defined methodologies, which also provide techniques for moving to an executable representation.
The MAKE (Maintenance Assistance for Knowledge Engineers), for instance, addresses the latter stage in expert system development, which focuses on the actual construction of the KB. Its prime focus was the construction of maintainable systems, in domains based on regulations that are particularly vulnerable to change. It is argued that there is a strong relation between maintenance and V&V: maintenance involves the detection of flaws in the knowledge base, and any changes that are made must themselves be validated and verified. MAKE prescribes a development methodology that produces systems that are more capable of verification, validation, and maintenance. To be effective, these activities should not be considered only when the system has been produced, but must inform the whole development process. Central to this philosophy is that V&V should always be carried out at a higher level than the level of executable code. The primary focus of V&V must be on the models, and the transition between them, rather than simply on the executable representation.
FIGURE 11 The waterfall expert system life-cycle paradigm.
Previous Table of Contents Next
footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.
Brought to you by EarthWeb
IT Library Logo Click
Here!
Click Here!
Search the site:
EXPERT SEARCH ---Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games
EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers
Previous Table of Contents Next
There has been some research effort into and development of a number of techniques to support V&V of expert system, and in identifying the most appropriate phases in the development to which they may be applied. Thus, opportunities to perform verification and validation occur at various stages during the development of the expert system. In the waterfall approach to software development, V&V can be carried out at the end of each phase of development.
The equivalent waterfall model for expert systems (Figure 11) is similar in a way but presents a number of particularities (Coenen and Bench-Capon, 1993). These include:
● System analysis. Is not always clear that the same principles used in conventional software can
be used for them too, since the estimates of costs, time, and benefits for an expert system are very unreliable.
● Requirements analysis and definition. It is difficult to provide clearly the requirements of the
system and in many cases this stage is neglected because many expert system applications have used the prototyping life-cycle paradigm.
● Software specification and design. The notions of data structures and procedures are not
relevant, and the KB is the focal point, with the design concentrating on the choice of representation for the knowledge and an inference engine to manipulate the knowledge.
● Implementation. The implementation is more complicated since the specification and the design
are not so detailed as in the case of conventional software. The expert systems are normally implemented using languages such as PROLOG, LISP, or a shell and are generally application specific, which makes it difficult to apply standards in order to reuse the code or perform major changes to the KB software product.
● Testing. The testing stage is rather vague and in many cases is integrated into the stage of
eliciting and refining knowledge from the expert.
● Maintenance. There are attempts to adapt Swanson's classification system for traditional
software system maintenance.
More or less serious criticisms of the traditional waterfall model have led to alternative models such as
rapid prototyping and spiral modeling, which have been developed to improve or replace the waterfall model. These models have been adopted by developers of expert systems as well. The software life cycle for spiral modeling is somewhat similar to the prototype model. In the analysis stage, the software
development team specifies in the requirements documents of the software project the validation procedures, risk identification, a number of KB requirements, constraints on the computer memory required by the KB, schedule, resources, and an overall test strategy, including a verification and validation test plan.
The attempts to define life-cycle models for expert system construction has led to the possibility of coupling the V&V activities to the specific stages in the development. Thus, V&V techniques are not stand- alone, but part of this methodology. However, important to notice is that the focus of V&V is not the same at each stage since the objectives of each are stage different. An example of such a mapping between different development stages and the focus of V&V in each of them is summarized in Table 3.
Such a mapping gives guidance to what V&V can be done when. Essentially, V&V is spread over four stages: (1) requirement analysis, (2) knowledge acquisition, (3) knowledge specification and refinement
and (4) implementation. TABLE 3
your e-mail
subscribe
Go!
ITLibrary
EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info
Mapping Focus of V&V Methods to the Development Stages
Life cycle Focus of V&V
Requirement analysis and initial knowledge acquisition
The focus is on achieving satisfactory requirements and consistent initial specifications. The use of traditional V&V techniques may not be applicable since an expert system is knowledge intensive rather than data intensive. The initial requirements are primarily related to questions about what kind of problems can be solved under which environments. Inconsistencies detected at this stage are resolved by supplying additional knowledge. The human expert is directly involved in the process of discarding or reflecting modifications in the initial knowledge
specification.
Knowledge specification V&V activities at this level exploit the structure of the conceptual model, focusing on validating the knowledge specification. During such activities, knowledge analysis can reveal potential errors. A failure to prove a desired property is a trigger to complete the knowledge specification. The human expert proposes a set of possible repairs.
Refinement of knowledge specification The relation between knowledge analysis and refinement relies on the fact that the latter follows the former. The analysis of desired properties guides the refinement process. The V&V activities focus on performing correct refinements, thus ensuring consistency between two consecutive levels of specification.
Implementation The focus is checking the implemented system for internal consistency, also demonstrating the compliance with the specification. Automated tools may greatly help in performing V&V activities.