Building the Right System Right Evaluating V & V Methods in Knowledge Engineering

This paper argues that verification and validation (V&V) techniques are an essential part of the knowledge engineering process, because they offer the only way to judge the success (or otherwise) of a KBS development project. However, examination f known studies on the effectiveness of existing KBS V&V techniques hows, rather worryingly, that the state of knowledge in this area is very restricted and sparse. A proposal is made to improve this situation, by systematically gathering data from a representative set of KBS projects and V&V techniques. Without such a study, it is argued that knowledge engineering will remain very much an art. The Art of Knowledge Engineering Knowledge-based systems (KBS) have proven to be effective technology for solving many kinds of problem in business and industry. KBS succeed in solving problems where solutions are derived from the application of a substantial body of knowledge, rather than by the application of an imperative algorithm. In the 1980s, KBS technology was widely applied to solve stand-alone problems. Classic examples of the successful use of the technology were in diagnostic problem-solving (for example, in medicine or engineering), provision of advice (for example, "help-desk" applications), and construction/configuration (for example, product manufacturing and transportation loading). In the 1990s, many organisations have identified their collective knowledge as their most important resource, and are applying KBS technology to capture and exploit these "knowledge assets" in a ’systematic manner (Liebowitz and Wilcox, 1997). The characteristic feature of problem domains where KBS technology is suitable is that the problems are illdefined: they are not amenable to solution by algorithmic means; instead, the knowledge in the knowledge base of the KBS is used in some way to search for a solution. Often, the domain is such that there can be no guarantee that a solution will be found, or that found solutions will be optimal. Many KBS offer a "best effort" solution, which is good enough when the application requirements permit this (that is, the system is not safety or mission-critical). The literature on KBS requirements specification recommends that the requirements be divided into minimum and desired functionality (Rushby, 1990): minimum requirements will often dictate what a system must never do (for example, a vehicle loading application must never produce a configuration that is unbalanced to the point of being dangerous to vehicle operators), while desired requirements will attempt to specify the quality of solutions (for example, that at least 90% of the configurations produced by the vehicle loading application should be within 15% of optimal). In practice, desired requirements will be difficult to specify, due to the ill-defined nature of the problem to be solved (for example, in the vehicle loading application, it may be very difficult to determine what constitutes an "optimal solution" for the desired requirements) (Batarekh, Preece, Bennett and Grogono, 1990). This is unsurprising; from a software engineering point-of-view, given the fact that the problem is ill-defined, it follows that the user requirements will be ill-defined also. Knowledge engineering can be viewed as a special instance of software engineering, where the overall development strategy typically must employ exploratory prototyping: the requirements will typically be ill-defined at the outset, and it will take some ffort in acquiring knowledge, and building prototype models, before the requirements can become more clearly defined. The knowledge ngineer will have the hardest task when the domain knowledge itself is not wellunderstood; for example, when the knowledge is locked up in the heads of human experts who are not able to articulate it clearly. It is not unusual for a knowledge engineer to face a situation in which the users will be unable to say what they really want, experts will be unable to say what they really know, and somehow a KBS must be built! Building KBS is something of an art. 38 From: AAAI Technical Report WS-98-11. Compilation copyright © 1998, AAAI (www.aaai.org). All rights reserved. The Importance of Validation and Verification Validation and verification (V&V) comprise a set techniques used in software engineering (and, therefore, in knowledge ngineering) to evaluate the quality of software systems (including KBS). There is much confusion about the distinction between validation and verification, but the conventional view is that verification is the process of checking whether the software system meets the specified requirements of the users, while validation is the process of checking whether the software system meets the actual requirements of the users. Boehm memorably characterised the difference as follows (Boehm, 1984): Verification is building the system right. Validation is building the right system. Verification can be viewed as a part of validation: it is unlikely that a system that is not "built right" to be the "right system". However, verification is unlikely to be the whole of validation, due to the difficulty of capturing specifying user requirements. As noted above, this is a particularly important distinction in knowledge engineering. Of course, the goal in software/knowledge engineering is to try to ensure that the system is both "built right" and the "right system"; that is, the goal is to build "the right system, right". In software engineering, efforts have been made to formalise the development process so that user requirements may be stated as a fully-formal specification, from which it can be proven that the implemented software system meets the requirements. While formal methods are desirable even essential in some cases (notably safety and mission-critical systems), these methods are unsuitable in large classes of software applications: ̄ Where requirements are amenable to formal specification, it may be too difficult to create the specification within project time and budgetary constraints. ̄ There are many kinds of requirement that are not amenable to formal specification (for example, the "usability" of a graphical user interface). The extent to which formal methods can be applied in knowledge engineering is debatable (Meseguer and Preece, 1995), but it is certainly unrealistic to expect formal verification to serve as the only V&V technique in a KBS development project, because it will rarely be possible to ensure that the formal specification is a complete and correct statement of the users’ requirements. Therefore, KBS V&V will typically need to involve multiple techniques, including formal verification against formal specifications (where possible), and empirical validation (including running test cases and evaluating the system in the operational environment) (Preece, 1990). Given that knowledge ngineering is an inexact art, the most fundamental measures of the success of a KBS project would seem to be: Did we get it right? That is, does it meet the users’ actual requirements. Can we keep it right? That is, is it sufficiently maintainable for anticipated future changes. Can we do it again? That is, is the process repeatable to ensure success with future projects. The final point refers to the capability of the knowledge engineers, and reflects the modem view of software quality being determined primarily by the quality of the development process (Preece, 1995). While verification and validation are only part of the overall development process, they are extremely important because they are the only way to produce an answer to the first of the three questions above ("Did we get it right?"), and provide partial answers to the other two questions (V&V techniques assist in measuring maintainability, and a repeatable V&V capability is a prerequisite for success in knowledge engineering). Consideration of the importance of V&V to successful knowledge engineering raises another question: how effective are the KBS V&V techniques in current use? Obviously, if the techniques are incomplete or unsound, then they cannot be trusted to provide measurement of software quality and project success. The goal of this paper is to reflect upon studies which have been done to assess the effectiveness of current KBS V&V techniques, and to: ̄ summarise what the studies tell us about the current state-of-the-practice in KBS V&V; ̄ identify ways to improve the state of knowledge engineers’ own knowledge about available KBS V&V techniques. Unlike most papers on KBS V&V, the objective here is not to propose new V&V techniques, but to determine what can be done with the existing techniques, and propose further ways of measuring the effectiveness of current (and future) V&V techniques.