14
Expert Systems With Applications, Vol. I, pp. 103-116, 1990 0957-4174/90 $3.00 + .00 Printed in the USA. © 1990 Pergamon Presspie Using Knowledge-Based Systems for Teaching and Performing Knowledge-Based Systems Development ROBERT J. MOCKLER* Abstract m This paper describes the development of a knowledge-based system (KBS) for guiding both technical and non-technical managers in finding, defining, selecting and evaluating a small knowledge-based system development project. The work described here is part of an ongoing research project studying the use of KBS both to teach and to do KBS development. So far, as part of this research project, over the past two years over 200 non-technical and technical full-time business managers have developed some 160 KBS prototypes in conjunction with an MBA course in strategic planning. Based on replies to a survey of this test group, 28% of the KBS developed by survey respondents were reportedly used at work, 2196 led to promotions, pay raises, or new jobs, and 12% led to partic- ipation in other KBS development projects at work. All but two of the survey respondents reported that their work on the KBS development project led to a substantial increase in their job knowledge or performance. The KBS work described here extends research work described by Cullen and Bryman (1988), Slagle and Wick (1988), Cohen and Howe (1988), Dologite & Mockler (1988, 1990), and Mockler 1989. 1. INTRODUCTION THIS PAPERDESCRIBES the structured analysis done in modeling the decision situation involved in finding, defining, selecting, and evaluating a small knowledge- based system development project. The final section of the paper gives a brief description of the prototype knowledge-based system, a concept testing system presently in use, developed on the basis of this struc- tured situation analysis. 2. THE UNDERLYING RESEARCH PROJECT There have been three phases in the research project upon which the knowledge-based system described in this article is based. The first phase involved studying how knowledge-based systems (KBS) and their devel- opment could be used to help nontechnical managers learn general business subjects, such as strategic plan- ning, finance, and marketing. The potential for this was noted by Tompsett (1988) and Dologite (1988). During this phase, several ways were developed to quickly introduce nontechnical managers with tittle or no computer training to KBS technology, including: * Professor Robert J. Mockler is in the Department of Management, Graduate School of Business, St. John's Univexsity, Jamaica, NY 11439. Dr. Mockler founded the Center for Artificial Intelligence Systems at St. John's University. 103 • providing many examples of KBS in a variety of management decision areas; • using expert system development shells that are nonthreatening and rely on English language rule building; • providing simplified manual modeling and analytical tools for structuring management decision situations in computer-compatible ways. Warrnan and Modesitt (1989), Bahill & Farrell (1986), Dologite & Mockler (1988, 1990), Mahler (1986), and Moclder (1989) describe these and similar techniques used in this study and in other studies on related topics. The second phase, using KBS technology to more effectively and quickly help nontechnical managers ac- quire KBS development skills, helped reduce the amount of time which had to be taken from teaching and learning a course's management subject matter to teach KBS development skills. The third phase involved developing and using KBS to help knowledge engineers and KBS project managers do their jobs. This stage has led to the development of a family of KBS designed to help do KBS development. The underlying research project and the KBS devel- oped during these second and third phases are described in the author's forthcoming book (Mockler, 1992). The knowledge-based system prototype described here is one of the early prototype systems developed as part of the third phase of this project. The system assists users (nontechnical business managers working on smaller KBS projects) in selecting and evaluating a

Using knowledge-based systems for teaching and performing knowledge-based systems development

Embed Size (px)

Citation preview

Expert Systems With Applications, Vol. I, pp. 103-116, 1990 0957-4174/90 $3.00 + .00 Printed in the USA. © 1990 Pergamon Press pie

Using Knowledge-Based Systems for Teaching and Performing Knowledge-Based Systems Development

ROBERT J. MOCKLER*

Abstract m This paper describes the development of a knowledge-based system (KBS) for guiding both technical and non-technical managers in finding, defining, selecting and evaluating a small knowledge-based system development project. The work described here is part of an ongoing research project studying the use of KBS both to teach and to do KBS development. So far, as part of this research project, over the past two years over 200 non-technical and technical full-time business managers have developed some 160 KBS prototypes in conjunction with an MBA course in strategic planning. Based on replies to a survey of this test group, 28% of the KBS developed by survey respondents were reportedly used at work, 2196 led to promotions, pay raises, or new jobs, and 12% led to partic- ipation in other KBS development projects at work. All but two of the survey respondents reported that their work on the KBS development project led to a substantial increase in their job knowledge or performance. The KBS work described here extends research work described by Cullen and Bryman (1988), Slagle and Wick (1988), Cohen and Howe (1988), Dologite & Mockler (1988, 1990), and Mockler 1989.

1. INTRODUCTION

THIS PAPER DESCRIBES the structured analysis done in modeling the decision situation involved in finding, defining, selecting, and evaluating a small knowledge- based system development project. The final section of the paper gives a brief description of the prototype knowledge-based system, a concept testing system presently in use, developed on the basis of this struc- tured situation analysis.

2. THE UNDERLYING RESEARCH PROJECT

There have been three phases in the research project upon which the knowledge-based system described in this article is based. The first phase involved studying how knowledge-based systems (KBS) and their devel- opment could be used to help nontechnical managers learn general business subjects, such as strategic plan- ning, finance, and marketing. The potential for this was noted by Tompsett (1988) and Dologite (1988). During this phase, several ways were developed to quickly introduce nontechnical managers with tittle or no computer training to KBS technology, including:

* Professor Robert J. Mockler is in the Department of Management, Graduate School of Business, St. John's Univexsity, Jamaica, NY 11439. Dr. Mockler founded the Center for Artificial Intelligence Systems at St. John's University.

103

• providing many examples of KBS in a variety of management decision areas;

• using expert system development shells that are nonthreatening and rely on English language rule building;

• providing simplified manual modeling and analytical tools for structuring management decision situations in computer-compatible ways. Warrnan and Modesitt (1989), Bahill & Farrell

(1986), Dologite & Mockler (1988, 1990), Mahler (1986), and Moclder (1989) describe these and similar techniques used in this study and in other studies on related topics.

The second phase, using KBS technology to more effectively and quickly help nontechnical managers ac- quire KBS development skills, helped reduce the amount of time which had to be taken from teaching and learning a course's management subject matter to teach KBS development skills.

The third phase involved developing and using KBS to help knowledge engineers and KBS project managers do their jobs. This stage has led to the development of a family of KBS designed to help do KBS development. The underlying research project and the KBS devel- oped during these second and third phases are described in the author's forthcoming book (Mockler, 1992).

The knowledge-based system prototype described here is one of the early prototype systems developed as part of the third phase of this project. The system assists users (nontechnical business managers working on smaller KBS projects) in selecting and evaluating a

104 R. J. Mockler

