Systems development life-cycle for expert systems Ritu Agarwal and Mohan Tanniru*

Existing life-cycles for the development of traditional information systems are shown to be inadequate for addressing expert system requirements. A life cycle for expert systems is constructed, outlining the tasks and activities to be performed at each stage of system development. The life cycle highlights the role of alternative development paradigms and the importance of social and organizational characteristics in system transfer to users. The operationalization of the life- cycle is illustrated through a case study, describing the development process and major architectural compo- nents of an expert system that configures air- conditioning units. Several important issues encoun- tered in transferring the system from test to production mode and in system evaluation are highlighted. Such a life-cycle approach can enhance project management for expert systems.

Keywords: expert systems, project management, man- agement information systems, transaction processing systems

The structured development life cycle (SDLC) approach used for the development of traditional management information systems (MIS) and trans- action processing systems (TPS) has become a widely accepted, efficacious technique for managing the com- plexity of large software development projects. In- formation intensive and technologically advanced in- dustries possess over two decades of experience in using this methodology, which prescribes a structured, phased, linear approach to system development 1,2. This experience is manifest in the form of cadres of trained systems professionals, in well-documented and expli- cated guidelines for systems development and docu- mentation, and in the delineation of the precise products or deliverables of each phase. Despite minor variations in the usage of terminology, there is agree- ment that the major phases of the SDLC, in terms of

Department of MIS and Decision Sciences, The University of Dayton, Dayton, OH 45469-0001, USA *School of Management, Syracuse University, Syracuse, NY 13244- 2130, USA Paper received 21 June 1989. Revised paper received 20 November 1989. Accepted 5 January 1990

their functionality, include project definition, require- ments determination, logical design, physical design, testing and implementation activities Lz.

The life-cycle approach rests on one fundamental assumption--that system requirements are well- defined and temporally static, at least in the short term 3. This assumption has proved to be incompatible with the computing trends witnessed in the 1980s. As the usage of information technology permeated to more decision-oriented applications, an alternative development strategy called prototyping was pro- posed 4,s. Prototyping, which prescribes iteration as opposed to linearity in system development, was adopted in situations where requirements were not well-defined and has been utilized fairly extensively for facilitating the development of systems by end-users and for the development of customized systems such as decision support systems 3. The advantages of the prototyping approach are evidenced in its ability to deliver systems in a more timely fashion to users. Thus, organizations have learned to use both approaches in a complementary manner, with the life cycle being used for large, complex projects and prototyping being restricted to simple projects in a single or small group user environment.

Expert systems technology is presenting a new challenge to the same group of industries interested in exploiting it for commercial benefit. While there are numerous accounts of how systems developed using expert systems technology have provided industries with improved service, reduced costs and, generally, a competitive edge, these accounts are incomplete speci- fications of ES development and implementation as they have tended to have a product as opposed to a process orientation. Multiple descriptions of architectures for knowledge-based systems can be found, but there is little reported evidence of the successes and failures experienced when these systems actually went live. There are some exceptions to this generalization--notably the systems developed at DEC 7, but by and large, these have tended to be enormous projects involving substantial outlays in monetary and other resources.

The espoused development strategy for expert sys- tems is an evolutionary, prototyping approach where the system evolves in multiple stages through continual interaction between the knowledge engineer and the

170 0950-7051/90/030170-11 © 1990 Butterworth-Heinemann Ltd Knowledge-Based Systems

expert(s) 8. Clearly prototyping is desirable, even essen- tial, in environments where system requirements are dynamic, ill-specified and not easily articulated 5. However, the implementation of expert systems re- quires an eventual transfer of these systems to non- expert users in order to disseminate the expertise in a secure and consistent manner. This issue of 'transfer to users' is never explicitly discussed in systems built using prototyping, as users are actively involved in the development and are, for all practical purposes, owners of these systems. Further, the onus of responsibility of system integrity and correctness often falls upon them as opposed to the system development staff.

The contraints experienced in an expert systems environment are different as users are non-experts and are minimally, if at all, involved in the system development process. Expert systems developed for commercial as opposed to scientific applications re- quire an entirely new paradigm of systems develop- ment. They must be integrated with existing corporate databases, they must address connectivity issues if they are to be accessible through existing communications networks, and they must provide adequate security as the knowledge captured in them is a valuable organiza- tional resource. Even if all commercial expert systems applications do not fit this mould, these issues will have to be resolved by the systems developement staff sooner or later if expert systems are to become an integral part of the organization's use of computing technology. It should be noted that the SDLC approach addresses these issues in the design and implementation phases as systems are moved from development or test to production mode.

The commercial development and implementation of expert systems necessitates a synthesis of the life-cycle and prototyping strategies as prototypes must eventual- ly be transformed into usable production systems. The life cycle approach supplies the beginning and end stages of ES development, i.e. project definition and implementation and operation. The activities in be- tween the two stages must follow an essentially iterative cycle until the system has reached the desired stability. The objectives of this paper are two-fold. First, a consolidated life cycle for expert system development is constructed, and second, this life cycle is related to experiences in the development of an expert system for configuring orders in a large manufacturing organiza- tion. The development of this system provides an interesting perspective on the dichotomy between the theory and the practice of expert system development and provides an empirical understanding of how the life cycle may be operationalized.

AN E X P E R T SYSTEM LIFE CYCLE

