Introduction
This section provides an overview of the common aspects of the different method- ologies discussed in the later sections.
Objectives
By the end of the section you will be able to:
rExplain the advantages and disadvantages with using conventional methodolo- gies.
Problems with Conventional Life Cycles
Traditional information systems usually perform some clearly definable pro- cessing tasks, and may have requirements that are relatively clear—though this does not preclude the possible need to developing throwaway prototypes as part of the requirement analysis phase in order to determine these require- ments.
Such systems are often created using the classic waterfall approach to software development. This follows a six-stage life cycle of:
1. analysis 2. design
3. implementation 4. validation 5. installation 6. maintenance.
While these steps provide a useful structure for a traditional software development project, they can be problematic—particularly when applied to the development of a KBS. These issues are discussed in more detail below. Prior to this discussion, attempt Activity 1.
Activity 1
Given the stages in traditional information system design noted above, what might be the principle activities carried out within each stage of a specifically KBS development?
Stage System Principal activities 1 Feasibility study
2 Knowledge acquisition
3 Design
4 Implementation
5 Validation
6 Maintenance
Feedback 1
Stage System Principal activities
1 Feasibility study Checking whether or not it is feasible to write and implement an ES. Feasibility may mean looking at whether or not the ES will be ac- cepted socially as well as whether sufficient resources are available to develop the system in the first place. Economic feasibility will re- quire that the knowledge to be built into the system is relatively scarce and also relatively stable.
2 Knowledge acquisition The knowledge to be input into the ES is col- lected from human experts.
3 Design The ES is designed. The initial design will show the logical structure of the system; this structure will then be used to write an appro- priate ES using rules or frames or both.
4 Implementation Writing the system is completed and it is im- plemented, normally on a test basis.
5 Validation The logic within the system is tested, possi- bly by providing the system with a series of problems where the output is known in ad- vance. A check is made to ensure that the system provides the same or better outputs than those devised by human experts.
6 Maintenance The system is maintained by expanding the rule or frames as new knowledge becomes available or old rules become out-of-date or are updated by new information.
The waterfall model of software development provides a well-structured life cycle that has on occasion worked well for the development of procedural information systems however it has one very significant weakness. For the waterfall model to work a clear and detailed set of user requirements must be obtainable during the analysis stage.
Problems with Project Specification
In the development of KBSs, unlike other types of information systems, the end goals are often not clearly defined. In particular, it is difficult to specify the knowl- edge that the ES must contain. For this reason the waterfall model is inappropriate for the development of KBSs.
Use of Prototyping
One of the main problems with designing ESs is the lack of any firm goals. Expert systems are primarily concerned with the capturing and processing of abstract knowledge. The knowledge domain as well as the activities involved in knowledge acquisition and processing will not be clearly defined, so the actual outputs from the system will be difficult to determine. In a conventional system, outputs can be stated precisely because inputs and processing activities can be clearly explained.
Even when the outcomes can be defined it is difficult to specify both the knowledge that is to be included within an expert system and the quality of the reasoning processes it requires. If these cannot be defined, then it is impossible to define specifications that the design and implementation can be assessed against. For this reason, the waterfall life cycle is problematic when developing any expert system.
Prototyping, on the other hand, has an iterative life cycle that allows specifications to be clarified as throughout the lifetime of the project.
Capturing knowledge for KBSs can also be difficult, because detail of the knowl- edge to be encoded into the system may have to be checked with the human expert a number of times. This does not represent a weakness in system design, but simply shows that additional care is needed in checking the accuracy of any KBS design compared to a conventional system. In KBS terms, this checking of the logical system design is most often done by prototyping.
The prototype is therefore used to check user requirements by providing a mock-up of the knowledge within the system (see Figure 6.1).
This iterative approach has four key stages, which are repeated as necessary:
rpreliminary requirements are identified ra design phase is performed
ra prototype is implemented rthe prototype is evaluated.
Design prototype
Implement prototype
Evaluate Identify
requirements
FIGURE6.1. An incremental prototyping approach for large or complex systems.
This leads to the design and development of a larger system.
Having obtained requirements from the users and performed some knowledge ac- quisition the rules are implemented in a prototype. The accuracy of the prototype is checked or evaluated by users, and a new prototype produced based on the expert’s opinions and suggestions. This process continues until the prototype accurately represents user requirements. The initial prototype therefore evolves into the final system.
This life cycle is particularly suited to KBSs. Knowledge-based systems can be very difficult to define even if the task they are required to perform is clear. It is difficult to define when the knowledge they contain is complete, and when the reasoning is up to the required standard. The availability of a cyclical iterative process is therefore extremely useful as it allows the quality of the reasoning process to be inspected and approved even when it was not possible to specify.
Activity 2
On the basis of your previous knowledge of prototyping, suggest what the advantages of this approach would be for the development of KBSs specifically in relation to:
r the accuracy of the knowledge base
r the quality of the reasoning applied to rule construction r the involvement of users.
Feedback 2
You should have been able to suggest the following advantages:
rAllows the accuracy of the knowledge base to be demonstrated during itera- tions of the life cycle. Any errors or inaccuracies within the knowledge base should be identified as the prototype shows the use and relationship between different rules.
rThe quality of the reasoning is open to inspection. The detail of the knowledge base can be checked prior to detailed programming; again, any errors or inaccuracies should be identified.
rIt provides an easy mechanism to involve the users, management and ex- perts. All parties involved with the design and development of the ES can be involved in the checking of the system.
rInvolvement of management, experts and users is an important part of convincing sceptics and gaining acceptance for the system.
Such an approach also allows the project to be signed off as complete. When the prototype is complete, then this should represent the final version of the rule or case base within the system, hence later signoff will be more of a formality than a detailed check.
Limitations of Iterative Processing
The main limitations of iterative prototyping include:
rThe ability to develop small projects does not always mean that it is possible to develop and maintain large real-world versions.
rThe difficulty in defining the costs and timetables. The number of iterations of the prototype will not be clear. This may result in high costs and development taking longer than expected as additional iterations are carried out.
Clearly, we need to overcome some of these problems.
Problems with Project Management (Users/Timescale)
As the development of a KBS is based on knowledge and human reasoning rather performing numerical calculations, management and users may be sceptical of the system. Prototyping provides a mechanism for involving such people in the project and overcoming their doubts; however, the iterative nature of the life cycle can itself cause additional problems as the number of required iterations, and thus the final cost/timescale, cannot be defined.
Need for Segmented Knowledge Bases and Control over Inference Process
Within a simple ES or KBS, the inference engine is separated from the knowledge base. The reason for doing this is to allow the inference engine to be reused for new problems.
However, this approach has limitations.
r Control knowledge is implicitly mixed with domain knowledge; this issue is discussed in more detail later.
r The representation of the knowledge is limited by what one inference engine understands.
r Large KBSs can be difficult to maintain. Normally, a problem can often be broken down into smaller problems, and these smaller problems may require a range of knowledge representation schemes. This will not be possible with one particular inference engine.
r Finally, large KBSs can be very inefficient when searching for the knowledge to be applied to a current problem, and thus the knowledge base needs to be segmented.
To overcome these problems we need methods that provide structure to a knowl- edge base, and to allow a range of knowledge representation schemes to be applied to different stages of a problem. Methods of providing this structure, including the use of blackboard architectures, are described in this chapter.
Self-Assessment Questions
Question 1
Consider the limitations of the waterfall and prototyping life cycles and justify the need for a methodology when developing large-scale KBSs.
Question 2
Consider any other software development methodologies you are familiar with and evaluate whether or not these can be used to develop ESs.
Answer to Self-Assessment Questions
Answer 1
The waterfall model of software development provides a well-structured life cycle;
however, this model is inappropriate for the development of large KBSs and the
use of prototyping is required in order to identify the knowledge required within the system. However, prototyping does not solve all of the issues. In particular:
rthe final cost/timescale, cannot be defined rlarge KBSs can be difficult to maintain rlarge KBSs can be very inefficient.
To overcome these problems we need methodologies that support the development of structured and segmented knowledge bases.
Answer 2
Other system development methodologies that can be used to develop commercial systems include:
rStructured systems analysis and design methodology (SSADM) rThe spiral model
rThe ‘b’ model.
Information about these systems can be found in many different analysis texts.
Structured systems analysis and design methodology is less suited to ES devel- opment than conventional information systems because, for example, it does not recognise the additional difficulties in relation to defining user requirements faced by knowledge engineers when building an ES.
Both the spiral and ‘b’ models could incorporate knowledge engineering. The ‘b’
model may be particularly suitable, with the emphasis on testing and evaluation at the end of the model.
Details of these methodologies can be found in various places including the www.