proposed KBS development project. In addition, it helps those having trouble finding and scoping a proj- ect, a problem frequently encountered by nontechnical managers who are familiar with KBS technology. This later problem has apparently been given little attention in research literature, even though it is a topic of vital interest to those in CIS who wish to expand the scope and development potential of KBS technology.

The system described here, an advanced version of which is now being used, achieves two goals: • It guides technical and nontechnical managers in es-

timating the risks inherent in a proposed KBS de- velopment project;

• It gives an example of a management decision-mak- ing KBS that nontechnical managers working on smaller systems can study and so use to acquire an understanding of how KBS for management deci- sion-making works. The following description may trouble some CIS

technicians. They may become impatient with the lengthy description of the decision situation. They may be anxious to see more space devoted to a description of the system. These readers should note that the sit- uation descriptions given in this article are in fact structured to be very precise situational descriptions of the system.

These readers should also keep in mind that the focus of the research project upon which the system is based is to get managers to both describe their decisions in sufficient detail for KBS development and to struc- ture or model that description in a way that makes transformation to an expert system shell easy. If a de- tailed and computer-compatible structured description of a decision situation can be formulated, it takes very little effort to prototype it on a computer. This point is made by Earnest (1989). When pressed, many CIS technicians will confess that their greatest problem is finding managers who can articulate how they make decisions in a way that facilitates the transformation to computer system. For example, Volkema (1988) de- scribes the difficulties involved in just defining a situ- ation or problem to be studied.

Because of the importance of well-defined decision making expertise, KBS development success depends on expert and user participation in and control of the development effort to a much greater degree than in conventional computer system development. Research on the subject appears to confirm this (Cupello & Mishelevich, 1988; Madni, 1988; Mantei & Teorey, 1988).

The research project upon which this article is based is a search for ways to overcome these problems and increase this participation.

The following discussion of the decision situation and the KBS developed to replicate it covers: • the general situation under study; • the situation to be prototyped;

• documenting the system and putting it onto com- puter;

• further screenings.

3. GENERAL SITUATION UNDER STUDY The general situation under study is knowledge-based system development. The KBS development life cycle is shown in Figure 1. The system described in this article involves the first phase of that life cycle, preliminary screening and planning, in situations involving a man- ager working alone who: • has little or no computer training; • is doing a relatively small system or concept testing

prototype system; • is in a business school program, and/or taking an

executive training seminar, and/or working in busi- ness with a consultant. Before undertaking such a project, an individual

would read through summary articles in an introduc- tory book on knowledge-based systems to get a brief idea of what the area is all about (e.g., Bowerman & Glover, 1988; Gallagher, 1988; Martin & Oxman, 1988; Mockler, 1989; Wolfgram, Dear, & Galbraith, 1987). He or she would also review a number of sample systems. The system described in this article might be one of the systems he or she would review. An indi- vidual might also examine other systems described in the literature (e.g., Agnew, 1988; Bramer, 1988; "Expert Systems," 1988; Humpert & Holley, 1988; "Inanimate Analysts," 1987; Lasher, 1988; Mockler, 1989; Rauch- Hindin, 1985; "Robots are Coming" 1988). The intent here would be to get an idea of what KBS are all about, not to master the subject.

It would also be useful to select the expert system development shell to be used for prototyping early in the study. In this way, any rule structuring and knowl- edge base typing can be done from the outset of the study in a format, and with the notation, appropriate to the shell being used. For information on such shells, see, for example, Gevarter (1987); Citrenbaum, Geiss- man, & Schultz ( 1987); and Finnie (1988). Descriptions of, and tutorials for using, all major PC expert systems shells are given in Mockler (1989). In most situations, the participants would be directed to do the develop- ment on an English language shell, such as M. 1, unless they had a preference for or experience with another shell.

In all the preliminary screening situations described in this article, it is assumed that an initial decision has been made that for some personal, business, or profes- sional reason the project is considered a worthwhile investment of time by the individual involved in the study. It is further assumed that the developers had very little computer background, and so would need detailed explanations of many basic concepts that readers of this journal might find obvious and unnec- essary.

Using Knowledge-Based Systems 105

Project Planning

Selection

Definition

Preliminary Screening

1' I

(refine)

Situation Analysis and Representations

Nnowledge Acquisition

Nnowledge Structure ,odell Representations

Decision , Situation Models/ Representations

I A

I

Situation Reformulation and Transformation

Situation Reformulation

Computer Compatible Decision Situation Formulations

I

(verify) I

System Design

Define System Architecture

and Sol tware i Hardware Requirements

', / ~ [verify) [

System Development

Design User Interfaces

Code

Debug , , ,~

(verify),'

System Testing and

]Implementation

Integration

Acceptance Jlx

(verify)

System Maintenance

Refine

Maintain

Repair

(verify) :

,,

FIGURE 1. KBS development life cycle.

4. THE SITUATION TO BE PROTOTYPED

The situation to be prototyped involves a preliminary evaluation of a KBS project proposal. It also involves any necessary guidance or assistance that an individual manager or student might require in finding, selecting, and defining a project for work or for class.

The discussion in this section covers the following areas: • factors affecting the decision; • recommendations and how they are arrived at.

4.1. Factors Affecting the Decisions

The critical factors affecting decisions in these situations can be grouped into three categories: • appropriateness for KBS technology; • project feasibility; • project usefulness.

The diagram in Figure 2 outlines the key decisions made in these kinds of situations. The following dis- cussion explains this decision situation outline or model.

The study of the above factors in situations involving people inexperienced in either KBS development or

management decision making may also include pro- viding help for those who are: • having trouble finding a suitable decision, problem,

or task for KBS development, and • having trouble defining and shaping an interesting

potential decision, problem, or task. A good starting point in understanding KBS devel-

opment is to examine and run consultations with ex- isting systems. Examining these sample systems will give the individual insight into the applications of KBS technology. (e.g., Agnew, 1988; Bramer, 1988; "Expert Systems," 1988; Humpert & Holley, 1988; "Inanimate Analysts," 1987; Lasher, 1988; MocMer, 1989; Rauch- Hindin, 1985; "Robots are Coming," 1988). It will also give him or her an idea of the structure, type of rea- soning, and effort involved in building a KBS.

For some, such a study will suggest ideas for KBS development projects. However, often individual stu- dents or managers may need further guidance in finding an area for a KBS development project. If this is the case, in order to assist them with this decision it is useful to first know their amount and level of work experience and schooling. For example, they might be: • a full-time undergraduate students with little or no

work experience;

106 R. J. MocMer

Guide for Selecting & Finding

Guide for Defining & Shaping the Scope

Student :-->-: ,.Constraints .: )

I .... a

: Manager 1-'>'1 ( Constraints ) :

