The expert system development life cycle Distinctive features

The expert system development life cycle

Distinctive features of expert systems - 1

Distinctive features of expert systems - 1 To repeat points made in earlier lectures: · Expert systems require special approaches to systems analysis, especially to the collection of the data (or rather knowledge) on which the system is based.

Distinctive features of expert systems - 1 · · The process of gathering the knowledge to stock the expert system's knowledge base - knowledge acquisition - has proved to be the most difficult component of the knowledge engineering process. It's become known as the 'knowledge acquisition bottleneck', and expert system projects are more likely to fail at this stage than any other.

Distinctive features of expert systems - 1 · Knowledge acquisition almost always involves extracting knowledge from someone who is expert in the field concerned - a domain expert. This process - knowledge elicitation involves a variety of interview and noninterview techniques.

Distinctive features of expert systems - 2

Distinctive features of expert systems - 2 l Expert systems require particular attention to the human-computer interface. User interfaces for expert systems are more troublesome, and harder to develop, than those of conventional pieces of software. · This is because, for various reasons, the interactions between computer and user are more complex than those involved in a conventional piece of software. ·

Distinctive features of expert systems - 2 · For instance: Conventional software typically performs some task, perhaps in interaction with the user. Expert systems typically assist with decision-making about how a task is to be tackled, and this means that the information that must be exchanged between the system and the user is more complex. · Different users differ in the sorts of problemsolving style they prefer. ·

Distinctive features of expert systems - 3

Distinctive features of expert systems - 3 l Expert systems projects require special approaches to software management. The methodologies used to build expert systems have been shaped by the problems with knowledge acquisition, described earlier. · For a long time, the favourite development methodology was rapid prototyping. (Cyclical development means more or less the same thing). ·

Distinctive features of expert systems - 3 · In the mid-1980 s, this approach came under criticism, because it appeared to have all the shortcomings of the unstructured approaches which had been used, with very poor results, in the early days of mainstream software.

Distinctive features of expert systems - 3 · But the Structured Systems Analysis & Design methodologies did not seem to be appropriate, because of the differences between knowledge and data.

Distinctive features of expert systems - 3 · As a result, special-purpose development methodologies for knowledge engineering were developed. The most well known is KADS, which was developed at the University of Amsterdam, as part of the ESPRIT programme, in co-operation with several European partners.

Distinctive features of expert systems - 3 · Nevertheless, many practitioners have not heard of KADS, or have rejected it, and continue to use rapid prototyping.

Distinctive features of expert systems · Both KADS and a more conventional approach are described below.

Cyclical development

Cyclical development · In the 1980 s (and before), the favourite approach, was based on rapid prototyping (also known as cyclical development or evolutionary prototyping).

Cyclical development · The essential principles: get a prototype - a small, preliminary version of the final system - up & running at an early stage; · present this to the domain expert, for criticism; · proceed to refine this prototype with repeated debugging & knowledge accretion stages; · continue with this cycle until the knowledgebase is finished. ·

Cyclical development Knowledge acquisition Prototype critiquing Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Preliminary exploration of field - initial k. e. interviews Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Build a small system containing a few of the features Prototype development

Cyclical development Present the prototype to the domain expert for him/her to criticise and improve Prototype critiquing Knowledge acquisition Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Correct & expand the knowledge on the basis of the D. E. ’s comments Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Add more features, and debug existing features Prototype development

Cyclical development Present the revised prototype to the domain expert for him/her to criticise and improve Prototype critiquing Knowledge acquisition Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Correct & expand the knowledge on the basis of the D. E. ’s comments Prototype development

Cyclical development Knowledge acquisition Prototype critiquing Add more features, and debug exisiting features Prototype development

Cyclical development Present the revised prototype to the domain expert for him/her to criticise and improve Prototype critiquing Knowledge acquisition Prototype development

Cyclical development · This has the advantage that the KE is able to show early progress in the Knowledge elicitation task.

Cyclical development · It also generates enthusiasm in the domain expert.

Turban’s account of the expert system development lifecycle

The expert system development lifecycle l The expert system development lifecycle, as described by Turban l Turban (1993) identifies the following phases and sub-phases in the development of an expert system. This is probably a good account of the way knowledge engineering projects are currently organised in America.

The expert system development lifecycle l Phase 1: Project initialisation Problem definition n Needs assessment n Evaluation of alternative solutions n Verification that an ES approach is appropriate n Consideration of management issues n

The expert system development lifecycle l Comment on Phase 1: n it's important to discover what problem/problems the client expects the system to solve for them, and what their real needs are. The problem may very well be that more knowledge is needed in the organisation, but there may be other, better ways to provide it. n 'Management issues' include availability of finance, legal constraints, and finding a 'champion' in top management.

The expert system development lifecycle l Phase 2: System analysis & design n n n Produce conceptual design Decide development strategy Decide sources of knowledge, and ensure co-operation Select computer resources Perform a feasibility study Perform a cost-benefit analysis

The expert system development lifecycle l Comment on Phase 2: the 'conceptual design' will describe the general capabilities of the intended system, and the required resources. n The problems of selecting software, and finding a domain expert (and persuading him/her to co-operate) have been discussed in the last two lectures. n

The expert system development lifecycle l Phase 3: Prototyping n n Build a small prototype Test, improve and expand it Demonstrate and analyse feasibility Complete the design

The expert system development lifecycle l Comments on Phase 3: Comments: See below on the question of what exactly this prototype is used for. n It's important to establish the feasibility (economic, technical and operational) of the system before too much work has been done, and it's easier to do this if a prototype has been built. n

