DEVELOPING KNOWLEDGE-BASED SYSTEMS: REORGANIZING THE SYSTEM DEVEPOPMENT LIFE CYCLE

1. DEVELOPING KNOWLEDGE-BASED SYSTEMS: REORGANIZING THE SYSTEM DEVEPOPMENT LIFE CYCLE PRESENTER: SOPHIA FERGUSON

2. OBJECTIVES • EXPLORING THE ORIGIN OF THE KBS. • Why build KBS? • UNDERSTANDING THE PROCESSES IN THE 3 STAGES OF THE KNOWLEDGE-BASED SYSTEM DEVELOPMENT LIFE CYCLE. • DEFINITION STAGE • DEVELOPMENT STAGE • INSTALLATION AND OPERATION

3. TRANSACTION PROCESSING SYSTEMS AND DECISION SUPPORT SYSTEMS VS. KONWLEDGE-BASED-SYSTEMS TPS • Transaction processing systems (TPS) perform routine data processing. • They are designed around forms, procedures, inputs and outputs, and often address well-structured problems. • SDLC originated when most systems were TPSs. • facilitate, Royce’s or Boehm’s life cycle – Execute SDLC sequentially, with sign-off after each phase.

4. TRANSACTION PROCESSING SYSTEMS AND DECISION SUPPORT SYSTEMS VS. KONWLEDGE-BASED-SYSTEMS DSS • High levels on uncertainty. • A strategy to design first implement later is in-appropriate. • Users seldom know their requirements in advance. • Use heuristics and evolutionary strategies.

5. Prototyping Methodology

6. TRANSACTION PROCESSING SYSTEMS AND DECISION SUPPORT SYSTEMS VS. KONWLEDGE-BASED-SYSTEMS KBS • Depends on access to knowledge. • High levels of uncertainty about project’s success. • Applicable when problems cannot be solved with an algorithm. • A nonlinear approach is applied. • Knowledge engineers must ferret out solutions.

7. THE ORIGIN OF KBSDLC • Blue Cross/Blue Shield (BC/BS) and the Institute of Information Management, Technology and policy at the College of Business Administration, University of South Carolina formed a joint venture to build a knowledge-based system to automate medical review of claims. BC/BS selected an expert. The system was called MEDCLAIM.

8. BASIC SYSTEM-BUILDING TASK IN THE SDLC

9. THE KNOWLEDGE-BASE -SYSTEM DEVELOPMENT LIFE CYCLE • The Knowledge-Based-System Development Life Cycle is a prototyping methodology for Knowledge-Based-Systems that uses expert system shells and programming environments.

10. PROTOTYPING METHODOLOGIES Although most KBSs cannot be pre-specified the KBSDLC can be like --: • Evolutionary Prototyping by Incremental Development – where the final prototype is kept by the production system. • Rapid prototyping – where the prototype is used as the design specification for a standard implementation of the production system, as in MEDCLAIM.

11. CONVENTIONAL METHODS vs. PROTOTYPING • KBSDLC consists of processes which are activated, deactivated, and reactivated as needed. • Contrary to common practice with conventional SDLC, reactivation is desirable.

12. DEFINE PROBLEM AND ASSESS FEASIBILITY • Definition of the business and knowledge problem is acquired. • The business problem in MEDCLAIM was straightforward to define. The knowledge problem was more difficult because the knowledge engineers were unfamiliar with medical review.

13. FEASIBILITY STUDY • A feasibility study is a quick examination of the problems, goals and expected cost and benefits of the system.

14. Feasibility Study Organizational Feasibility Economic Feasibility Technical Feasibility Operational Feasibility

15. FEASIBILITY STUDY • Organizational Feasibility • Is the project aligned with the organization’s goal? • Economic Feasibility • Is the project cost-effective?

16. FEASIBILITY STUDY • Technical Feasibility • Does the technology exist ? • What about the availability of staff to make the technology work? • Operational Feasibility • Will the project improve the operation of the firm? • Can the system be easily integrated into the current system?

17. IDENTIFY SUB-PROBLEMS • Knowledge problems of any respectable size are too difficult to comprehend as a whole, so the problem should be broken down into workable sub-problems. • Experience with MEDCLAIM suggests that identifying sub-problems is a significant enough activity to be a separate process.

18. IDENTIFY AND DEFINE CONCEPTUAL STRUCTURE • A transaction processing system automates a process with many observable components, in contrast to a knowledge-based system, which automates a human problem-solving process with few observable components. • Knowledge engineers search for concepts that characterize the expert’s thinking about the problem. • Knowledge engineers should look at each concept (entity, attribute, or relationship) as equally important.

19. IDENTIFY AND DEFINE CONCEPTUAL STRUCTURE • In MEDCLAIM, providers and patients which in the TPS were key entities were peripherals details. • Decisions were made about the claims as opposed to the patients. • Critical concepts were:- • The appropriateness of services rendered. • The amount of services rendered.

20. CONCEPTUAL DESIGN • Logical system design – serves the same purpose as it does in conventional SDLC. • Creates a framework for using knowledge representation. • Knowledge engineers select a knowledge representation (FOL, Semantic Network or Production Rules as in MEDCLAIM).

21. CONCEPTUAL DESIGN • Knowledge engineers should be willing to make drastic changes and perhaps discard the prototype if needs be. • To avoid information overload, knowledge engineers should activate new processes until a prototype is built to provide a focus point for departure.

22. DETAIL DESIGN Knowledge engineers: • Identify propositions for logics. • Write descriptions and pseudo-code for procedures. • Draw network diagram for semantic networks. • Write English language rules for production rules. • Draw diagrams or build models for direct representations. • Identify and name slots for frames and scripts. • Identify and name table entries for data.

23. CODE • Translates detail design into the language of the knowledge engineering tool. • Updating knowledge-base with knowledge information. • Can run concurrently with detail design. • Can create reactivations, as in MEDCLAIM.

24. TEST TEST REASONING • Searches for invalid reasoning. • To correct bugs coding is reactivated. • Address mechanical details such as interfaces and internal flow using artificial test cases. TEST KNOWLEDGE • Correct code does not means correct knowledge. • Attempts to detect invalid and ambiguous knowledge. • Invalid knowledge occurs when facts are stated incorrectly.

25. VALIDATION • Detecting conditions missed earlier. • Requires large sample of real cases. • In MEDCLAIM, the reviewers ran claims through the system for several weeks and uncovered a few minor problems. • Blind spots , due to hidden assumptions , therefore someone else, with different hidden assumptions, should conduct validation.

26. WHAT ‘S NEXT AFTER VALIDATION? • Use the prototype as the production system. • Write off the prototype as a learning experience. • Use the prototype as the specification for a conventional SDLC methodology.

27. WHO SHOULD BUILD THE KNOWLEDGE-BASED SYSTEMS? • Choose a expert who is articulate, cooperative and willing to work with the knowledge engineer. • Knowledge engineers need a flexible approach to problem solving, the ability to conceptualize and think abstractly and to listen without imposing their views.

28. CONCLUSION • A new SDLC philosophy is needed. • Methodologies suitable for TPSs lack the adaptability needed for KBSs. • Methodologies suitable for DSSs address the black box problem but the knowledge engineer must open the black box and get inside the expert’s head.

29. QUESTIONS???