: General :-->-: :_Constraints ..:

) ....... ( ............... ( ............. ( ......... )

I : ) : ) Task ) 1-->--1 : Selection & )

)--->--: Oefinition ( ..... > ........... > ................ > Study more sample I ) ) no, task not selected & defined systems a~ explore : I further sources for : : yes (Continue: task system ideas.

I">": : selected & defined) : ...... : ) : Quantitative I

i and : Procedural

Heuristic and

Symbolic

)--)o)

) )'>-I Appropriate- ( ' ', : ~ss for KBS : - - - ) - :

: Technology : ','>", I

--)-)

Expertise :-->-', Availability', :

.', : I'>'l p

,' Project ', .... > ) Feasibility )

">'1 .... I ) Individual I System l-->- Developer's : .Constraints I

Proposed System's : Feasibility :-->-:

Level of Personal Value

I - - ) ~ I

:->-: u, ' ,Project

Usefulness ',.>-', ..

Practical ) Applications ',-->-',

I - - - ) -

: Preliminary I Screening:

-->-- : Small : Individual I Project

Proceed Reject Modify

FIGURE 2. Decision situation under study preliminary screening r o l l individual project proposal decision domain program.

• full- or part-t ime graduate students with some man- agerial experience;

• people with some work experience at the managerial level but with little experience in KBS development or formal problem definition. To help guide individuals in finding and selecting a

KBS project proposal that is feasible, is appropriate for KBS technology, and has a high level of usefulness (personal value and/or practical applications), individ- uals would be directed to consider the following as a possible source of a KBS development project:

• a decision or task they presently perform either at school or at work;

• hobbies or interests that they may have a very strong interest in;

• a decision or task that their boss or coworker makes or performs that they are interested in learning more about and for which they have or can get access to the expertise involved;

• a specific area in which they might want to start a new business;

• any other job-related decision or task that they are

Using Knowledge-Based Systems 107

Example A: A "'PC Expert System Shell Selection System" developed by an undergraduate student for part of a software rev iov course.

The general area under study was software selection. This involves evaluating the capabilities of different types of software and matching them against user needs and abilities, technical computer capabilities, and decision situation needs to select the best software package. Software may be selected from the many different word processing, expert system shell, spreadsheet, desk top publishing, graphics, database, and integrated packages available.

The area selected for further study was selection of a PC expert system shell for use in a class project. The scope of the initial prototype system to be developed was narrowed further to the five shells available at the schools computer lab.

Example B: A "Horse Race Betting" system, which was de- veloped based on a manager's hobby.

The general area under study was horse racing, one of the only sporting events in the United States where money can be wagered legally. This money-making aspect combined with the expert decision making (handicapping) that goes into placing a wager makes horse race betting a good candidate for the appli- cation of KBS technology.

There are different types of horse races, for example, thor- oughbred and harness racing. The scope of the prototype system to be developed was narrowed to handicapping thoroughbred horse races run on a fast dirt track and limited to claiming races.

Example C: An "Auto Stock Analyst System" developed by a graduate student who wanted to acquire a better understanding of the area.

The general area under study was financial planning and analysis. Financial planning and analysis encompasses a very broad range of areas including personal investment planning, cash management, merger and acquisition analysis, and individ- ual company analysis. Individual company analysis was chosen for the general area under study from these areas.

The scope of the prototype system to be developed was nar- rowed to regular and periodic fundamental analysis of the com- mon stock of the three major auto companies. The scope was narrowed so that the breadth covered by the system was of man- ageable size and so that the system could cover the chosen area in sufficient depth.

Example D: A "'Franchise Selection" system, which was de- veloped by a consultant with considerable work experience in the area under study.

The general area under study was entrepreneur- ial new venture planning. This area covers such deci- sions as:

• whether or not to be an entrepreneur,

• whether to go into business alone or with partners;

• choosing the type of venture to undertake;

• whether or not to use franchising;

• whether o r not to accept a specific new venture deal offered. Of all the possible entrepreneurial decision areas, franchise

selection was chosen for further study. Franchise selection de- cisions are frequently faced by individual entrepreneurs, both

because of their lack of capital and because of their unfamiliarity with the particular business involved.

The focus of the study was further limited to the fast food and specialty food areas. Of the many possible retail ventures considered, fast food and specialty food stores are recognized as strong opportunity areas, both because of population demo- graphics (increasing numbers of working mothers and thus de- pendence on convenience foods, an increase in working teenagers and young, affluent, childless couples, geographic population shifts, and shifts in shopping and eating habits) and local con- ditions (large groups of these people are concentrated in selected areas).

The situation to be prototyped assumed that the individual involved had already made the decision to be an entrepreneur, and to go into business on his or her own.

The prototype system covers the critical knowledge areas ex- amined in making these decisions. They are: (a) the general and local business prospects, including opportunities, success factors, and general market structure; (b) the individual's resources and capabilities to meet success criteria; and (c) the franchisor's of° feting.

Example E." A "Commercial Loan Approval" system, which was developed by two loan officers at a large metropolitan bank,

The general area under study was financial planning and analysis. Many areas of financial planning lend themselves to KBS development, including personal investment planning, capital investment planning, cash management, merger and ac- quisition analysis, individual company analysis, and commercial and personal loan application analysis.

The business or commercial loan application analysis area was selected for prototype development for several reasons in- cluding:

• There are recognized experts in the field;

• Expert decision skills are needed to do the job:

• It requires informed judgement;

• The task is well understood;

• The decisions have a high payoff and practical value;

• The system developer was familiar with the area. Several types of companies and loans within the commercial

credit analysis process were identified for possible prototype de- velopment including:

• loans to new businesses, under 3 years old, with no record of past performance;

• loans to existing businesses;

• loans of varying amounts. The scope of the system was narrowed to commercial loan

requests of between $250,000 and $2.5 million from a business in existence for at least 3 years and not in violation of a bank's policies regarding target markets.

The focus of the study was also further limited to concentra- tion on nonfinancial considerations, such as the future prospects of the company applying for the loan, the character of its man- agement, and a fit of a proposed loan with the banks strategic guidelines, since they involve nonquantitative, more subjective and more strategic factors, and thus are more appropriate for KBS developmenL

FIGURE 3. System examples based on individual's situation and preferences.

interested in and would like to unders tand bet ter

a n d / o r be able to per form just to satisfy their own

curiosi ty or mee t their own goals.

T h e key here is to start with a p romis ing area in

which there is a very high level o f in te res t and potent ial

long- term benefits to the individual involved.

Based upon the ind iv idual ' s s i tuat ion and prefer-

ences, he or she would be shown further appropr ia te

examples o f systems previously developed by people

in s imilar s i tuat ions in order to help s t imulate his or

her thinking. For example , an undergraduate s tudent

might be shown examples A and B in Figure 3, graduate

s tudents might be shown examples B, C and D, while

working managers might be shown sample systems

similar to examples C, D, and E.

