CommonKADS: a comprehensive methodology for KBS development

Abstract

W H E N THE RESEARCH THAT led to CommonKADS was conceived as part of the European Esprit program in 1983, the AI community as a whole showed little interest in methodological issues. At the time, the prevailing paradigm for building knowledgebased systems was rapid prototyping using special purpose hard-and software, such as LISP machines, expert system shells, and so on. Since then, however, many developers have realized that a structured development approach is just as necessary in knowledgebased systems as it is in conventional software projects. This structured development approach is the aim of CommonKADS.Traditionally, knowledge engineering was viewed as a process of "extracting" knowledge from a human expert and transferring it to the machine in computational form. Today, knowledge engineering is approached as a modeling activity. In the CommonKADS methodology, KBS development entails constructing a set of engineering models of problem solving behavior in its concrete organization and application context. This modeling concerns not only expert knowledge, but also the various characteristics of how that knowledge is embedded and used in the organizational environment. The different models are a means of capturing the different sources and types of requirements that play a role in realistic applications. A KBS, then, is a computational realization associated with a collection of these models. Figure 1 summarizes the suite of models involved in a ComrnonKADS project. A central model in the CommonKADS methodology is the expertise model, which models the problem solving behavior of an agent in terms of the knowledge that is applied to perform a certain task. Other models capture relevant aspects of reality, such as the task supported by an application; the organizational context; the distribution of tasks over different agents; the agents' capabilities and communication; and the computational system design of the KBS. These are engineeringtype models and serve engineering purposes. The models are considered not as "steps along the way," but as independent products in their own right that play an important role during the life cycle of the KBS.Here, we give a brief overview of the Com-28 0885-9000/94/$4.00 0 1994 IEEE monKADS methodology, paying special attention to the expertise modelingan aspect of KBS development that distinguishes it from other types of software development. We illustrate the CommonKADS approach by showing how aspects of the VT system' for elevator design would be modeled (see sidebar, "The VT System" for background). Project management principlesIn CommonKADS, project management and development activities are separated. Project management is represented by a project management activity model that interacts with the development work through model states attached to the CommonKADS models. The development process proceeds in a cyclic, riskdriven way similar to Boehm's spiral model? IEEE EXPERT

Solution driven versus problem driven design: strategies and outcomes

“…This model was based on empirical data derived from the protocol studies, analysed with the aid of the CommonKADS conceptual modelling language (Wielinga et al, 1993;Schreiber et al, 1994). CommonKADS offers a methodology for constructing knowledge based systems, which can also be used as a cognitive modelling tool.…”

Problem-solving methods: Making assumptions for efficiency reasons

“…We use this example since our experiences in the Sisyphus-II project inspired our current point of view. Sisyphus-II [Schreiber & Birmingham, 1996] aimed at comparing different approaches to knowledge engineering. The task is to configure a vertical transportation system (an elevator) which was originally described in who developed the PSM propose & revise to solve this configuration task.…”

Principles for Knowledge Engineering on the Web

“…A key outcome of knowledge-engineering research in the eighties and early nineties (typically for stand-alone knowledge systems) was the use of patterns, such as patterns for the structure of knowledge-intensive tasks like diagnosis and assessment (Eriksson et al 1995;Schreiber et al 1994). This insight is still a useful guiding principle.…”