A frequently encountered misconception in the litera- ture and in the computing industry is that the term life cycle connotes a rigid set of activities that are arranged in sequence of task execution 2. Recently, Enger 1 extended the concept of a life cycle to any type of new system development where the objective of describing a life cycle is not so much to prescribe rigidity, but more to emphasize the application of sound management principles to system development. A life cycle for expert systems is described below, highlighting the

points of convergence and divergence between the SDLC and the expert systems development life cycle (ESDLC). With regard to terminology, the term 'phase' will be used to denote a discrete point in time where a specific deliverable of the project is completed. Phases consist of activities or tasks, which may or may not have products associated with them.

Both life cycles are initiated in a similar fashion, with the problem identification phase of the ESDLC corres- ponding to the project definition phase of the SDLC. The tasks in problem identification include determining whether the real-world problem has a corresponding expert system solution, whether this solution is admissi- ble in terms of cost, feasibility, availability of expertise, and any other criteria the organization may consider relevant, and obtaining the necessary resource commit- ment for system development9,10. These activities of the ESDLC are grouped under phase 1, where the development process is essentially structured, with the deliverable of this phase being a project description statement, outlining the problem, the experts to be used for its solution, and the resources available. In addition, the benefits that the organization hopes to obtain from the expert system development effort must be specified.

The divergence between the SDLC and the ESDLC is evident in phase 2, where the activities of the ESDLC in phase 2 subsume the phases of requirements determination, logical design, physical design, and testing of the SDLC. While it is appropriate in the SDLC for these activities to constitute distinct phases, the rationale used here for grouping problem concep- tualization, formalization, implementation and testing in the ESDLC derives from the inherently iterative nature of these activities. Thus, problem conceptualiza- tion leads to the identification of specific examples of problem solving activity, formalization involves the mapping of domain objects and concepts into a machine representable language, implementation sug- gests the actual coding of the formalized concepts, and testing involves validating the encoded concepts for correctness and completeness. Anomalies or incom- plete information for any activity may necessitate a re-initiation of previous tasks. The appropriate de- velopment strategy for this phase is the prototyping approach, which specifically allows for the inclusion of feedback. The deliverable at the end of this phase is an acceptable, working expert system that is complete in all respects and capable of functioning on a standalone basis.

The penultimate phase in the SDLC is implementa- tion, or the successful integration of the system with the environment in which it will operate. Implementation includes converting the information system from de- velopment to production, completing all system docu- mentation and establishing procedures for handing over the system to its clients. Analogously, in the ESDLC, phase 3 is termed the transfer to production phase. The activities to be performed here include some tasks completed in earlier phases of the SDLC, viz., database access and update procedures, control design, and interface design, where connectivity issues are resolved, Bobrow and Stefik n provide an evocative characterization of this stage by highlighting that an expert system is not merely a piece of software, but

Vol 3 No 3 September 1990 171

rather, a process that needs to be put in place in a user organization.

The SDLC and the ESDLC both terminate in a similar fashion--with the system operation phase. The activities in the SDLC constituting this last phase include on-going maintenance/enhancement and sys- tem evaluation. Similarly, the ESDLC phase includes enhancements and evaluation. While maintenance and enhancement connote approximately similar activities, the focus of the evaluation exercise is different for the two life cycles. In the SDLC, evaluation entails comparing the functionality of the operational system to the initial system specifications in order to determine whether the system fulfills its design requirements ~. The implicit assumption here is that if specifications are adequately met, then the system will deliver the benefits for which it was originally conceived. This assumption is reasonable as there is enough reported evidence and experience in the development of tradi- tional systems, and there is little or no uncertainty in the correspondence between a technological solution and its benefits. For example, a system which auto- mates inventory accounting, if developed correctly, will most likely lead to a reduction in the number of stock-outs and misplaced items.

In the ESDLC, on the other hand, evaluation must focus on whether the expert system delivers the benefits that motivated project initiation. Clearly, the functional specification for any expert system is that it effectively clone the decision making process of the expert, and this must be minimally satisfied and verified before the system is transferred to production. More importantly, however, as this is a new technol- ogy, it is incumbent upon the development team to determine the tangible benefits obtainable from the system. If it cannot be demonstrated convincingly that the system delivers its anticipated benefits, then user confidence in and corporate commitment to the tech- nology are likely to decline. Further, the usability of the system from the perspective of its eventual clients, must be evaluated. The acceptability of an ES to its users is the final determinant of its eventual success or failure. In the SDLC, system usability forms a part of logical design where man-machine interface issues are resolved.

The objective of constructing a life cycle for system development is to facilitate project management and to guard against the inadvertent omission of any tasks that are necessary for the eventual success of the system. With this objective in mind, a life cycle for expert systems has been described. The life cycle is intended to serve as a template against which an organization can monitor and assess its expert system development efforts, and not all activities in all phases may be applicable to every expert system development project. Figure 1 describes the SDLC and the ESDLC phases and the activities performed in each phase. This life-cycle was synthesized from the authors' experiences in expert systems development. In the remainder of this paper, one such specific expert system is described to demonstrate the operation of the ESDLC.

D E V E L O P M E N T O F CONFIGURATOR

This section describes the business problem and its

~haee 1

ProiecL Definitian

I ~htee 2

R~'ou ir~,z~ f Dt fel'm~tal'/oa

1 ~htee 3

Logical Design

Input/Output Design Data Base/File Design Conerol design

I P h a ~

Phusical Design

rrogramm~ toOc Coding

I