Once a general decision, problem, or task area has

108 R. J. Mockler

been selected for KBS development, it is usually nec- essary to define it more precisely. This phase is often referred to as refining or defining the scope of the proj- ect. The examples in Figure 3 include brief examples of the initial phases of refining and defining. This phase sometimes requires broadening the scope of the project and sometimes narrowing it.

In order to determine that the breadth and depth (scope) of a KBS project proposal is not too over- whelming, the following steps can be helpful: • Write a very detailed scenario (story) of how the task

or decision under study is carried out in a specific situation, including such situation specifics as time, place, people involved, and other actual events which would occur on a given day in a real situation;

• Identify the recommendations which can be made in the kind of task situations under study, limiting the number to no more than four or five basic ones;

• Specify the three or four critical factors which are considered in making these recommendations and how these affect which recommendation is made;

• List l0 or 12 specific questions which need answering in order to obtain information about the factors needed to make a recommendation;

• If dealing with a diagnostic situation, reduce it to a technical manual outline involving alternative search paths;

• Reexamine samples of existing systems. To help guide an individual in doing these, examples

would be given of how they were done for a particular decision, task, or problem and how a KBS was devel- oped from this process. An example of some of the steps in this process for the "Franchise Selection" is shown in Figure 4.

It is also possible for the scope of the decision, task, or problem area to be too narrow. Several questions are explored in determining if a KBS project proposal is (or has become) too narrow. These questions include: • Does the situation involve just common sense, for

example, whether or not to use an umbrella on a rainy day, or whether or not to bring your passport if you are travelling to Europe?;

• Are the final recommendations simply yes or no?; • Does the reasoning involve mostly a procedural pro-

cess that can be reduced to a single sheet of instruc- tions or a check list of criteria which dictate a specific solution? if the answer to these questions is "yes," then the

project proposal (situation definition) is probably too narrow and needs broadening through reexamining the situation and studying existing sample systems.

A commonly encountered narrow selection defini- tion involves evaluating only one option: for example, the decision whether or not to purchase a specific expert system shell, such as VP-Expert. Such a decision is too narrow mainly because of its limited applicability and its simplicity. Such a system can be broadened very

simply by defining it as a decision involving selecting the expert system shell (from the major ones available on the market) which best meets the needs of the in- dividual (who could be anyone in any type of business) considering making the purchase.

Only after an individual has found and selected an area, task, or decision for KBS development and ad- equately defined its scope is it worthwhile to examine the critical factors affecting the evaluation of the pro- posed KBS project. These critical factors can be grouped into three categories: • appropriateness for KBS technology; • project feasibility; • project usefulness.

4.1.1. Appropriateness for KBS Technology. Deter- mining a project's appropriateness for KBS technology requires looking at the reasoning processes involved to see if they are: • quantitative and procedural in nature, or • heuristic and symbolic in nature.

Reasoning processes are quantitative and procedural if they can be reduced to a mathematical formula. For example, if a decision relies mainly on mathematical computations, such as when to reorder a particular product for inventory or when and how much to bill a customer, the reasoning or decision making involved is quantitative. Decision situations which are largely quantitative and procedural are usually best suited for conventional computer systems.

For a project proposal to be appropriate for KBS development, the reasoning involved in the task or de- cision should be heuristic and symbolic, that is, knowl- edge intensive in nature, not process intensive or quantitative. This is because heuristic and symbolic reasoning process are suitable to the reasoning process patterns built into KBS system development shells and languages. Knowledge intensive refers to information or knowledge of how different factors interrelate to ar- rive at some conclusion. An example can be seen in Figure 4, Section 2.

Heuristics are rules of thumb that experts use to help them solve problems. For example, an expert baseball manager might know that when a particular pitcher's fastball rises more than usual the pitcher is getting tired. This is an example of just one of the many heuristics that a manager may use when evaluating players throughout the league. Heuristic knowledge is judgmental in nature. The rules of thumb that it is based on do not always guarantee a single best solution. The if-then rules described later in this article are an- other example of heuristic knowledge.

Symbolic reasoning involves manipulating symbols that represent concepts, such as a syllogism. Symbolic reasoning is based on the application of strategies and heuristics to manipulate symbols representing problem concepts. Syllogisms are examples of symbolic reason-

Using Knowledge-Based Systems 109

A Franchise Selection System

Note. This system is an early prototype of a KBS being de- veloped for a company with 100 locations which sells franchising advisory services.

To help determine.the adequacy of the scope of your KBS project proposal you should: I. Identify the recommendations which can be made in the kinds

of task situations under study, limiting your answer to no more than four or five basic ones. Typical recommendations made when evaluating franchise

offerings include:

• Superior--Actively pursue the offering;

• Very good--Pursue the offering, but commit to it only after further analyses and evaluations are completed of such factors as local business prospects, and especially the competition;

• Fa i r - - l f the local business prospects are weak, examine a sim- ilar proposal in another location: if the franchise offering is the weak factor, look for another offering with a similar product and location, but through a different franchisor,

• Poor - -Abandon the proposal. 2. Specify the three or four critical factors which are considered

in making these recommendations and how these affect which recommendation is made. The critical factors considered when evaluating franchise of-

ferings include:

• the business prospects, both general and local;

• individual resources and capabilities, such as personality, fi- nancial position, and work experience and skills;

• the franchise contract covering franchisor support, the rea- sonableness of the deal, and the franchisor character. A franchise offering would be considered superior if both the

business prospects and the franchise contract were favorable and the individual's resources were favorable or average.

A franchise offering would be considered very good if both the business prospects and the individual's resources were fa- vorable and the franchise contract was only average, or, if the business prospects were average and both the franchise contract and the individual's ?esources are favorable.

A franchise offering would be considered fair if both the busi- ness prospects and the individual's resources were average and the franchise contract was average or favorable.

A franchise offering would be considered poor if any of the critical factors were considered unfavorable. 3. List ten or twelve specific questions which need answering in

order to obtain information about the factors needed to make a recommendation. Some of the questions asked when evaluating franchise of-

ferings include:

For Business Prospects: "After examining demographic characteristics such as age, income,

and size of the target market, what is your estimate of the potential growth in the market in general?" For the Individual's resources and capabilities:

"What amount of money are you able to borrow?" For the Franchise Offering:

"What has been the average failure rate of former franchisees?" "Has the general evaluation of the franchisor by former and cur-

rent franchisees been favorable?"

4. Write a detailed scenario of how the task or decision under study is carried out, including such situation specifics as time, place, people involved, and other actual events which would occur on a given day in a real situation. The scenario will probably not be complete after a first draft but will grow as you investigate how the situation and decision work.

