Welcome to My Life

A Walk Down Memory Lane, But I Can't Remember the Class

I handed this final examination for MIS485 on December 18, 1992. I got an A on this 10-page report, so I am presuming I got an A or B in the class; unfortunately, I cannot remember the class. About the only thing I remember, or think I remember, about the class is that I took it at the University of Nevada Las Vegas as part of my Bachelor's degree in Business Administration. Since I cannot keep everything I am going through, I decided to use this report as today's entry. I do not know if I should be worried that I cannot remember the class or the professor.

Note: Everything that is in capital letters was in capitals in the report, so I am presuming that is the was what the professor or whatever grammar book I was using at the time required. The original report was double spaced, which I believe was a requirement of the grammar book I used at the time. Every few pages throughout this report the professor wrote good or very good.

FINAL EXAMINATION

1.          Knowledge engineering is the interaction of Decision Support System development with an expert (notes from first class). It is the process of becoming an expert (notes from second class). This process endeavors to produce Expert Systems, which the book (THE DYNAMICS OF DECISION SUPPORT SYSTEMS AND EXPERT SYSTEMS) defines as computer programs that capture that capture "the knowledge and experiential learning (page 35) of human experts narrowly defined domains.

         Knowledge engineering focuses on creating systems that perform specific task. In doing this it tires to mimic the actions of human experts as they apply their experience in solving specific problems. The systems analysts, on the other hand, must view the whole system in its entirely, rather than just s specific tightly defined domain. Her or she must know how the parts of the entire system interact with each other and upon each other.

         The key players involved in knowledge engineering are the expert, the users and the expert systems creator or the 'knowledge engineer'. The knowledge engineer creates a working system using the three components of an expert system: (1) the dialogue structure [user interface], (2) the inference engine [control structure], and (3) the knowledge base [fact base] (THE DYNAMICS OF DECISION SUPPORT SYSTEMS AND EXPERT SYSTEMS, page 119) . To do this the knowledge engineer needs the cooperation of the expert and user to consult the system.

         If the expert will not cooperate or only partially cooperates the system will fail. The same is true if the user does not consult the ES. That is why the user interface must be "user friendly", easily accessible, and present relevant information. Consider for example Archie, the expert system discussed in "CASE-BASED DESIGN SUPPORT: A CASE STUDY IN ARCHITECTURAL DESIGN".

         Archie presented its information through the use of sets of static forms. Each form presented a specific view that included a "subset of case features" and ways to display those features. The problem here is that neither the system or the architect could "dynamically restructure the interface." As a result the information could not be made more salient.

2.          The Es development process usually relies on the prototyping approach because of the type of tasks handled by ES system. Many of these task, as shown in several of the articles, included "nontraditional" (as opposed to SDLC knowledge representation) methods of representing knowledge. In the article b}"CASE-BASED DESIGN SUPPORT: A CASE STUDY IN ARCHITECTURAL DESIGN" and "FRACAS: A COMPUTERIZED AID FOR REASONING IN TAX" frames were used to represent the knowledge necessary for those system. While the article "CASE-BASED REASONING AND RISK ASSESSMENT IN AUDIT JUDGMENT" MODELS WERE USED. These methodologies contrast drastically with the usual method of data processing technology.

         Other reason for ES developments use of prototyping is shown in the difference between an ES and a DSS. THE DYNAMICS OF DECISION SUPPORT SYSTEMS AND EXPERT SYSTEMS, pages 92 and 93, gives eight differences between the two system. Those differences lend themselves to the use of prototyping. First, ES systems are used mainly by nonexperts. Second, ES technology is most often aplied to recurring problems. Third, ES are used in solving tactical problems. Fourth, the quality of an ES decision is considered successful if it is close to the quality of the resolution made by the expert the system replaced. Fifth, the decisions of an ES are structured, which mean that the attributes of the problem its solved can probably represented in frames. Sixth, an ES is usually used to enhance the efficiency of a decisions rather than the effectiveness. Seventh, the knowledge of an ES system is isolated from its control structure. Eight, an Es can explain its reasoning.

3.          Rule-based expert systems are appropriate for some business applications, but not all. The type of applications that would fall within the range of rule-based ES are those that fall within the range of tactical decision making. Other types of business situations that fall within the range of ES are recurring problems and task that are structured or well defined.

         On page 37 of THE DYNAMICS OF DECISION AND SUPPORT SYSTEMS AND EXPERT SYSTEMS seven elements are given for determining if an application is appropriate for building an Expert System. For a business application to be consider as suitable for a rule-based expert system it must meet the requirements. First, it needs to be a problem or task that takes "between a few hours and a few days to solve." Second, it need to be a problem that it encounter frequently or a task that is performed on a regular basis. Third, it should something that involve primarily symbolic procedures. Fourth, there must exist a general consensus concerning the solution. Fifth, an expert, who is willing to cooperate, must exist. Sixth, there must be test cases that are easily accessible. Seventh, there must be necessity to obtain the expertise.

         Those applications that do meet these requirements fall within areas where there are well documented procedures or concrete rules that must be followed. This include decisions or problems encounter on a daily basis. An example of such a decision would be the one discussed in "AI APPLICATIONS ON WALL STREET". Where certain types of trading practices, i.e. insider trading, were prohibited.

         In this example only about ten percent of the trading practices encountered fall within the "prohibited" range. It was only those that required investigation. While that particular ES system have several problems, those same concepts could be applied to a wide range of business application. Anything in a business environment that has well a established set of rules is a candidate for ES applications. Examples of business applications would be approving or disapproving credit request, the acquisition of new equipment or investment in foreign currency.

         The business application that are not suitable for ES development fall within the range of unstructured decisions or one time problems. Situation that fall within the range of strategic decision making. Examples of business application for this type, would be the acquisition of a new factory or investment in a casino.