Testin~

Prqp'*m T e s ~ Syst~a Tesfmg

I ~lut~e 6

lmnlementatioH

Convexdon t~ Production Documentation Transfer to Clients

I ~hmse 7

O~eratiom

Maintenance/ Fad~nomumt

Evaluation

~ a s e

Problem Id~t l f lcat ion

Economic feasibility Technical ~easlbility Operational feasibility

( Sul tan Develonm~nt

Conceptualization Formalization

Objec~ Relationships

Implementation

Coding

Tesling

Advice

Exphmation User Interface

I I

Corm,~vity ] Database Access and Update Security

I ~'hmN 4

Malntemmcc/ F.ahmcement

Evaluation

SDLC ESDLC

Figure 1. Life cycles for traditional and expert systems

expert system solution, highlighting the potential ben- efits from transferring the activities performed manual- ly to a knowledge-based system. Configurator was built to configure a set of part numbers for a particular air-conditioning equipment series based upon customer request. The part numbers configured by the system include the unit number and a variety of coil and motor numbers based on the model and unit size of the equipment chosen. While this was not a task that required considerable expertise in the sense that we conventionally understand, its payoff rested in the numerous weaknesses in the existing system and the sheer volume of the task performed.

Under the existing system, a salesperson fills an order form based on customer needs. The order form is then transmitted to the main office where the first task that is performed is order completion and validation. The complete and valid order is priced and sent to manufacturing to fill the order. Pricing information is used to complete a sales contract which is then signed by the customer.

The salesperson does not fill out the entire form, as some of the information required can be deduced, based on existing design relationships, from the in- formation that has been provided. For example, if a customer chooses a particular model and coil types, then the code for the coil fastener package can be determined automatically. Such dependent fields are completed by personnel at the order processing office. Several inconsistencies are evident in the completion of these fields. For example, a coil option is requested which cannot be used with the model chosen. In addition, several important data items were observed

172 Knowledge-Based Systems

to be either missing (e.g. insulation code missing), incompletely specified (e.g. an electric coil chosen without providing a specific voltage), or inaccurately specified (e.g. a r.p.m, selected for the motor that is incompatible with the horse power chosen). Any or all of these inconsistencies in the information result in order processing delays as additional time is being spent to contact either the salesperson or the customer for obtaining clarification.

Order validation is performed by an individual cognizant of design relationships and equipped with the knowledge of where to locate the ones he is not knowledgeable about. In addition, even with this knowledge and experience, errors of transcription and look-up could occur and propagate through the system both in pricing and assembly. Since there is no other check on the order after this point, it is conceivable that an order is filled incorrectly (i.e. the design is feasible but not what the customer requested) or an order is found to be infeasible after it is manufactured (i.e. the design options are such that the product cannot be assembled from its component parts).

An expert system was built to interact with sales- people as they filled orders so that the orders could be complete, correct and free from design errors. The design dependencies are stored as part of the know- ledge base and the inference mechanism guides the user's interaction with the system in order to configure a valid set of part numbers. Once a set of valid part numbers has been prepared, they can be used for pricing, preparing a bill of materials as part of the maufacturing process and preparing a contract for the customer.