Robert London, age 42, is a single male interested in a retail fast food franchise. He has worked in investment banking for the last I0 years and prior to that, worked in a branch of a sub- urban bank. He holds a bachelor's and master's degree in business and lives in a rented apartment in a middle-class suburban area near a major city. Rob engaged a consultant (expert) in the field to assist him in deciding whether or not to purchase a Burger King franchise near his home.

The consultant first collected background information. In terms of general business prospects, the product was examined for growth potential and staying power. Since fast food products are common ones, ample demographic and market studies were available that showed the overall prospects were favorable. How- ever, analysis of the local area revealed several weak points. The consultant found that the location Rob was looking at was already saturated with competition, including McDonald's, a Wendy's, and a Roy Rogers, all within a mile radius of each other. In addition, the franchise would be located near an exit ramp to a major highway, but would be the last eating place that travelers would reach coming off the highway.

Although the franchise's target market matched the demo- graphic profile of the local area, the market area was not expected to grow significantly in the future. The consultant talked with other small business owners in the area and found that general indicators called for only modest overall growth. Although the other franchises in the area seemed busy, the consultant's research indicated that competitors' sales had been fairly flat over the prior 3 years.

The consultant interviewed Rob to see if he was cut out to be an entrepreneur. Based on experiences Rob described from his past, he seemed capable of taking charge, organizing and handling multiple jobs, and dealing effectively with people. He had demonstrated determination and self-reliance to a high de- gree. Rob generally seemed competent enough to run his own business but lacked the willingness to take big risks.

Next, the consultant examined the franchise offering. Burger King provides substantial initial ongoing assistance at no addi- tional cost in the areas of operations, equipment maintenance, and training. However, they have a relatively high annual fran- chise payment, provide no assistance with financing, and subject franchisees to a wide variety of controls. Burger King, in business since 1954, has maintained excellent relations with its franchisees and business contacts. The company is predicted to increase its 3,000 units substantially in the next decade. Although a very reputable franchisor, Burger King's contract gives no guarantee of exclusivity of territory, and contains some tie-in purchasing agreements with suppliers.

The consultant summarized his evaluation as follows:

• Business prospects--The general prospects were favorable. However, because of a stagnating local market and poor lo- cation, the local factors were considered unfavorable. The business prospects were, therefore, rated unfavorable overall.

• Individual resources and capabilities--Because Rob had fa- vorable personal, financial, and business skills, the overall rat- ing was favorable.

• Franchisor offering--Franchisor support was very favorable. However, due to the lack of financial assistance and only fair fee schedule, the reasonableness of the deal was rated average. Although Burger King's reputation is excellent, lack of exclu- sivity of territory and tie-in agreements yielded an average rating for the contract. The overall rating for the franchise offering was average. Based on this analysis and evaluation, the consultant's overall

rating of the venture was only fair. Knowing that the local area was not well suited to the particular franchise because of heavy competition, and that Rob would need assistance with financing, the expert recommended looking for a more generously financed offering, with a similar product but in a better location.

FIGURE 4. Steps to help define project scope.

110 R. J. Mockler

ing. Syllogisms are arguments consisting of at least three propositions. For example: • The students in BA 224 are studying business; • Carol is a student in BA 224; • Therefore, Carol is studying business.

The first two propositions are called premises and have one term (symbol) in common (students in BA 224) which furnishes a logical connection between the two other terms (studying business and Carol) which are then linked in the third proposition or conclusion.

Decision situations involving heuristics and sym- bolic reasoning are appropriate for KBS development.

Questions such as the following are asked to find a project's appropriateness for KBS technology. The an- swers to the first two questions should be answered "yes" or "to a great degree," while the last two should be answered "no" or "not to any great degree": • Does the reasoning or task involved require symbolic

manipulation?; • Does the reasoning or task involved require using

rules of thumb or heuristics?; • Does the decision involve mostly giving yes or no

answers to questions?; • Is the decision or task quantitative enough that you

could make a version of it work on Lotus 1-2-3 or some other spreadsheet system?

4.1.2. Project Feasibility. A project's feasibility de- pends on three major factors: • expertise availability; • the proposed system's feasibility; • the individual system developer's constraints._

A project's feasibility depends first upon the exper- tise availability. Expertise availability refers to the sources of expertise that can be used to develop the system. This may include the expert or experts who can be used as sources of knowledge, as well as books, manuals, and any other expertise or knowledge sources.

Determining the expert/expertise availability in- volves answering such questions as: • Can the reasoning process be identified and defined?; • Do recognized experts or sources of expertise exist?; • Can experts do the task better than amateurs and

can their skills be taught to others?; • Can the available experts articulate the general

methods that they use to reach conclusions and make decisions?;

• Do you have or can you get adequate sources of the knowledge and/or expertise to develop the KBS? Unless the answers to all o f these questions are pos-

itive, sufficient expertise is not available for the project and it is not feasible. If all of these questions are an- swered satisfactorily, the evaluation of the proposed KBS would continue.

Determining the proposed system's feasibility re- quires that individuals imagine how their proposed system would look on computer. A system is feasible

if the scope of the decision to be prototyped is within the capabilities of existing KBS technology. This in- volves examining and consulting sample systems and then answering the following questions about the de- cision situation under study and the system proposed to replicate it: • Approximately how many questions need to be an-

swered about the area involved when making/per- forming the decision/task?;

• How long do you estimate that it takes an expert in the area to make the decision, solve the problem, or do the task under study?;

• How many rules would you estimate will be in the final prototype system?;

• How many major factors influencing the final de- cision do you estimate there are?;

• How many factors or rule sets do you estimate there will be in the system?;

• Will the proposed system require that information he gathered from a spreadsheet or database?;

• How many recommendations do you estimate there will be in the system? The above phases should be repeated until a fairly

detailed picture is formulated of how the decision, task, or problem situation is structured. Figure 2 is an ex- ample of such a structured model of a decision situa- tion.

A project's feasibility also depends upon the indi- vidual system developer's constraints. Individual sys- tem developer constraints can vary considerably, de- pending on the situation. Typical situations include: • systems developed as part of an undergraduate or

graduate course; • systems developed covering the entire course; • systems developed by full-time managers for use at

work; • systems developed as part of a business seminar.

The different constraints arising from these situa- tions can be broken down into three categories: • student constraints, if the developer is a student; • manager constraints, if the developer is a mana-

ger; and • general constraints, that apply to all types of situa-

tions. Student constraints cover such questions as:

• the number of other courses taken; • the year of school these courses are taken in; • whether they are undergraduate or graduate students; • their other obligations, such as work, family, and

special circumstances. Manager constraints cover such areas as:

• job demands; • their other obligations, such as family, school, or

other special eireumstanees. General constraints cover such areas as:

• the amount of time and energy that can be devoted to the project;

Using Knowledge-Based Systems 111

• the individuals' knowledge of the area to be proto- typed;

• their background in computers; • their general competency in the cognitive skills area.

