The application of case-based reasoning to the software development process

Abstract

This paper, supported by a commercial case-based reasoning tool, demonstrates a method by which case based reasoning can be applied to the business software development process. Requirements definition, effort estimation, software design, and troubleshooting, and maintenance processes are discussed in terms of candidacy for CBR technology. Proper planning for an adequate support infrastructure is stressed as well as clear expectation setting through ongoing training. CBR is explored as a mechanism for improving productivity and quality problems currently afflicting the corporate software development field.

Introduction

Object-oriented development philosophies and reusable software components are evidence that the formal process of business software development is evolving from an art form into an engineering discipline; a discipline that attempts to optimize the process of software development and maintenance through the development of approaches that formalize the process of specifying, creating, and verifying system components 1, 6. The engineering approach includes goals such as standardization of the process; creation of a measurable, predictable environment; reduction of redundancy in coding and effort through the reuse of existing code and objects; and production of higher-quality software.

One of these objectives, the objective of reusability, is based on the assumption that if software functions or components are designed and built properly, a long-term increase in developer productivity and software quality logically follows. Software reusability has the potential to significantly improve long-term productivity and quality because it capitalizes on one of the most expensive components of the process of software development and maintenance, the cost of experienced people. Reusability is valuable because it seeks to find new uses for software modules and objects that were originally created suis genera but now embody expertise in a way that encourages reuse. For example, a properly designed object-oriented system that defines a vacation report can use the same object again for generating a military leave report. Further, reusability assumes that a company maintains a usable inventory of its software assets.

The learning that analysts and programmers acquire is, in a sense, compressed into code. When software is reused, one reuses expertise. Generally, the more experience a development or maintenance staff has, the more likely it is that they can build a high-quality product in a timely manner. This is seen in the 1996 salary survey of American programmer/analysts [9]. The major difference between the lowest and the highest paid programmer/analysts operating in similar environments was reported as being `experience level'. Experience is generalized in this and other studies, as the years of employment in which the programmer/analyst has had opportunities to identify different schemes for testing (i.e., top-down, bottom-up, exhaustive), apply prior knowledge to all of the key activities related to program development—analysis, design, programming, and testing and using available tools for prototyping and CASE development. When appropriate software engineering techniques are employed, the staff acquires better experience in the software development life cycle phases of: requirements analysis; cost and effort estimation; software design; testing, and on-going maintenance.

Requirements analysis is the process of defining the scope and content of a software development or maintenance effort. It is usually a collaborative effort involving both software development and business personnel. The process relies heavily on the participants' ability to interpret business problems or opportunities and propose feasible software solutions based on prior experience with existing systems and environmental constraints. Knowledgeable analysts learn much from one situation to the next, as do business personnel. Also, in many environments analysts focus on the same functional area such as personnel or finance. They put prior experience to use in all new projects.

Once requirements are understood, the process of developing estimates of cost and effort are undertaken. Accurate estimates emerge from many factors. Although there is a movement towards applying stricter methodologies such as function point analysis to the estimation effort, much of the process continues to rely on the `gut feeling' of experienced analysts. Analysts who have participated in a variety of development efforts and who are familiar with the operating environment often collaboratively apply that experience to the estimation of similar projects.

Following the definition of a system's requirements, software design begins. All of the `how's' are worked out during this phase of the process. Again, experienced analysts can apply their prior knowledge when designing similar systems to the process.

In coding and testing, expertise also comes into play. Experienced programmers optimize their time and system resources when they can draw on the past work of themselves and others. Test cases, library functions, reusable modules, data repositories, objects and other resources can be reused.

Finally, maintenance activities will continue through the software's useful life. Changes and modifications may be implemented singly or in groups on a scheduled basis. Again, past experience comes into play. Experienced maintenance programmers recall the structure of programs and grasp the cascading effects of changes. For example, one Year 2000 project programmer is likely to be more efficient when working on 20 programs than would 20 programmers working on one program each.

By investigating the nature of the software development experience and ways in which experience might be captured, indexed, and drawn upon during software development, substantial improvements might be possible. The application of artificial intelligence (AI) technology to the problem of encapsulation and reusability of experience is currently enjoying considerable attention in a variety of industrial applications through technologies such as expert systems, neural networks, genetic algorithms, and case-based reasoning.

