Potential Uses of Case-Based Reasoning in Experience Based Construction of Software Systems and Business Process Support Klaus-Dieter Althoff Fraunhofer Institute for Experimental Software Engineering (FhG IESE) Sauerwiesen 6 D-67661 Kaiserslautern Email:
[email protected]
Wolfgang Wilke Centre for Learning Systems and Applications (LSA) University of Kaiserslautern Erwin-Schroedinger-Str. 57 D-67653 Kaiserslautern Email:
[email protected]
Abstract We introduce an organizational interpretation of the well-known case-based reasoning cycle of Aamodt and Plaza which is helpful for comparing the case-based reasoning approach to other approaches known from Software Engineering like the quality improvement paradigm and experience factory approach. We will point out that the introduction of an organizational view to the case-based reasoning cycle contributes to the modeling of and the decision support for experience guided business processes and we believe that this is a first step into the right direction for case-based reasoning to become a key technology for supporting organizational learning. In addition, even for simple application scenarios the applicability potential of casebased reasoning technology is made more explicit by including organizational issues that are usually necessary within real-life environments.
1.
Introduction
An increasing number of activities and publications underlines that the fields of Software and Knowledge Engineering overlap more and more (e.g., Verlage & Rombach, 1995; Bergmann & Eisenecker, 1995; Bartsch-Spörl, 1996; Lees, Hamza & Irgens, 1996; Shaw & Gaines, 1996; Jarke, 1996; Fickas, 1996; Maurer, 1996; Maiden, 1996; Katalagarianos & Vassiliou, 1995; Fernández-Chamiso, Gonzales-Cálero et al., 1996; Bergmann, Wilke et al., 1996, Althoff, Richter & Wilke, 1997). While the use of AI techniques in Software Engineering is by no means new, the more encompassing view (including also organizational issues) of modern Software Engineering approaches, in turn, appears to be of increasing value for knowledge engineering in general and case-based reasoning (CBR) in particular. In this extended abstract we want to give a short overview of a Software Engineering approach named „Experience Factory“ and its underlying methodology called „Quality Improvement Paradigm“ (Basili, Caldiera & Rombach, 1994a) and compare them to CBR by transferring the underlying more encompassing view to the (widely accepted) „CBR Cycle“ of Aamodt and Plaza (1994) and, by this, derive an „organizational interpretation“ of the CBR cycle, called „CBR Process Model“1, which is more helpful for understanding the potential uses of CBR in
1 We know from personal communication with Agnar Aamodt that he had always in mind to optimise the
combination of computer and user. This already includes also organisational aspects as, e.g., indirectly mentioned in Althoff and Aamodt (1996). As heading of a subsection the term has already been used in Althoff
software development and process modeling support. We will illustrate the organizational interpretation of the CBR process model using a simple example that involves the combination of one (or more) user(s) and a database/information system. We will point out that the introduction of an organizational view to the CBR cycle contributes to the modeling of and the decision support for experience guided business processes and we believe that this is a first step into the right direction for CBR to become a key technology for supporting organizational learning. By introducing the CBR process model and demonstrating its usefulness for more realistically representing the spectrum of potential CBR applications, we successfully exemplify that work done in the field of Software Engineering is valuable for the CBR community (for another important example see Bergmann, Wilke et al., 1996). In turn, CBR technology can for instance be used to support an experience factory. This will become very obvious if we compare the quality improvement paradigm to the CBR process model. In the following section we will give a short overview of an experience factory and the underlying quality improvement paradigm. We then introduce the organizational interpretation of the CBR cycle and compare the „resulting“ CBR process model to the quality improvement paradigm. The usefulness of the CBR process model is illustrated by two examples based on a simple database/information system scenario as well as an example for the support of experience guided business processes. Before giving a final conclusion we will point to work on the evaluation of CBR tools and applications and the goal/question/metric approach, a basic mechanism for realizing experience factories, which additionally underline the respective correspondences and analogies of the quality improvement paradigm and the CBR process model.
2.
Experience Factory and Quality Improvement Paradigm
To address the business needs of software, Software Engineering offers a framework based on an evolutionary quality management paradigm tailored for the software business, the quality improvement paradigm (Basili, Caldiera & Rombach, 1994a). The paradigm is supported by a tool for establishing project and corporate goals and a mechanism for measuring against those goals, the Goal/Question/Metric Paradigm (Basili, Caldiera & Rombach, 1994b), and by an organizational approach for building software competencies and supplying them to projects, the experience factory.
and Bartsch-Spörl (1996). However, we are not aware of any paper or article where this issue has been clearly stated.
Package
Analyze
Execute
Characterize
Set Goals
Choose Process
Fig. 1 – The quality improvement paradigm (adapted from Basili, Caldiera & Rombach, 1994a)
The quality improvement paradigm is the basic methodological device for the experience factory. It is articulated into the following six steps (Basili, Caldiera & Rombach, 1994a; Fig. 1): • Characterize: Understand the environment based upon models, data, intuition, etc. Establish baselines with the existing business processes in the organization and characterize their criticality. • Set Goals: On the basis of the initial characterization and of the capabilities that have a strategic relevance to the organization, set quantifiable goals for successful project and organization performance and improvement. The reasonable expectations are defined based upon the baseline provided by the characterization step. • Choose Process: On the basis of the characterization of the environment and of the goals that have been set, choose the appropriate processes for improvement, and supporting methods and tools, making sure that they are consistent with the goals that have been set. • Execute: Perform the processes constructing the products and providing project feedback based upon the data on goal achievement that are being collected. • Analyze: At the end of each specific project, analyze the data and the information gathered to evaluate the current practices, determine problems, record findings, and make recommendations for future project improvements. • Package: Consolidate the experience gained in the form of new, or updated and refined, models and other forms of structured knowledge gained from this and prior projects, and store it in an experience base so it is available for future projects. The goal/question/metric paradigm is the mechanism used by the quality improvement paradigm for defining and evaluating a set of operational goals using measurement. The development of goal/question/metric models is a task performed by the experience factory which will use as inputs to the process the business driven goals provided by the corporate management and the environment characteristics provided by the project team. An experience factory is a logical and/or physical organization that supports project developments by analyzing and synthesizing all kinds of experience, acting as a repository for such experience, and supplying that experience to various projects on demand. An experience factory packages experience by building informal, formal or schematized, and models and measures of various software processes, products, and other forms of knowledge via people, documents, and automated support. The main product of an experience factory is an experience package. The content and the structure of an experience package vary based upon the kind of experience clustered in the package. There is a central element that determines
what the package is: a software life cycle product or process, a mathematical relationship, an empirical or theoretical model, a data base. Together with such central elements information is stored needed to reuse it, as well as lessons learned in reusing it.
3.
CBR Process Model: An Extended View
CBR bases upon cognitive roots because it was originally developed for representing a model of human problem solving and learning on a computer (Schank, 1982; Kolodner, 1993). As such it is a rather general framework for describing problem solving and learning based on experiences. By contrast, the CBR cycle of Aamodt and Plaza (1994) serves as a means for systematically describing existing CBR systems (without ignoring the cognitive roots), which can be directly confirmed by the task-method decomposition model for CBR being introduced in Aamodt and Plaza (1994) as well which further details the description of CBR systems. What we now suggest is to extend this interpretation of the CBR cycle to explicitly include organizational issues as, e.g., it is done by an experience factory. Normally a „case-based procedure“ is part of most business processes (Scheer, 1995), which we call experience guided business processes. In case there do not exist explicitly defined courses of action, decisions are often made based on concrete experiences. Thus, the CBR cycle can be used to model such business processes, at least on a high level of abstraction. Or in other words, as a supplementation to explicitly defined courses of action, experience based reasoning and acting is used by „human problem solvers“. If we view a CBR cycle from this extended organizational perspective, the experience factory model and the (then called) CBR process model become to a high degree comparable. This can be easily seen if we relate the six steps of the quality improvement paradigm to the four phases of the CBR process model. Choose Process, Analyze, and Package can be directly compared to Retrieve, Revise, and Retain. The Execute step and the Reuse phase cannot be directly compared because of a different internal structuring. The quality improvement paradigm already includes the corresponding step for the Reuse phase as a part of the Choose Process step, because the chosen processes are already here combined to an overall project plan. The CBR process model includes the Execute step in the beginning of the Revise phase, where the found „solution“ is tested in the real world. The steps Characterize and Set Goals are also included in the CBR process model but in a more implicit way. While Characterize can be related to the definition of the new case (problem), Set Goals corresponds to the definition of similarity measures. Thus, it is obvious that an experience factory model and a CBR process model have many correspondences and analogies. An experience factory is an infrastructure for the systematic reuse of all kinds of experiences during software development. Compared to this the CBR process model is more general because it models experience based reasoning and acting for any kind of problem (e.g., business processes). However, the very general description of the basic steps within the quality improvement paradigm and, for instance, its compatibility to Total Quality Management (Ishikawa, 1985; Basili, 1993) show that it can also be applied to the management of other kinds of experiences than those collected during software development. As a consequence, we would like to suggest to join research efforts on the practical realization of the CBR process model and the experience factory within industrial and other business environments, because we believe that there are many helpful commonalties. In the next section we will give an example that shows the usefulness of an organizational interpretation of the CBR cycle from the application development point of view.
4.
Instantiating a CBR Process Model Using a Database/Information System
One simple and already very common practice to instantiate the CBR process model in a reallife environment is the use of a database/information system (Fig. 2). Here the Retrieve phase (with a restricted notion of similarity) and the Retain phase (without learning besides case storage) can be automated. The Reuse and Revise phases must be carried out manually. This is a very common scenario for supporting a huge number of business processes. Since the CBR process model already covers such kinds of decision support, it is much easier to recognize potential uses of CBR technology. Possible benefits of using CBR tools (in the more narrow sense) include: • Improving the Retrieve phase by implementing more complicated notions of similarity including multiple class-dependent measures as well as general knowledge. • Improving the Retain phase by applying a case deletion policy, case abstraction, inductive learning of general knowledge, purging of the case base, and learning of improved similarity measures. • Partially automating the Reuse phase through combining different cases, inferring solutions on a more abstract level of description, using adaptation rules, or suggesting additional information that needs to be acquired for solving the problem more adequately. • Partially automating the Revise phase by temporarily canceling of cases that include already rejected solutions, purpose directed revision of the similarity assessment procedure, consistency checking based on general knowledge and/or failure cases, or by comparing the suggested solution to solutions achieved by different methods.
5.
CBR Process Models for Experience Guided Business Processes
The extended view on the CBR cycle as a CBR process model has another advantage for business process modeling. Since experience based reasoning and acting occurs in many different and, especially, in what we call experience guided business processes, the CBR process model can „serve“ as some kind of background model to directly relate business process steps to one another. This can be done in a form that explicitly considers the feedback of valuable information/knowledge and, by this, directly supports organizational learning, a very important topic in enterprise-wide business process modeling and decision support. To give a simple example: a design department produces a plan how to assemble the wings of an airplane (e.g., by Retrieve and Reuse of old plans) and the assembly unit in the same enterprise then assembles these wings and, as usual, uses a number of „work-arounds“ to make the plan really „work“. For applying these work-arounds the respective employee, for instance, uses his/her (well-documented) set of work-arounds (Retrieve, Reuse), achieves more or less immediate feedback during the Revise phase when testing whether the work-arounds help in assembling the wing (in case they do not help maybe the advice of some colleagues is also necessary), and then documents this „case“ if it works and the work-around has been modified, suggested by a colleague, or newly found (Retain). This whole process of assembling the wing (i.e. the complete CBR process model) is part of the Revise phase from the perspective of the design department with respect to the plan for assembling the wing. Often this kind of feedback is not used very well to optimize the overall business process. In case there is a feedback from the assembly unit to the design department, then the plan can be adapted (Revise) and the new/modified one can be documented (Retain).
Problem
New Case
RE
TR
IEV
E
RETAIN
Learned Case Retrieved Case New Case
Previous Cases
US
RE
General Knowledge
E
Tested/ Repaired Case Solved Case
REV
ISE
Confirmed Solution
Suggested Solution
Fig. 2 – Organizational interpretation of the CBR cycle: An example
Thus, linking of CBR process models for related business process steps enables the representation of organizational feedback loops on high levels of abstraction and, therefore, is a contribution to business process modeling in general. In addition, such an abstract (CBR) process model already shows how to support these processes, namely by using CBR technology. This is another reason why the introduction of the CBR process model is helpful, namely because it makes the applicability potential of CBR technology more obvious. For a practical example for using CBR technology in business process modeling support see Krampe and Lusti (1996).
6.
Experience Feedback in CBR System Development: Case Studies
Althoff, Auriol et al. (1995) report on an evaluation of commercial CBR tools that describes such tools according to a detailed set of relevant characteristics. This kind of evaluation has been extended and further detailed in Althoff (1996). Some of the underlying methodological aspects can be found in Althoff & Bartsch-Spörl (1996) and Althoff & Aamodt (1996), and in Bergmann, Wilke et al. (1996) it is described how to build a concrete methodology for developing CBR applications based on this using a process modeling approach (e.g., Rombach & Verlage, 1995). The way in which these results have been achieved is very much comparable to the „philosophy“ underlying the quality improvement and goal/question/metric paradigms. To which degree these approaches overlap is made obvious by Bartsch-Spörl, Althoff and Meissonnier (1997) where the authors report on the implementation of a casebased information system that includes descriptions (e.g., technical aspects, domain aspects, lessons learne, etc.) of CBR applications and tools as cases such that it is possible to automatically retrieve similar CBR applications/tools according to a characterized query problem, i.e. an application task. This system automates a task which in principle is very common to any experience factory. It is realized by an evaluation approach that has many correspondences to the goal/question/metric paradigm, as described in Basili, Caldiera and Rombach (1994b), for the area of CBR tools and applications, and it is implemented using CBR technology.
7.
Conclusion
We agree with Barr and Magaldi (1996) who state that CBR is a technology with a potential of applications that goes far beyond the specific usages in integrated problem solving and learning tasks for „AI problems“. We propose an „organizational interpretation“ of the CBR cycle of Aamodt and Plaza (1994), which we call CBR process model, more generally covering the possible spectrum of applications of CBR technology. As a first justification we pointed to a number of cases studies and their obvious correspondences to other approaches in the Software Engineering field which underline the broad applicability of CBR technology and make it necessary to realistically characterize the application potentials of CBR, e.g. in experience based construction of software systems and in supporting different kinds of experience guided business processes. In Barr and Magaldi (1996, p. 495) the authors state that they believe that there is „a window of opportunity for CBR to seize a key role in building an information infrastructure to support the knowledge-based enterprise“. We believe that there will be a number of supporting case studies soon that confirm the view of Barr and Magaldi (1996) and we hope that our organizational interpretation of the CBR cycle contributes to this.
8.
Acknowledgment
Funding for this work has been partially provided by the Commission of the European Union (INRECA II: Information and Knowledge Reengineering for Reasoning from Cases; Esprit contract no. 22196) and to which the authors are greatly indebted. The partners of INRECA II are AcknoSoft (prime contractor, France), Daimler-Benz (Germany), Interactive Multimedia Systems (Ireland), tecInno (Germany), and the University of Kaiserslautern (Germany).
9.
References
Aamodt, A. & Plaza, E. (1994). Case-Based Reasoning: Foundational Issues, Methodological Variations and System Approaches. AI Communications 7, No. 1, 39-59 Althoff, K.-D. (1996). Evaluating Case-Based Reasoning Systems: The INRECA Case Study. Habilitationsschrift, University of Kaiserslautern (submitted) Althoff, K.-D. & Aamodt, A. (1996). Relating case-based problem solving and learning methods to task and domain characteristics: towards an analytic framework. AI Communications 9, No. 3, 109-116 Althoff, K.-D., Auriol, E., Barletta, R. and Manago, M. (1995). A Review of Industrial CaseBased Reasoning Tools. Oxford (UK): AI Intelligence Althoff, K.-D. & Bartsch-Spörl, B. (1996). Decision Support for Case-Based Applications. Wirtschaftsinformatik 1/96, special issue on case-based decision support (edited by D. Ehrenberg), 8-16 Althoff, K.-D., Richter, M. M. & Wilke, W. (1997). Case-Based Reasoning: A New Technology for Experienced Based Construction of Knowledge Systems. forthcoming Barr, J. M. & Magaldi, R. V. (1996). Corporate Knowledge Management for the Millenium. In: Smith & Faltings (1996), 487-496 Bartsch-Spörl, B. (1996). How to Make CBR Systems Work in Practise. Burkhard & Lenz (1996), 36-42 Bartsch-Spörl, B., Althoff, K.-D. & Meissonnier, A. (1997). Learning From and Reasoning About Case-Based Reasoning Systems. To appear in: Proc. XPS-97 Basili, V. R. (1993). The Experience Factory and its Relationship to Other Improvement Paradigms. In: I. Sommerville and M. Paul (eds.), Proc. of the 4th European Software Engineering Conference (ESEC4), Springer Verlag, 68-83
Basili, V. R., Caldiera, G. & Rombach, H. D. (1994a). The Experience Factory. In: Marciniak (1994), 469-476 Basili, V. R., Caldiera, G. & Rombach, H. D. (1994b). The Goal Question Metric Approach. In: Marciniak (1994), 528-532 Bergmann, R., Wilke, W., Althoff, K.-D., Breen, S. & Johnston, R. (1996). Ingredients for Developing a Case-Based Reasoning Methodology. In: Proc. GWCBR-97 Bergmann, R. & Eisenecker, U. (1995). Fallbasiertes Schließen zur Unterstützung der Wiederverwendung objektorientierter Software: Eine Fallstudie. In: M. M. Richter & F. Maurer (eds.), Expertensysteme 95, infix Verlag Burkhard, H.-D. & Lenz, M. (eds.) (1996). Proc. 4th German Workshop on Case-Based Reasoning – System Development and Evaluation. Informatik-Berichte Nr. 55, Humboldt Universität zu Berlin Fernández-Chamiso, C., Gonzales-Cálero, P. A., Gómez-Albarrán, M. & Hernández-Yanez, L. (1996). Supporting Object Reuse Through Case-Based Reasoning. In: Smith & Faltings (1996), 135-149 Fickas, S. (1996). Kate's Story: from RE to KE, and Back Again. In: Gaines & Musen (1996), 55-1–55-2 Gaines, B. R. & Musen, M. (eds.) (1996). Proc. 10th Knowledge Acquisition for KnowledgeBased Systems Workshop. Banff, November 1996 Ishikawa, K. (1985). What Is Total Quality Control? The Japanese Way. Prentice Hall (translated by D. J. Lu) Jarke, M. (1996). Meta Models for Requirements Engineering. In: Gaines & Musen (1996), 56-1–56-27 Katalagarianos, P. & Vassiliou, Y. (1995). On the Reuse of Software: A Case-Based Approach Employing a Repository. Automated Software Engineering, 2, 55-86 Kolodner, J. L. (1993). Case-Based Reasoning. Morgan Kaufmann Krampe, D. and Lusti, M. (1996). Wissensbasierte Unterstützung des konzeptionellen Entwurfs betrieblicher Informationssysteme. In: R. Klar (ed.), Abstracts of the 20th Annual Conference of the German Society for Classification, 73 Lees, B., Hamza, M. & Irgens, C. (1996). Applying Case-Based Reasoning to Software Quality Management. In: Burkhard & Lenz (1996), 162-169 Maiden, N. A. M. (1996). The Transfer Problem in Analogical Reuse. Smith & Faltings (1996), 249-265 Marciniak, J. J. (ed.) (1994). Encyclopedia of Software Engineering – Vol. 1. New York: Wiley Maurer, F. (1996). Coordinating System Development Processes. Gaines & Musen (1996), 49-1–49-20 Meissonnier, A. (1996). Ein fallbasiertes Informationssystem für fallbasierte Anwendungen und Systeme auf der Basis von Inreca. Diploma Thesis, University of Kaiserslautern Rombach, H. D. & Verlage, M. (1995). Directions in Software Process Research. In: M. V. Zelkowitz (ed.), Advances in Computers, Vol. 41, Academic Press, 1-61 Schank, R. C. (1982). Dynamic Memory: A Theory of Learning in Computers and People. Cambridge University Press Scheer, A.-W. (1995). Wirtschaftsinformatik. Referenzmodelle für industrielle Geschäftsprozesse. Springer Verlag Shaw, M. L. G. & Gaines, B. R. (1996). Requirements Acquisition. IEE Software Engineering Journal 11, 3, 149-165 Smith, I. & Faltings, B. (eds.) (1996). Advances in Case-Based Reasoning. Springer Verlag
Wess, S. (1995). Fallbasiertes Schließen in wissensbasierten Systemen zur Entscheidungsunterstützung und Diagnostik. Doctoral Dissertation, University of Kaiserslautern; also: St. Augustin: infix Verlag