For managers in a training seminar, in addition to the information gathered from the above questions, the length of the program would be identified, so that t ime constraints could be better evaluated.

The level of difficulty of the proposed KBS would be proportionately greater with each level of situation complexity, from an undergraduate course, to a sem- inar with experienced executives or a graduate class in KBS for nontechnical managers, to a manager working on a relatively complex system to support his or her job at work.

Assuming the expertise is available, these individual system developer constraints are matched against the proposed system's feasibility to determine the overall project feasibility.

4.1.3. Project Usefulness. Determining a project's use- fulness involves examining such factors as: • the practical applications of the system; • its level of personal value to the individual developer.

Practical applications of a system may include help- ing people make decisions in their job. A system may contain personal value to the developer if the individual is interested in learning more about the area involved or if it helps his or her career in general.

In measuring the practical applications of the sys- tem, an individual answers such questions as: • Is the expertise being replicated in the proposed KBS

needed often and on a regular basis at work, for ex- ample, more than once a week on average?;

• To what extent can your proposed KBS be used to help repair and service products?;

• To what extent can your proposed KBS be used to give sales assistance to customers?;

• To what extent can your proposed KBS be used to help train or retrain employees?;

• Does your proposed KBS have some other practical use at work?;

• Does your proposed KBS have some practical use in a possible new venture you are considering?;

• Is the main purpose of the system to test KBS tech- nology? In measuring the personal value of a decision, task,

or area selected for KBS development, an individual answers such questions as: • Did you choose to develop a KBS in this particular

area or was it assigned to you?; • How would you describe the extent to which your

KBS will help you at school, in your job or else- where?;

• Would you like to learn how to perform the task or make the decision involved in your KBS for your own personal satisfaction?;

• Does your proposed KBS deal with your hobbies or interests?;

• How would you describe the chances of your devel- oping this system helping you get a new job, a pro- motion, a raise, or job security?;

• Will developing this system impress your boss?; • How would you describe the feeling or sense of ac-

complishment that you expect to get from developing this system?;

• Are you being paid to develop this system? The KBS project proposal's usefulness is based upon

the answers given to the above sets of questions. For example, if the system will have a practical application at work, such as training employees who work for the KBS developer, the project's usefulness is significant. If the individual developer is assigned to develop a par- ticular system as a class project or its main purpose is to test KBS technology at the company where the in- dividual works, the project's usefulness would be lim- ited.

4.2. Recommendations and How They Are Arrived at

In situations involving the evaluation or preliminary screening of a KBS project proposal of an individual manager or student with little or no computer training, doing a relatively small concept testing prototype sys- tem, three basic recommendations can be made: • Proceed with the proposed KBS project as it is; • Do not proceed at all with the proposed KBS proj-

ect--reject it; • Modify some aspect of the proposed KBS project to

increase its chances of being successfully developed and used, and proceed only if you can make the required modifications. One would proceed with a small individual KBS

project as proposed without any modifications if: • the project feasibility is acceptable, that is, expertise

is available and the amount of time the individual has to work on the proposed project is sufficient to handle a project of its scope and the scope is suffi- ciently large;

• the proposed project is significantly or moderately appropriate for KBS technology;

• the proposed system is significantly or moderately useful. A small individual KBS project would be rejected

outright if: • expertise is not available or, given the scope of the

project, the amount of time the individual has to work on it is insufficient, and the scope cannot be narrowed further or more time cannot be made available; or

• the project is not appropriate for KBS technol- ogy; or

• its usefulness is very limited. Under certain circumstances one would proceed

112 R. J. Mockler

with a small KBS project proposal only if modifications could be made. For example: • If an individual has very little time available, he or

she should narrow the scope of the proposed project; • If the project's scope is large, more time should be

made available or the scope should be narrowed. Under other circumstances, an individual may want

to make other kinds of modifications to the project proposal. For example:

• If the individual has lots of time available he or she may want to increase the scope of the project and develop a larger system;

• If the area of the KBS project proposal has a high degree of personal value, then the individual may want to develop a more complex system and devote more time to it. These modifications would only be suggested if:

• adequate expertise is available;

Guide for : Finding & : ~ ', Task : Study more sample

I I I " t Selecting ,-->--itscr',,~ Selectzon & , no: task not selected & defined systems and explore ', I!-3/,'~ Definition ', ................. > .................. > further sources for

C, MC ',->~/" ',_(see Fi~ 6) ', no: task too narrowly defined system ideas. + t

Guide for ', ', yes (Continue: task selected & defined Defining & ,->, .................................... >--- Shaping the : .Scope ', Quantitative :

D and ',-- > ~, Procedural ', ', \ i Appropriate- ',

,' t RS ~t I' ness for KBS ,'-- ) S,M,L ii-3 /~, Technology

Heuristic , ~ S,M,L and I-->

Symbolic ', ',S,M,L

Key:

C : area-chosen MC : area-not-chosen D : done S : significant M : moderate L : limited Y : yes N : no A : acceptable MDF : modify R : reject Sh : shown NR : too narrow

Individual System Developer's Constraints 4 leve!s

[

Expertise : Availability ',

Project ' ' Feasibility

i!'15/ (see FiqT)

i-'>!/ A,MDF,R

- > ~ '

Proposed System's Feasibility

Level of Personal Value

S,M,L

Practical Applications

5 levels

I . . I i )I

"'>:~N~ : Project :R6 "~ Usefulness :--> : I - 4 / : , " , / : , . (see fiq 6-E):

--> ~ / " S,M,L

~ Preliminary I I

,' ,' Screening: -->' ' Small

e . i :l-l)/: Individual "~//i' Project

Proposal Proceed Reject Modify

S,M,L

FIGURE 5. Project proposal evaluator system dependency diagram: Overview (initial Prototype).

Using Knowledge-Based Systems 113

• the proposed project is significantly or moderately appropriate for K B S technology;

• the proposed system is significantly or moderately useful.

5. DOCUMENTING THE PROTOTYPE SYSTEM AND pLrrI 'ING IT

IN THE COMPUTER

The following discussion covers: • System Proposal; • Description of the prototype system; • Dependency diagrams; • Designing and constructing the knowledge base.

5.1. System Proposal

The objective of the project is to develop a KBS that will assist a person in finding, selecting, defining, and evaluating an area, decision, or task for potential KBS development. Typical users include graduate and ad- vanced undergraduate students, as well as business managers inexperienced in KBS development.

The system was developed by educators, managers, and CIS technicians experienced in the process of as- sisting people with such decisions. Published sources of expertise were also used. The system would have two major benefits: It would enable inexperienced de- velopers to work more independently, quickly, and ef-