The expert system development lifecycle l Phase 4: System development Build the knowledge base n Test, evaluate and improve the knowledge base n Plan for integration n

The expert system development lifecycle l Comments on Phase 4: See below on the question of how the knowledge base, as constructed, relates to the prototype. n The evaluation of an expert system (in terms of validation and verification) is a particularly difficult problem. n

The expert system development lifecycle l Phase 5: Implementation Ensure acceptance by users n Install, demonstrate and deploy the system n Arrange orientation and training for the users n Ensure security n Provide documentation n Arrange for integration and field testing n

The expert system development lifecycle l Comments on Phase 5: If the system is not accepted by the users, the project has largely been a waste of time. n Field testing (leading to refinement of the system) is essential, but may be quite lengthy. n

The expert system development lifecycle l Phase 6: Post-implementation n n Operation Maintenance Upgrading Periodic evaluation

The expert system development lifecycle l Comments on Phase 6: A person or group of people must be put in charge of maintenance (and, perhaps, expansion). They are responsible for correcting bugs, and updating the knowledgebase. They must therefore have some knowledge engineering skills. n The system should be evaluated, once or twice a year, in terms of its costs & benefits, its accuracy, its accessibility, and its acceptance. n

The expert system development lifecycle l Turban leaves open the options that the prototype which features in phase 3 might be an evolutionary prototype or a throwaway prototype.

evolutionary prototype or throwaway prototype · · In the 1 st case, phase 4 would consist mainly of expanding this prototype, by adding more and more knowledge, until it became the knowledge base for the finished system. In the 2 nd case, it would consist of drawing lessons from building the prototype and using these to assist in building the knowledge base from scratch, using a more appropriate tool.

evolutionary prototype or throwaway prototype · In other words, the development lifecycle as described is either a disguised form of the rapid prototyping (cyclical development) procedure mentioned earlier, or it is a substantially different approach which is liable to produce a substantially different knowledge base.

evolutionary prototype or throwaway prototype · The tendency among European knowledge engineers is to reject evolutionary prototyping (and rapid prototyping / cyclical development) in favour of throwaway prototyping. See next section for the reasons why.

evolutionary prototype or throwaway prototype · Note that some knowledge engineers would object to Turban's sequence of steps on the grounds that the computer resources should not be finally selected until the precise nature of the knowledge had been established. i. e. not until after phase 3. Again, see next section.

KADS

KADS is a development methodology for knowledge-based systems. l KADS was developed at the University of Amsterdam, as part of the ESPRIT programme, in co-operation with several European partners. l

KADS l KADS is: · · A methodology for managing knowledge engineering projects A methodology for performing knowledge elicitation.

KADS l KADS objections to rapid prototyping / cyclical development: · · · The interpretation of the verbal data is strongly influenced by the implementation formalism. i. e. , if the shell which the KE has available is based exclusively on rules, then everything the expert says will be interpreted as rules, or discarded. This results in a system based on shallow knowledge.

KADS l KADS objections to rapid prototyping / cyclical development: · Such "shallow" knowledge-based systems, which only contain representations of a limited amount of the knowledge in the domain, are unable to give acceptable explanations about their conclusions.

KADS l KADS objections to rapid prototyping / cyclical development: · · The knowledge in such a system is often unstructured, so that it's not clear where or why certain rules or guidelines have been included. It is generally difficult to adjust and to maintain such a system.

KADS l KADS objections to rapid prototyping / cyclical development: · · There is no way to decide how long the knowledge acquisition phase can be expected to last. The development tends to last as long as the budget permits, and the feasibility is not determined until the system is ready. Such projects are barely manageable.

KADS l KADS objections to rapid prototyping / cyclical development: · · Therefore, this approach is highly unsatisfactory for the development of commercial systems, where the goal is to build a system which can execute a predetermined task at a specified level, for a predetermined budget. For a commercial system, the feasibility and scale of the project must be estimated at an early stage.

KADS · The KADS alternative: · Build a conceptual model of the domain expert's knowledge, including his/her problem solving strategies. Take it to its final, complete state before doing any program building.

KADS · The KADS alternative: · When eliciting knowledge from the DE, use the KADS scheme which organises knowledge into several layers: · Facts about entities in the domain, and their relationships, are found in the bottom layer. · Strategies for finding pieces of information (or other small-scale tasks) are found in the layer above. · Strategies for performing larger tasks, such as doing a diagnosis, are found in the layer above.

KADS · · When structuring the domain knowledge in this way, be guided by the KADS library of Interpretation Models. These are descriptions of various different general problem-solving tasks. e. g. if you decide that the task your expert system must perform is "singlefault systematic diagnosis by causal tracing", there will be an interpretation model corresponding to this. It will describe the contents of the various layers, in general terms, and give you guidance as to what pieces of knowledge you should expect the DE to provide you with.

KADS · Imposing a structure on the knowledge elicitation task in this way should ensure that · the expert system that is subsequently built contains knowledge which has a suitable degree of depth;

KADS · Imposing a structure on the knowledge elicitation task in this way should ensure that · the DE's knowledge is stored, in its final form, as a set of intermediate representations; at a later date, a knowledge engineer can revise the system, or build a new system, from this stored knowledge, rather than having to work with the original DE.

KADS · Imposing a structure on the knowledge elicitation task in this way should ensure that · The knowledge elicitation task is shorter, and of predictable length.