4.          There is a very good chance that the future of ES development could include end-user computing. Especially in view of the advance the book (THE DYNAMICS OF DECISION AND SUPPORT SYSTEMS AND EXPERT SYSTEMS, pages 202 and 203) predicts and which may already in progress. Those improvements in ES systems would aid the end-user in developing his or her own expert systems.

         By incorporated learning into expert systems, ES tutors could be included in the systems sold to corporations and individuals. The addition of two other advance to this system would allow experts in any fields to create their own expert systems. Those other two advances are ESs constructed for generic task and those embed in the conventional data processing technology. The most important advances in ES that would allow end-user computing lay in the fields of distributed ES systems and elaborate user interfaces.

5.          One of the benefits of ES to an organization is the improved efficiency of decisions (THE DYNAMICS OF DECISION AND SUPPORT SYSTEMS AND EXPERT SYSTEMS, page 92). Other benefits include solutions to problems of interpretation, prediction, diagnosis, fault isolation, design, planning, monitoring, debugging, repair, scheduling, instruction, control analysis, legal analysis, maintenance, configuration, and targeting resource allocation (THE DYNAMICS OF DECISION AND SUPPORT SYSTEMS AND EXPERT SYSTEMS, page 39).

         Another benefits of Es to an organization was demonstrated in the article "FRACAS: A COMPUTERIZED AID FOR REASONING IN TAX, which discussed the retrieval of historical court cases to pertaining certain legal problem. In business decisions are made daily based upon historical records or the past performance of a stock or firm. Quick and easy access to those records makes the decisions based upon them reliable.

         This article also demonstrated two limitations of ES for an organization. The first was the considerable effort it takes to construct an historical data retrieval system. The second limitation was the coding of historical cases into frames. This part of the process is very labor-intensives. Which brings us to the tird limitation the cost of the system itself. This is a problem especially for small firms.

         Another article "CASE-BASED DESIGN SUPPORT: A CASE STUDY IN ARCHITECTURAL DESIGN reveal two other limitations of Es for an organization. Which this article discussed an ES for architectural design, the problems that were encounter can be applied to any system that encodes cases into frames. First, real-world cases, unless they are very well documented, are incomplete. And this incompleteness limits the usefulness of a system. Second, real-world cases are quite large and take up a great deal of space in storage and memory. Again this brings us to the cost of the system itself.

         Other limitations of ES to an organization include problems inherent in the systems themselves. First, the need for the development of automated tools and improved procedures for acquiring knowledge. Second, the necessity for ES systems to learn from experience. Third, better debugging tools. Fourth, a structured methodology must be developed for validating ES. Fifth, the explanation capabilities of ES systems must be improved. Sixth, improved interface procedures and architectures must be created. Seventh, the ability for ESs to make assumptions and expectation must be incorporated into them. Eight, better techniques of knowledge representation must. Ninth, the methods for handling information that is uncertain, incomplete, or inconsistent needs improvement. Tenth, improved user interfaces. Eleventh, approaches to parallel processing must be developed. Twelfth, method for embedding ES in other systems. Thirteenth, generic task development. Fourteenth, the development of distributed ES techniques (THE DYNAMICS OF DECISION AND SUPPORT SYSTEMS AND EXPERT SYSTEMS, page 88).

6.          a.          The nature of the decision task for Trouble Shooting WORDPERFECT Merg was structured. The relationship between the difficulties encountered in merging primary and secondary files or printing a document and the solutions to those problems are based upon well understood relationships. The key to these relationship is the resolution to a given problem based upon the problem itself.

         For example, there are two reasons files won't merge. First, is missing files. Both the primary and secondary files must exist before they can be merged into a single document. Second, the lack of merge codes is either document will prevent the files from merging. The solutions to both these problems are based the reason for their occurring. Sometimes the resolution can be as simple as looking on the C drive or another floppy disk.

6.          b.          Knowing the application domain well decreased the time required to gather information necessary for the knowledge base itself. It did not, however, decrease the time required to input the examples and test the rules. Because I knew the application I wanted to include every conceivable problem encountered. Tod do this would have required much larger knowledge based on a complete version of the expert system generator.

         The negatives encountered were mostly because of the limitations imposed in the student version of 1STCLASS. This made it prohibitive to construct a detailed explanation of the creation of both the primary and secondary files necessary to complete the merge process. One factor not included was a decision of using keyboard input in merge files.

Final Note: I see by retyping this document that I could have did a better job with some of the sentences and grammar; however, since the instructor gave me an A on the exam and the exam occurred 21 years ago I am not going to worry about it.