?&ask-~n-mind ?text-~ ?developer-type ?XES.SAGE-CAT. ?H~SAG[-EX-SYS ?tLsk-in-wind2 ?see-examoles-anyway ?message-end-here

?TOO-NARROW-TEXT > ~ ?T~LO-NARROW-EXAMPL >' ?cg!eon-sense >:1-2~ : ?l:~age-instruct > ~ /

) ): ~ : Guide for : )!R2 ~ Finding & : >:l-16/I Selecting : . . . . >: >: / : , : > : / C,NC > ~ /

Y,N Too Narrow :-:

f I

?write-scenario > 0 , ! I ?EX~HPLES OF )IR~(2)~ Scenario , ,>,'~ I : Task

t..l :~-4// : (I i 2) , >: \ Selection & ~ / : \ : l - ~ / : Definition

?developer-type )I \ I Guide for : / I I . . . f , ' / / ?w~ssaqe-a ' . >!N~(1)~ Oefining & , > > Y,N,NR

?helD-define- >II-3 ~ Shaping the I ~,/ ~ ' ~ : : /',.scope . . . . . :

I . I ?]ist-recmendatJons> List ~ "')i / O ?EX_AHPLES OF )!R3(2)~, Rec (! & 2) , : /

: , y ° ?se.e-samples ., - > > ; ' /

?list-quest > l ?group-questions.. >~2)'~ List ,_,' ' ?EXAMPLES OF >',9~O//l_Quest (I & 2)I

O Key:

, , ~ C : area-chosen ?specify-factors ) NC : area-not-chosen

I ?EXAMPLES OF >~2)~, , Specify ~_, D : done ,~SJl_Fac (I & 2)., S : significant

D M : moderate L : lilited Y : yes N : no A : acceptable NDF : modify R : reject $h : shown NR : too narrow

FIGURE 6. Project proposal evaluator system dependency diagram: Task election and definition (Ini~al Pro~pe).

114 R. J. Mockler

ficiently; it would reduce the amount of course time needed for KBS development for those using it as part of a management seminar or school course.

5.2. Description of the System

5.2.1. System Overview and Objective. The prototype system being developed during the first part of the project is designed to help users evaluate a proposed KBS project. It also assists in finding, selecting, and defining an area for KBS development if the user needs such assistance. The system uses if-then rules and backward chaining to guide the user and reach rec- ommendations.

5.2.2. Recommendations to be Made by the System. The recommendations made by the system include: • Look at more sample systems. This is made to people

who still have not found, selected, and defined a de- cision for KBS development;

• Proceed with the proposed KBS project as it is; • Proceed with the proposed KBS project with the op-

tion of increasing the scope; • Do not proceed at all with the proposed KBS proj-

ect~reject it; • Modify the proposed KBS project by either narrow-

ing its scope or committing more time to it: • Modify the proposed KBS project by increasing its

scope and committing more time to it; • Modify the proposed KBS project by increasing its

scope;

• Modify the proposed KBS project by committing more time to it.

5.2.3. Nature of the User Interface, The typical user dialogue covers five major areas: * Guide for finding and selecting~if assistance is

needed in this area, it is based on the type of devel- oper, for example, student, graduate student, or manager, with different examples shown to different t ypes of people;

• Guide for defining and shaping~if assistance is needed in this area, it is also based on the type of developer, with different examples shown to different types of people.

• Appropriateness for KBS technology--this infor- mation is obtained from questions about the quan- titative and procedural reasoning involved in the decision, as well as the heuristic and symbolic rea- soning;

• Project feasibility--this information is based on questions about expertise availability, the proposed system's feasibility, as well as the individual's situ- ation and individual developer constraints;

• Project Usefulness--this information is based on questions about practical applications of the system as well as its level of personal value to the developer.

5.3. Dependency Diagrams

Figures 5, 6, and 7 show the overall dependency dia- gram and dependency diagrams for 2 segments of the

?dpfinabl~ ?rec-exeerts-ex~st ?txperts-~etter ?pr1~culate-me~hQd ?p;cess-sources-exDertise ?wp-dev-sit ?tra~n-sem-t

?;~urse-load )' ' ?school-year >11-4~,

I i ?@liuations >~/ ',

?job-demends > ?m-obliqations )

I . e

?comouter-bkqd ?ind-knowledge ?s-a-t ?time

?sys-dev-sit ?hum-questions ?decision-time ?num-rulep ?info-~p-~heet ?num-recs ?rule-sets

)IR7-2 ~ Expertise Y,N ):I-3/" : ~vailability

' i \ >' ' :R4 '~ Pro~ect

Student : :lq5/I, Feasibility l.. Constraints , )'~x I *- t p

i i i ' ' i . . iIi , I \ , Indlv~dual , > A,MOF,R / .I levels ',R8 \ ', System ', ',/

,'I-B ~/Developer's ', -) I / Hanager ',-->I //:_Constraints ', Constraints ', ', / 4 levels Key: 4 levels /

- > ~ /

> General i-: ):1-4/~, Constraints., > / " 3 levels

\ . . . . . : .

) :RT~, ', System's ', >:l-lO'X~ Feasibility ',

>', / S levels

>'b J > /

C : area-chosen N¢ : area-not-chosen 0 : done S : significant M : moderate l : limited Y : yes H : no A : acceptable HDF : modify R : reject Sh : shown HR : too narrow

FIGURE 7. Project proposal evaiuator system dependency diagram: Project feasibility (initial Prototype).

Using Knowledge-Based Systems 115

Rule # 13- 1 2 3 4

if course-load > 5 .5 <5 * if school-year F/Sp J /Sp J/Sr * if obligations M/S M/L M/L *

then st-constraints = level-1 X level-2 X level-3

S = significant M = moderate L = l imited F = freshman Sp = sophomore J = junior / = or * = any answer

X X

Sr = senior

FIGURE 8. Project proposal evaluator system decision chart: Student constraints (Initial Prototype).

KBS project proposal evaluation KBS. The diagrams present a summary outline of all the questions, rules, knowledge segments and their interrelationships, val- ues, and recommendations in the system.

5.4. Decision Charts

Figure 8 shows a sample of a decision chart for the prototype system developed.

5.5. Designing and Constructing the Knowledge Base

Rules, questions, and examples to be shown to tl~e user were developed based on the situation study. They were largely based on the developers' experiences in helping different kinds of people make selection decisions and helping them define and structure the area that they selected.

A segment of the prototype system's knowledge base is shown in Figure 9. The expert system shell used is M. 1. It was chosen because it allows rule writing in plain English, has the capability of handling a system of this size, and has a reasonably efficient and friendly user interface. The "if-then" rules were written to reflect the relationships shown in the dependency diagram and match those specified in the decision charts.

6. FURTHER SCREENINGS

The preliminary decision situation definition and sys- tem evaluation studies described in this paper are only one of several that have been and are being developed as part of this research project to help do KBS de- velopment. For example, systems have been devel- oped for: • estimating the risks inherent in a proposed KBS de-