The benefits that can accrue to an organization by using such a system are numerous. First, it assists in the reduction of errors (transcription and design) that surface in the current system. In addition, it helps in the reduction of delays caused by data transmission and clarification as the system is available at the source of the interaction between the salesperson and the cus- tomer. It can enhance customer support if it is integrated with manufacturing (by computing a tenta- tive delivery date) and pricing (by providing a com- pletely priced order). While it cannot rectify errors in the selection of options that are free of design problems, these can be minimized by providing the customer with a hard copy of the order for visual verification and also by providing certain salient information about the product as it is configured (i.e. the options most appropriate for certain kinds of environments, the amount of resource used by a selected model, the characteristics of the model in the customer's terminology, etc.) in order to detect any problems with an order when it is placed.

Expert system development process

Buchanan et al. 12 identified a five-step, iterative approach to expert system development. This approach is used as a basis for structuring the activities performed in the development of Configurator. While the approach proposed by them does reflect the sequence of tasks undertaken, one important distinction must subsequently be made in the definition of the 'imple- mentation' phase.

Problem identification Problem identification corresponds to the first step in the expert system development life cycle. Generally, all accounts of expert system projects have assumed that the problem has already been identified and have gone on to describe the development and architecture of the system in detail. However, as with any other informa- tion systems project, there are typically numerous business problems existing concurrently that could be potential candidates for expert systems solutions9,10. How does an organization make the trade-offs involved in selecting one project to the exclusion of the others?

The answer to this question is largely context- dependent. In the case of Configurator, as a part of the general investigation of the types of problems that can be solved using ES technology, the product configura- tion system was proposed along with several others. In discussions with the business analyst closely associated with this configuration, the product configuration system was found to be the most viable candidate for the reasons outlined in Table 1. The characteristics of the system under consideration provided sufficient justification that it was indeed a meritorious candidate for expert system development. It should be noted that, in contrast to the SDLC approach, a detailed cost- benefit analysis cannot be conducted for expert system projects because of the very real problem of quantifica- tion of benefits and costs, as expert system technology is still in its incipient stages and metrics for these purposes have still to be developed. Thus, selection decisions must be based on essentially a subjective evaluation of the feasibility of the system, the potential benefits derivable from the system, its criticality in terms of addressing a pressing business concern and the opportunity costs of not having such a system.

Problem conceptualization An initial discussion between the knowledge engineer and the expert helped clarify the scope of the system, its basic features in more detail, and to identify a sub-problem that could be implemented relatively quickly, in order to obtain feedback from the expert as to the feasibility and desirability of the system. Based on this preliminary discussion, the problem was sub- divided into unit, motor/drive and coil subsystems. A part of unit number determination was developed within a week using a rule-based expert system shell.

One point that requires some elaboration at this stage was the decision to use a rule-based representa- tion for the system. The theory recommends that knowledge acquisition and representation be made two distinct phases in the system development cycle so as to obviate the possibility of a representation mismatch ~2. The motivations underlying these views are to develop technical artifacts that mirror the world-view of the expert more closely, and are, hence, easier to validate and maintain. While there is much merit in these observations, the commercial reality is quite different. Typically, organizations do not possess an infinite amount of resource to acquire expert system software that permits flexibility in being able to represent knowledge using different paradigms (rule-based, object-based, logic-based, etc.) Further, the costs involved in training personnel to become skilled using multiple types of systems can be fairly prohibitive,

Vol 3 No 3 September 1990 173

Table 1. Characteristics of application domain

Technical assessment

Domain requires expert knowledge Task requires expertise Task requires symbolic reasoning Task requires the use of heuristics Conventional (algorithmic) approaches not adequate Gaining expertise requires time Expertise will not be available reliably

Operational assessment

Yes Yes Preferable Yes No, but less flexible Yes Yes

Knowledge can be acquired from a limited domain Task is of reasonable complexity Task is clearly defined Task teachable or knowledge extractable Recognized expert exists Expert has credibility Expert is available and can communicate knowledge Expert is willing to assist Initial information provided by expert is substantial Preferably one expert or one primary expert

Yes Yes Yes Yes/no Yes Yes Yes Yes Yes Yes

Task sufficiently narrow and self-contained Task decomposable and can tolerate ambiguity Concepts required are bounded Phasing in the system is feasible Unobtrusive, non-controversial and non-sensitive task Domain fairly stable and test data available Similar types of systems exist Project not time-bound Payoffs measurable and performance verifiable

Organizational assessment

Yes Yes/No Yes Yes Yes Yes/Yes Yes Yes May be/Yes

Knowledge base interesting Goal: expand technology or develop usable system Significant payoffs expected Project meets goal/risk tradeoffs Management understand limitations and provide support System requirements well understood Significant user interest

Possibly Both Possibly Possibly Support for prototype Yes Yes

particularly if the organization is still in an evaluative stage with respect to expert systems technology and is not willing to make a major resource commitment up front.

A rule-based shell was used to implement Configur- ator for very pragmatic reasons. The organization already had such a shell in its possession, and their objectives were more to answer questions of the type: should expert systems technology be used for applica- tion development in this organization, and if so, what types of problems can be reasonably addressed? No decision was made at that time as to the type of knowledge representation or shell that would eventual- ly become the standard for subsequent development. This decision was deferred until the results of the initial investigation had been obtained. Given the availability of the rule-based shell, the candidate applications were those that had a type of knowledge structure that was amenable to a production rule representation. In other words, it was the tool that guided the problem selection

to answer the broader question of whether the orga- nization should make an investment in expert systems technology. Obviously such an approach is undesirable in most cases as the nature of the knowledge to be represented must be assessed prior to committing to a representation formalism.

Formalization Knowledge for developing an initial understanding of the domain and its subsequent refinement was acquired from two individuals: a design engineer who was the designated 'expert' on the project, and another expert who was currently performing the task on a daily basis. The domain was such that detailed knowledge was already available in written form (the so-called public knowledge~3), resident on cryptic order sheets, and this reduced the number of meetings needed with the expert. Interviewing and verbal protocol analysis ~4 were the major knowledge acquisition techniques used. Since the domain skills were more knowledge intensive

174 Knowledge-Based Systems

and experiential as opposed to cognitive and subjec- tive, the traditional problems with protocol analysis (viz., the generation of reconstructed 15 accounts of reasoning) were not encountered. These techniques helped extract the 'private' knowledge of the expert that was not explicitly documented. Simple production rules of the form: if (antecedent parameters) then (consequent parameters) were found to be adequate to capture the expertise.

Inplementation A clarification with respect to terminology is appropri- ate here. Implementation, as suggested in the approach proposed by Buchanan et a112, relates to the translation of domain concepts into machine manipulable form. In traditional systems, that activity is frequently called programming, and implementation has a much broader connotation in that it specifies what happens after the system has been completely developed. We will use the term implementation here in the manner that it was intended to be used in ES development and later expand its coverage to include the issues of handing over the system to its clients.

The unit sub-problem was represented in the system and the expert asked to evaluate the simple prototype. The initial reaction was extremely favourable. The interaction between the expert and the prototype highlighted the need for additional knowledge on the way certain design decisions were made. Further, specific operating requirements such as menu-driven user-friendly interfaces, access to databases for in- formation retrieval, and control over the line of questioning put forth by the system to the salesperson were identified by the expert.

Prior to making a commitment to implementing all the subproblems, the operating requirements specified by the expert were tested using the shell. The shell provided for easy access to the database tables, facilitated user-friendly interaction through screen de- velopment routines, and permitted the knowledge engineer to control actively the inferencing mechanism, i.e., request parameter values in a certain order, fire rules in a certain sequence, execute certain operations repeatedly, branch to modules based on the satisfaction of certain conditions, etc. This prototype was used to demonstrate to the expert that the expert systems environment does, in fact, provide flexibility for any future modifications and is capable of gathering the required information effectively.

Before proceeding with a complete development of the application, additional demonstrations were used to obtain feedback from individuals either involved in or familiar with the existing system. This group included individuals who would eventually be involved in the interface of Configurator with other applications such as pricing, bill of material preparation, etc., and individuals who were familiar with systems of a similar functionality but developed in alternative computing environments using, for example, a procedural lang- uage such as COBOL. These demonstrations helped reinforce the view of both the knowledge engineering and the management groups that Configurator was indeed a justifiable candidate for expert systems development. The prototype, with additional revisions, became a usable system in a matter of two months.

Testing Performance verification for expert systems is critical as the risks inherent in a system that delivers incorrect advice can be enormous. It has been recommended that multiple features of an expert system, including its recommendations, the reasoning modelled in it, the user interface and the explanation facilities be subject to testing and validation s .

Configurator was extensively tested using several different scenarios during the demonstration sessions. Care was taken to ensure that a sufficiently wide range of test cases were generated in order to achieve domain coverage. Production rules are theoretically supposed to represent modular, independent chunks of know- ledge. However, in practice, rules are never completely independent of each other and may interact in unex- pected ways. The logic encapsulated in the inference rules was validated thoroughly so as to avoid any unanticipated consequences of rule interaction.

Configurator exemplifies some of the more tangible benefits that organizations can realize through the adoption of expert systems technology. Systems which are small in scope but demonstrably useful and complete will, in the long run, pay a greater return on investment than systems that address large problems but are doomed to remain mere prototypes that never manage to make the transition from the designer's computer to the client's computer. The problem addressed by Configurator was not one that required great skill. However, the intricacies of the design relationships and the large number of these rela- tionships made the achievement of consistency in decision making almost impossible. This consistency and correctness was enabled by capturing the task in a computer-based system. The following section des- cribes the activities that were performed in order to transfer the system to production and operation.

F R O M D E V E L O P M E N T TO P R O D U C T I O N AND BEYOND

In order to make the expertise embedded in an expert system easily accessible to a large number of non- expert users, these systems may need to be connected with existing communications networks, protected from unauthorized access/update from remote loca- tions, and integrated with corporate databases for both obtaining required information and transferring results. However, none of these issues have been specifically addressed in the development processes proposed for expert systems. In conventional systems, the aforemen- tioned issues comprise a part of database design, implementation and control design. In this paper, another step is added to Buchanan's ~2 expert system development life-cycle: transfer to production, and some of the activities that are of interest in this stage elaborated on. While not all of these activities may be performed for every expert system application, the intent here is to highlight the major issues that must be resolved at this stage.

Transfer to production

Moving an expert system application from its development/test mode to production mode may not

Vol 3 No 3 September 1990 175

always be necessary. For example, if the expert system is providing guidance to a limited number of individuals in a controlled environment, the development version may be used for both consultation and enhancement purposes. In the case of Configurator, the system had to be made available in an interactive mode to a large number of individuals residing in multiple locations for purposes of consultation. Simultaneously, the system had to be accessible to the knowledge engineer and the expert for iterative development and refinement. The question that arose at this point was that if we were to maintain only one copy of the system for both development and consultation, how would the prob- lems of concurrent access and update of the knowledge base be tackled?

This scenario is similar to that observed in the case of concurrent access and update of databases. In data- bases, the nature of updates (addition, modification and deletion of records) can be relatively brief, largely pre-defined and sometimes prescheduled. However, changes to a knowledge base can be rather extensive and may require a longer testing period to ensure update integrity, may be somewhat unpredictable in terms of when they become necessary and may be difficult to preschedule (as the expert does not always provide information at discrete time intervals). For these very compelling reasons, it may be decided to separate the test/development version of the know- ledge base from its production version. Several issues have surfaced when such a separation was proposed for Configurator, including when the knowledge base should be moved from test to production, what procedures are to be followed to accomplish this move and, how acceptable the system will be to users if the explicated rationale for decision making changes fre- quently and dramatically?

Connectivity While the information provided by an expert system can be used on a standalone basis, this may not be the most productive utilization of it. Most business opera- tions synthesize information from several systems in order to realize greater productivity and to reduce the time lost in system transfers. It is logical for an organization to wish to link a product configuration system to pricing, sheduling and inventory control systems to speedup operations such as the order processing task. This requires the expert system to be able to talk with systems developed using other languages and machines. The relevance of the connec- tivity issue is independent of whether the expert system is in development or in production mode, as these interfaces must be established reliably. Even if the expert system is not connected to other application systems, it is possible that the results of a consultation may be transmitted via electronic mail, through a word processor, in order to generate a report. In other words, it may become necessary for the system to link effectively with resident office communication software and remote area networks.

Database access/update Many expert systems in commercial environments have to access data (or parameter values) from other

applications and transmit their results to a database for access by other applications. This will not be the case, of course, if the expert system is stand-alone and generates all its input information interactively from the user and provides the output to that user for possible action. In the case of Configurator, integration with other systems via access/update of database records became essential. Since most organizations have well established procedures for accessing, updat- ing and maintaining database records, the expert systems' database interface must be reconciled with the existing data administration procedures. Several issues arise during this reconciliation process, including:

• Should the database update be performed through the expert system environment by multiple users (as is the case with Configurator) or should the two activities be distinct?

• Should the database used by the expert system be different for test and production versions, and if so, are these to be temporally synchronized with the expert system transfer?

• How will the back up and recovery procedures be handled if the database updates are to occur through the expert system consultation, rather than being routed through established database maintenance procedures?

The scope of this paper does not permit a detailed discussion of how these issues were addressed in the case of Configurator (for additional details see Refer- ence 16). It is, however, important to note that these issues acquire a special significance when the consulting parties not only have access to the database, but are also able to update it.

Security Given the amount of investment an organization makes in the development of an expert system knowledge base, the knowledge encoded in the system becomes a valuable organizational resource. This knowledge must be made available in both development (where detailed knowledge is easily visible for access and update) and in consultation mode (where the system is available primarily to provide an expert solution or explanation, without allowing users to view or update any part of the knowledge base). In a stand-alone controlled environ- ment, this may not be as much of a problem as it might in an expert system available at remote sites through communications networks. Some security issues that surface here are:

• What knowledge bases should a client be able to consult and view but not update, and what know- ledge bases should he/she be permitted to only consult and not view?

• What knowledge bases is a knowledge engineer permitted to develop, i.e. have access and update privileges, and how can one ensure that this know- ledge engineer is treated merely as a client for other knowledge bases?

• What security issues and grant authorities need to be provided for databases if they are to be accessed through the expert system?

176 Knowledge-Based Systems

In transferring Configurator from test to production mode, these issues were addressed extensively so that the organization's investment in the development of the knowledge base was not jeopardized. A point to note here is that while some expert system development environments (notably the PC-based shells) make it convenient to transfer, view, copy and update know- ledge bases, this flexibility must be evaluated against the security an organization wishes to provide for its expert systems.

System maintenance and evaluation

The set of activities described above are critical for ensuring the longevity and security of any computer- based information system, with expert systems being no exception. As highlighted in the section the develop- ment of Configurator, the final tasks in the ESDLC include system maintenance and evaluation. The ways in which these issues were addressed for Configurator are described briefly below.

System operation Configurator was anticipated to deliver three major benefits:

• reducing errors in transcription and design con- figurations,

• reducing delays in processing customer sales orders, • integrating with other systems such as pricing and

manufacturing.

The planning for system transfer identified three major stages to address each of these benefits. The first stage called for system transfer to the individual responsible for order validation so that design and transcription errors may be reduced. This transfer has been com- pleted and all errors (approximately 8% of the orders) attributable to design configuration and transcription eliminated. The rapid and successful completion of the first stage was partly due to the limited number of individuals involved in using the system. The second stage was envisaged as system transfer to the field in order to reduce order processing delays, a process with a much wider scope as a large number of remote locations were involved. This stage has been delayed for the following reasons. First, a new version of the expert shell used for development which was more efficient became available and a corresponding new version of Configurator had to be developed. Second, while the system was very successful in its reduction of errors, the process of using it made the initial set of clients view it from a different perspective that was more marketing oriented. This led to suggestions for improving the user interface and incorporating addi- tional features to make the help facility more meaning- ful. Management is waiting to complete these enhance- ments prior to making the system available to sales personnel.

Overall, the design of the system was considered to be very successful. While plans are underway to fully realize the benefits that were initially attributed to this venture, product configurations for other and more complex product lines have already been initiated. The next section presents some technical details and the major architectural components of Configurator.

CONFIGURATOR ARCHITECTURE

In this section, some of the major architectural components of Configurator are described. The follow- ing discussion begins with an elaboration on the characteristics of the knowledge base, describes the overall architecture, and presents the inferencing and search mechanisms employed by the system.

The domain of the system did not include imprecise information and thus, the manipulation of inexact or uncertain information was not required of the applica- tion. The design relationships were well documented and widely consulted by all the individuals involved in order validation. Thus, the knowledge acquisition exercise in system development did not have to address the issue of cognitive limitations on the part of the expert to articulate his problem-solving behaviour adequately. The structure inherent in the task also precluded any inabilities on the part of the expert to recall past decisions effectively. However, certain design computations provided by the expert were refuted by the individual involved in the routine completion of orders and these were brought to the surface to be reconciled. Differences in opinion occur- red with respect to the way in which a particular model was handled for coil placement. The expert subse- quently retracted his original logic as the model in question was in the design stage at that time and not related to the model currently on the market. This lag between the knowledge possessed by an expert and that accepted by the organization as valid is not unusual in situations where information is not disseminated until it has passed commercial testing and marketing.

Configurator has been implemented in IBM's main- frame expert system shell, ESE. While there was no specific evaluation conducted to see how well the shell fared against others which provided a similar repre- sentation and reasoning, the application selected was well suited for the shell's operating environment. Its menu-driven interface, screen-construction facilities, modular structure and the availability of backward as well as forward reasoning rendered it extremely suit- able for the product configuration application. The shell also provides access to external databases and procedures, with this access being transparent to the user.

Briefly, the expert system constructs a set of part numbers based on user input. The part numbers for coils 1, 2, and 3 are dependent on the model and unit size. Similarly, the use of hot water or electric coils is dependent on some of the accessories selected by the customer. Each order may or may not request a motor (and drive). In addition, certain accessories are not appropriate with certain other user-provided input even though the design of the product is still feasible. In this case, the user is informed of potential anomalies and provided with the option of either changing the input or proceeding further if that is, in fact, what the customer desires. The system also validates the acces- sories requested by the user by checking them against the database containing valid options. If the user input is incorrect, the system provides the user with a set of valid options and requests a re-input of data. An overview of the system architecture is provided in Figure 2. The major architectural components are described below.

Vol 3 No 3 September 1990 177

| Filter I [ Filter/ Airf low [

- i Obtain 1 [ | ~ Unit I [ i. ~ Information |

- N 7 Motor~.'ve t

[ 0b , ; i ; . . . . . . ! . . . .

Coil3 I Information ]

& DB2

DataBase

* Access database to obtain valid air flow codes, test user input, and iterate till code is valid

** Certain combinations of filter/air f low optiom are not desirable. User is requested for clarification, and, if needed, reinput is it.quested

~ Either/ or

Any combination of these

~ 1 ~ May or may not exist, dependin 8 on user input of model size and other characteristics

Figure 2. Organization of modules (focus control blocks) in Configurator

Backward chaining The rule-based system primarily uses a backward- chaining mechanism to determine the values of the goal parameters. In backward-chaining systems, the goal is matched with the right-hand side of productions in the knowledge base to determine which rule should be executed 8. The system then attempts to satisfy the left-hand side of the rule, by either matching it with known facts or executing other rules in order to satisfy antecedent subgoals. For example, the relationship

(Parameter) U_code = model II unit_size ]l- • •

is used to define U_code, a goal parameter. The values of model, unit_size, etc. are automatically sought by the system as it attempts to establish a value for U_code. If these values are determined internally or sought from the user, then the system will search for them accordingly. Otherwise, if the knowledge base contains rules that establish the values of these para- meters, then these rules are enabled by the inference engine. This implies that the system is now looking to establish the values of the parameters that appear in the premise (or antecedent) clauses of these rules, and this process continues until such time as all the values for establishing the goal have been determined.

Forward chaining The forward-chaining mechanism is used to inactivate certain modules that are rendered irrelevant by user input. Forward chaining allows the system to generate new facts from already known facts. For example, if the model is, say, 'A', then only the coil 1 module is relevant and need be executed. Using Discover, the system is asked to deactivate those modules that are not relevant. The forward-chaining mechanism can be controlled by asking the system to enable only the execution of rules that are specifically related to this particular task. An illustration of the forward-chaining mechanism is provided below.

Discover--use(rule1, rule2, rule3) rulel: IF model is 'A'

THEN don't consider coil2 and don't consider coil3

rule2: IF model is not 'A' THEN don't consider coil 1

rule3: IF model is 'F' AND unit_size is '05' THEN don't consider coil2

Iterative input The ability to incorporate the 'redoing' of certain

178 Knowledge-Based Systems

operations when the input is not valid is feasible in the ESE environment. For example, the user may input a set of accessories and the system verifies this input by comparing it with a set of valid options. If the input is deemed invalid, the system automatically backtracks by providing a set of valid options and requesting a re-input by the user. This facility is exhibited below.

main module:

determine alLoptions/access data base to obtain list of options/

establish options

options module: ask accessories

/call the module to input accessories desired/

/let the user input the accessories desired/

discover--use (rule_ok, rule_not_ok) /enable forward chaining/

rule_ok:

rule_not_ok:

if position of accessories on all_ options > 0 then don't consider options

/check for membership and deactivate the options module if necessary/

if position of accessories on alL options = 0 then show 'incorrect accessory option, the valid options are: vl*alLoptions. Enter the accessories again' and pursue another option

/if no membership, display error message, list valid data, and reexecute options module/

Database access

The shell also provides mechanisms for accessing a database table residing in the DB2 system by allowing a parameter to obtain its values through external access as opposed to the normal defaults (rule inference, user input or default). By defining a parameter as external, a database procedure call can be established to access the database, obtain the desired values and assign the results to the parameter which makes the database call. The database facility defined below.

parameter: range

source sequence: external

procedure name: sql

is demonstrated in the code

/parameter in ESE that is to be assigned a value/

/assigning the result from DB2 to range/

/call to data base using sql/ procedure arguments:

table: xyz /table name in DB2 is xyz/ column: hp

/select value from column hp/ condition: 'il = :vq*il and ml = :vq*ml'

/assign value of il and ml in

ESE to il and ml in the query to select the relevant row of xyz/

access (select range) /call in the FCB to direct the needed retrieval/

This code executes with reference to an existing DB2 table, 'XYZ' and using the values of il and ml defined in the expert system, performs a select operation on the table. The value of hp that satisfies this condition is then passed on to the parameter 'range' in the expert system. The shell provides the flexibility to define and update DB2 tables directly from the knowledge base. As illustrated earlier, this access, though desirable from an efficiency perspective in that separate databases did not have to be created, can create new problems when attempting to establish system integrity and security.

Screen facilities

One of the more important features of the shell with respect to Configurator was the screen generation facility. This facility allows for the creation of elaborate screens for collecting single as well as multiple para- meter inputs. This allowed the number of screens needed to input the data, to be reduced, and all the related data to be input at once, and made it easier to present what has been input thus far at discreet points in time for review and re-input. Figure 3 shows a sample screen layout.

Meta rules

Meta rules encapsulate 'knowledge about knowledge' and can be used to proactively guide the inference mechanism. The use of meta rules, i.e. rules that activate or deactivate other rules is accomplished indirectly in Configurator either by deactivating an FCB that contains these rules (as shown earlier with the function 'don't consider') or by asking the system not to consider certain parameter(s) whose values are esti- mated by these rules. The tree diagram in Figure 4 illustrates how the search process can be controlled through the use of meta rules.

Product configurator an expert system

PF1 Help PF2 Review PF3 End PF4 What PF5 Question PF6 Unknown PF7 Up PF8 Down PF9 Tab PF10 How PF11 Why PF12 Command

: >

Figure 3. Sample screen layout

Enter the model type

- A _ B x C _ D - E _ F - G - H

Enter the unit size, large face area in square feet

- 03 _ 0 6 x 08 _ 10 _ 12 - 15

Vol 3 No 3 September 1990 179

m o d e l = X model no~×)

M = I a[=2 aI=O m o d e l = x l m o d e l = x2 modl¢l. ~L3

i " ' l ~ i ' ~ : @ i"~.~'~:-"''l'~i."'"N = y s i z e no t~y l

......... \ . ,?° t . .~ \~!U.P.~. . "

d - 3

l c l . 1 c1~2 c1=3 l

\ . . . . . . . . . . . .

.?~...."

Figure 4. controlling inference

Depending on the values of some parameters, other parameters or control modules are eliminated from consideration. Such a structure allows the pruning of the search tree or the guiding of the search in a way that limits the number of rules that have to be enabled or fired to determine the values of the goal parameters, locl, 1oc2, 1oc3, loc4 and 1oc5.

The development environment selected for Con- figurator, despite the rather ad-hoc nature of the selection, proved to be adequate in delivering the required functionality. Every attempt was made during system design and development to exploit the features of the software environment that contributed to either the efficiency of the system or its effectiveness, in terms of making it more acceptable to users.

Conclusions

It has been suggested that expert systems development can be made a well managed and adequately controlled process, contrary to popular belief. A four-phase life cycle for expert systems has been described which synthesizes elements from both structured develop- ment and prototyping approaches. The operation of the life-cycle has been illustrated through a case study outlining the development process for a product configuration expert system, including the major architectural components of the software. The prob- lems and issues encountered in transferring the system to its clients have been highlighted.

It is anticipated that the commercial development and implementation of expert systems will necessitate a reevaluation of the current project management prac- tices employed. This paper has been directed to that end, with the motivations arising from a need to make the expert system development process more effective and manageable. Future research along these lines includes the investigation of specific tools and techni- ques for each phase, in a spirit similar to structured analysis and design tools.

REFERENCES

1 Enger, N L 'Classical and structured systems life cycle phases and documentation' in Cotterman, W M, Couger, J D, Enger, N L and Harold, F (eds) Systems Analysis and Design: A Foundation for the 19808 Elsevier, the Netherlands (1982) pp 1-24

2 Toellner, J D 'Project management of systems projects' in Cotterman, W M, Couger, J D, Enger, N L and Harold, F (eds) Systems Analysis and Design: A Foundation for the 19808 Elsevier, the Netherlands (1982) pp 91-108

3 Ackoff, R L 'Management misinformation systems' Manage. Sci. Vol 14 No 4 (April 1967) pp B-147- B156

4 Cerveny, R P, Garrity, E J and Sanders, G L. 'The application of prototyping to system devlopment: A rationale and model' J. Manage. Inf'. Syst. Vol 3 No 2 (Fall 1986) pp 52-62

5 Jenkins, A M 'Prototyping: The new paradigm for systems development' MIS Quart. Vol 6 No 3 (September 1982)

6 Alavi, M and Henderson, J "An evolutionary strategy for implementing a decision support sys- tem' Manage. Sci. Vol 17 No 11 (November 1981) pp 1309-1325

7 McDermott, J RI: An expert configurer Report CMU-CS-80-119 Computer Science Department Carnegie-Mellon University, USA, (1980)

8 Hayes-Roth, F, Waterman, D A and Lenat, D B (eds) Building Expert Systems Addison-Wesley, MA, USA (1983)

9 Preran, D S 'Selection of an appropriate domain for an expert system' AI Magazine Vol 6 No 2 pp 26-30

10 Slagle, J R and Wicks, M R 'A method for evaluating candidate expert system applications' AI Magazine Vol 8 (Winter 1988) pp 44-53

11 Bobrow D G and Stefik, M 'Knowledge-based programming' Alvey News Vol 13 (1985) pp13-14

12 Buchanan, B G, Barstow, D, Bechtel, R, Bennet, J, Clancey, W, Kuliwoski, C, Mitchell, T and Water- man, D A 'Constructing an expert system' in Hayes-Roth, F, Waterman, D A and Lenat, D B (eds) Building Expert Systems Addison-Wesley, MA, USA (1983)

t3 Berry, D C 'The problem of implicit knowledge' Expert Systems Vol 4 No 3 (August 1987) pp 144-150

14 Belkin N J, Brooks, H M and Daniels, P J 'Knowledge engineering using discourse analysis' International J. Man-Mach. Stud. Vol 27 (1987) pp 127-144

15 Johnson, P E 'What kind of expert should a system be?' J. Medicine & Phil. Vol 8 (1983) pp 77-97

16 Agarwai R and Tanniru, M, 'Organizational man- agement of expert systems development' Proc. First Int. Conf. AI in Industry and Government Hyder- abad, India (November 1989)

180 Knowledge-Based Systems