We believe that case-based reasoning (CBR) is a promising form of AI that is especially helpful when a problem domain lacks a strong set of heuristics but possesses a set of successfully and unsuccessfully solved cases 5, 8. Further, we suggest that software project sizing and estimation is an area where CBR can be usefully applied. The purpose of this research is to investigate the application of CBR technology to the business software development process. CBR is a branch of machine learning in which previous, similar problems are studied to address current problems. A CBR system is built around a variety of cases in a problem domain. It does not rely upon a strong heuristic base, but assumes that previous solutions to problems, whether successful or unsuccessful, can inform and improve solutions that appear in the present. A case base is, in effect, an accumulated body of problem-solving experiences. As the cases increase in number and in diversity, the case base becomes more useful. The case-based reasoning process is straightforward and proceeds as follows.

What is the current situation or problem? What information is available that describes the circumstances at hand?

Given the information at hand (possibly incomplete information), which past cases may provide full or partial solutions in the current circumstances?

From among all of the potentially useful cases, which is the most likely to be of assistance? Are there characteristics of the current situation that provide information with which to retrieve the appropriate case.

Does the most appropriate case in fact provide a satisfactory solution, given the current problem? If the retrieved case is useful, is the solution used in that case acceptable? If not: (a) can a new, better case be found, or (b) can the best solution in the current case be modified to provide an improved solution?

If none of the cases in the case base satisfactorily solves the problem, a solution must be identified in another manner. For example, an expert could be asked for a solution or the case base could be augmented with a rule base that fixes or repairs those cases that are close to what is needed. Cases themselves are not written as rules for several reasons. First, the developers are often unsure what the rules are that an expert used when solving a case problem. Second, cases may not encompass a complete universe of cases and solutions. A rule represents specific knowledge about a problem and is not a complete case. A case is complete, while a rule is synthesized from multiple cases by deduction or induction. Hence, a complete rule base could not be defined. After a satisfactory solution is developed, the new or revised case is stored as a new entry in the case base.

Cases are complex entities encapsulating facts and relationships about incidents in a specific context. Riesback and Schank [2]identified CBR applications used for dispute and conflict resolution, plan adaptation, recipe and plan modification, legal argumentation, corporate merger analysis, and medical diagnosis. Cases are used heavily in fields as diverse as business education and military planning, advertising and law, arbitration, and trouble shooting. Often, cases are identified by name or number (i.e., file 29, error message 27, Roe v. Wade). It provides many benefits over competing technologies that could be considered. Among these are the following.

A case base becomes useful with the first case. A case base is an accumulated body of problem solving experience. As with individual expertise, the value of the case base increases as the volume of cases increases. It is not necessary to wait, however, until all cases have been developed before the system can be used. The knowledge encapsulated by case one might be helpful in solving case two.

A case base captures knowledge easily. The structure of cases is much less constrained than rules are. There is no need for discovering complex interrelations between cases as there is when fully elaborating an expert system's rules. Consequently, case bases come online faster and they stay online even as cases are being altered or eliminated. Learning is incremental.

Case bases are understandable. Although a variety of techniques are used to structure CBR systems for efficient case storage and retrieval, the basic organization and functioning of such systems is logical and easy to follow. People feel better about using systems that understandable.

CBR augments human capabilities. A CBR system can track more cases than a person can. Its utility persists beyond the presence of any individual. As with other types of computer systems, a CBR system thoroughly and neutrally evaluates all possibilities before making a recommendation.

CBR is useful to people who know a lot about a task and domain, because it gives them a way to reuse hard reasoning that they have done in the past. It is even more useful, however, to those who know little about a task or domain [3]. It has been observed that traditional rule-based expert systems act as a novice does, following one rule after another until a conclusion is reached. CBR systems more closely approximate an expert's almost immediate insight into a new problem because of characteristics the expert has confronted before. They see the problem and they know what to do. This gestalt deals with the ambiguities of complex problem solving in a way that more closely matches the knowledge retrieval process of a real expert.

Grupe [4]proposes the following criteria for qualifying candidate problem domains:

• cases should characterize the problem solving process;

• similar problems (cases) are recurring;

• weak explanations characterize the selection of solutions;

• cases are highly specifiable;

• CBR information is needed by many people;

• obtaining and storing cases is cost-effective.

In summary, CBR is receiving much attention in certain complex problem solving environments. Many CBR applications have already been deployed and commercial CBR tools are available. Many aspects of the process of business software development meets the criteria outlined for consideration of CBR. The remainder of this investigation outlines a method for integrating CBR into software development and considers the implications of such an integration.