velopment project; • assigning knowledge engineers to projects; • more formal feasibility studies of proposed KBS de-

velopment projects; • selecting development and delivery shells and hard-

ware; • selecting knowledge acquisition and representation

techniques for specific KBS development situations.

These and other similar KBS development tasks, and KBS developed to help do them, are described in several of the works listed in the following reference

/ * Student Developer Constraints * /

rule-13-1: if course-load = A and

A > 5 a n d school-year = freshman or school-year = sophomore and obligations = moderate or obl igations = significant

then st-constraints = 1.

rule-13-2: if course-load = A and

A = 5 and school-year = junior or school-year = sophomore and obligations = moderate or obligations = limited

then st-constraints = 2.

rule-13-3: if course-load = A and

A < 5 and school-year = junior or school-year = senior and obligations = moderate or obl igations = limited

then st-constraints = 3.

rule-13-4: if course-load = A and

school-year = B and obligations = C

then st-constraints = 2.

/ * Student Quest ions */

question (course-load) = [nl, nl, nl, nl, nl, nl, nl, nl, nl, nl, hi, nl,'

How many courses are you taking this semester?

Type in a number such as " 5 " and press "ENTER"

', nl, nl, hi, nl, nl, nl, nl].

legaivais (course-load) = number.

question (school-year) = [nl, nl, nl, nl, nl, nl, nl, nl, nl, nl, nl, nl,'

What year of school are you in?

', nl, nl, nl, nl, nl, nl, nl, hi, nl].

legaivais (school-year) = [freshman, sophomore, junior, senior].

question (obligations) = [nl, nl, nl, nl, nl, nl, nl, nl, nl, nl, nl, nl,'

How would you describe demands placed on your t ime by obligations such as work, your family and friends, or other circumstances?

', nl, nl, nl, nl, nl, nl, nl, nl, nl].

legaivals (obligations) = [significant, moderate, l imited].

RGURE 9. Project proposal evaluator system knowledge base sample: Rules & questions from student constraints segment

(InWal Prototype).

116 R. J. Mockler

sect ion wh ich d e s c f i b e t h e research p r ~ e c t ( M o c k l e r , 1990a, 1990b, 1992).

AeknowledgementPSpecial thanks to John Merseburg for his sub- stantial contributions to all the systems involved in our research project.

REFERENCES

Agnew, J. (1988, September 25). Artificial intelligence with a mar- keting use. Marketing News, pp. 3, 6.

Bahill, A.T., & FarteR, W.R. (1986). Teaching an introductory course in expert systems. 1EEE Expert, Winter, 59-63.

Bowerman, R.G., & Glover, D.E. (1988). Putting expert systems into practice. New York: Van Nostrand Reinhold.

Bramer, M. (1988). Expert systems in business: A British perspective. Expert Systems. May, 104-117.

Citrenbaum, R., Geissman, J.R., & Sehultz, R. (1987). Selecting a shell. AI Expert, September, 30-39.

Cohen, P.R., & Howe, A.E. (1988). How evaluation guides AI re- search. AI Magazine, Winter, 35-42.

Cullen, J., & Bryneau, A. (1988). The knowledge acquisition bottle- neck: Time for Reassessment? Expert Systems, 5(3), 216-225.

Cupello, J.M., & Mishelevich, D.J. (1988). Managing prototype knowledge/expert system projects. Communications of the A CM, May, 534--54 I.

Dologite, D.G., & Mockler, R.J. (1988). Integrating the teaching of knowledge-based system development into the Business curric- ulum. Journal of Education for Business, April, 300-306.

Dologite, D.G., & Mockler, R.J. (1990). Modelling management de- cision situations for effective knowledge-based system develop- ment: A non-technical manager's perspective. Journal of Systems Management, May, 46-55.

Earnest, L. (1989). Can computers cope with human races? Com- munications of the ACM, February, 173-182.

Expert systems--Applications in finance. (1988). Financial Man- agement: Journal of the Financial Management Association, Au- tumn, 12-86.

Finnie, J.S. (1988). Sudden shower enriches MIS turf. Computerworld. October 17, 77-96.

Gallagher, J.P. (1988). Knowledge systemsfi~r business. Englewood Cliffs, NJ: Prentice-Hall.

Gevarter, W. (1987). The nature and evaluation of commercial expert system building tools. IEEE Computer, May, 21-41.

Humpert, B., & Hoiley, P. (1988). Expert systems in financial plan- ning. Expert Systems, May, 78-100.

Inanimate analysts: Expert systems for marketing. (1987). Marketing, September 3, 21.

Lasher, E. (1988). An expert system for logistics management. AI Expert, September, 46-53.

Madni, A. (1988). The role of human factors in expert system design and acceptance. Human Factors, 30(4), 395-414.

Mahler, E. (1986). The business needs approach. In Knowledge-based systems: A step-by-step guide to getting started (The Second Ar- tificial Intelligence Symposium) (pp. 1-18 to 1-25). Austin, TX: Texas Instruments Company. pp. 1-18 to 1-25.

Mantei, M~M., & Teorey, T.J. (1988). Cost/benefit for incorporating human factors in the software iifecycle. Communications of the ACM, April, 428-439.

Martin, J., & Oxman, S. (1988). Building expert systems. Englewood Cliffs, N J: Prentice-Hall.

Mockler, R.J. (1989). Knowledge-based systems for management de- cisions. Englewood-Cliffs, N J: Prentice-Hall.

Mockler, R.J. (1990a). Using knowledge-based systems for estimating risks inherent in a proposed KBS project. Expert Systems. Feb- ruary, 27-41.

Mockler, R.J. (1990b). Using knowledge-based systems for KBS pro- ject feasibility studies. AI Magazine, Fall, 108-125.

Mockler, R.J. (1992). Developing knowledge-based systems. Colum- bus, OH: Merrill Publishing.

Rauch-Hindin, W.B. (1985). Artificial intelligence in business, science and industry (volume II--applications). Englewood Cliffs, N J: Prentice-Hall.

Robots are coming: Use of AI and expert systems in marketing. (1988). Marketing, February 25, 3.

Slagle, J.R., & Wick, M.R. (1988). A method for evaluating candidate expert system applications. AI Magazine. Winter, 45-53.

Tompsett, C.P. (1988). Education, training and knowledge base de- sign. Expert Systems, November, 274-280.

Volkema, R. (1988). Problem complexity and the formulation process in planning and design. Behavioral Science, October, 292-300.

Warman, D., & Modesitt, K.L. (1989). Learning in an introductory expert systems course. IEEE Expert, Spring, 45-49.

Wolfgram, D.D., Dear, T.J., & Galbraith, C.S. (1987). Expert systems for the technical professional. New York: Wiley.