Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!

Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


5. FULL-FLEDGED METHODOLOGIES

As soon as softwarehouses working in the area of conventional software development sensed the commercial uptake of expert systems, they entered the market by profiling themselves as competitors through their methodologies. These were mostly the same they also used for developing conventional systems, with an added "KBS-specific" component, mostly focused on knowledge acquisition and representation. As their methodologies were full-fledged, in the sense that they covered all levels of the pyramid and were of a broad scope, they automatically possessed a KBS methodology. As most of them were to a greater or lesser extent of the waterfall type described in Section 3, they shared the world view underlying this approach, though they differed in theories and methods6. In particular in Europe, these methodologies were seen to be proprietary to a company and the KBS methodology carried the name of the original with some kind of "AI," "KBS" or "Expert Systems"-like extension to it. In including KBS-specific elements, they relied heavily on advances made in R&D in the focused approaches described in Section 4. Some companies even started subsidiaries in the AI market, but most of these have disappeared by now. In general, for most softwarehouses, it turned out to be difficult to dress up in new clothes, a situation aggravated by the lack of qualified personnel because knowledge acquisition called for different skills than those possessed by most computer scientists and programmers. It can be safely stated that from this area not much new was added to the KBS development process not already known or developed elsewhere. From that angle, the short-lived nature of these methodologies is not surprising. In the wake of the disappointment with KBS benefits that overtook the initial optimism in the early 90s, building a KBS is just a particular brand of systems development in general, which occasionally occurs when things cannot be solved with conventional techniques. Thus, the need for profiling through proprietary KBS specific methodologies gradually faded away.


6In the 1980s, most conventional methodologies were not supported by computerized tools. However, this changed in the 1990s. Starting with rather simple drawing tools for data flow and entity-relation diagrams, they grew by including more and more activities from the life cycle. One of the most comprehensive computerized development environments on sale in Europe is the S(ystems) D(developers) W(orkbench), marketed by Cap Gemini.

Of the full-fledged methodologies only a few are entirely KBS specific. The most complete and best known is the CommonKADS methodology, the product of two consecutive R&D projects funded by the European Community under the ESPRIT program. This is not the place to elaborate extensively this wide ranging methodology. The reader is referred to Schreiber et al. (1994) for a concise overview. Apart from being full-fledged, the interesting point in CommonKADS is its farewell to waterfall like approaches, and opting instead for a fully objectives and risk driven development approach, which owes much to the work of Boehm. Thus, the methodology also includes its own peculiar project management approach. To give its flavor, the CommonKADS worldview is summarized below:

  • Knowledge acquisition requires knowledge modeling.
  • Parts of expertise can be caught in generic libraries which can be reused.
  • KBS development should take place by building models as the main products.
  • Organizational issue should be part of the methodology.
  • The development process must be supported by a flexible, configurable approach, based on the analysis of objectives and risks.

The theory layer of the pyramid is embodied in the six models and their templates making up the CommonKADS model suite. These models are:

  • The organization model. The organization model addresses issues concerning the socio-organizational environment of the KBS. It contains several views on the organization or part of the organization that enables the people involved to identify problems areas where KBSs could be fruitfully introduced, but also areas where problems can arise when an actual system is put into operation.
  • The task model. The task model is a specification of how an organizational function can be achieved by means of a number of tasks, with a focus on knowledge-intensive tasks. This is achieved by means of a task decomposition. Furthermore, there is a description of a number of important properties of tasks like inputs and outputs, capabilities needed to carry out the task, task frequency, etc. For one or more knowledge-intensive tasks, the required expertise is modeled in the expertise model.
  • The agent model. This model describes the important properties and capabilities of agents7 that perform tasks in the context of the KBS. This information is important for deciding about the task assignment in the new situation. It also models the communication capabilities of agents, important inputs for the communication model.

    7The term "agent" refers to any entity that can carry out a task. Thus, an agent can be a human, but also a computer or another machine.
  • The expertise model. This is a central model in the CommonKADS methodology as it is one of the main components that distinguishes KBS development from conventional system development. It contains a specification of the problem-solving expertise required to carry out the expert's task. The structure of this model is three layered: the domain layer, the inference layer, and the task layer (not to be confused with the task model).
  • The communication model. The communication model is devoted to an issue that is frequently overlooked in KBS development: the interaction with the user and other software systems (e.g., databases). It only covers man-computer and computer-machine communication and not man-man communication even if it is relevant for the context of the KBS.
  • The design model. The bridge to actual implementation of the system is provided by the design model. This consists of a description of the computational and representational techniques that must be used for building and running the KBS.

In addition, there are several libraries that can be used by the developer to shortcut the work. These also promote reuse over projects. The CommonKADS Workbench marketed by ISL from the U.K. is the powerful, though somewhat erratic, embodiment of the tools layer. Figure 4 shows the control window for the CommonKADS Workbench.


FIGURE 4 Main control window of the CommonKADS Workbench.

Figure 4 shows the four main aspects that play a role in the methodology:

  • the life cycle approach LCM (project management) as a sequence of Risk, Plan, Monitor and Review
  • the model set, to be developed in the project
  • the people working in the project
  • the documents to be generated during the project

Not shown is the Library which can be accessed from the "Guidance" menu item.

CommonKADS is the sequel to KADS, which was wholly developed in the eighties. Therefore many ideas originated in KADS are incorporated in the focused approaches and the full-fledged methodologies which KBS specific grafts. In particular the library of generic expertise tasks as can be found in Breuker et al. (1988) and elaborated in Breuker and van de Velde (1994), has been frequently (re)used. It could be that this library is ultimately the most frequently used product of the entire KADS endeavor.

The COMMET methodology (Steels, 1990; 1993) has not been widely published. It is based on the theory that three major components make up a knowledge level description of expertise: the model perspective, the task perspective, and the method perspective. These perspectives are refined in a "spiral" movement. The COMMET approach is supported by a workbench described in Steels (1993). However, the move to operational use has been mainly limited to Belgium and there was never a commercially available version of the COMMET workbench.

Though not sailing under the flag of a methodology, the book by Prerau (1990) comes fairly close to the methodology definition of Section 2. Though the world view is not stated explicitly, the sequence of phases that Prerau describes is of the familiar waterfall type. But the support for carrying out these phases as presented in the majority of the chapters is, most of the time, very KBS specific.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.