Appears in Proceedings of the International Conference on Software Reuse, Orlando, FL, ACM, New York, April, 1995.

Accelerating the Successful Reuse of Problem Solving Knowledge Through the Domain Lifecycle

Scott Henninger

Department of Computer Science & Engineering
University of Nebraska-Lincoln
scotth@cse.unl.edu

Abstract

The inability of software reuse to reach its full potential lies partially in the product-centric way in which we view software development. Methods are needed that help us reason about product families and degrees of support that can be offered for problem domains. This paper uses a "domain lifecycle" to formalize a process in which increasing levels of formality can be provided as a domain matures. The first step in this process is to collect and disseminate project experiences that can accelerate the process of identifying and refining application domains with significant impact in a software development organization. This approach facilitates the reuse of a broad spectrum of knowledge at multiple levels of formality. Based on empirical investigations of a software development organization, a prototype of a case-based organizational memory repository for software development practices is presented and assessed for its impact on reusing software development knowledge.

Keywords: domain analysis, organizational learning, reuse repositories, broad-spectrum reuse

Table of Contents

Introduction
Supporting the Domain Lifecycle
An Organizational Memory Repository for Software Development
Structure of the Case-Based Repository
Knowledge Dissemination
Constructing Domain Knowledge Through a Community of Practice
Changes to Development Practice
Related Work
Conclusions and Future Directions
References

Introduction

Research in software reuse has observed that most successful reuse efforts have been achieved using collections of components within well-defined and well-understood domains. "Biggerstaff's Rules of Three" [34] states that unless three real systems have been built in the domain, it is unlikely that the details required for successful reuse can be derived. In many ways this is unfortunate as tool builders are providing the largest degree of support for those problems that require the least amount of support. If the domain is mature, then people and artifacts exist that can supply the necessary background for solving the problem, reducing the need for sophisticated support models. A potentially larger return on investment lies in support for problems that have not yet matured, but for which some isolated solutions have been explored.

It has been suggested that "The defining characteristic of good reuse is not the reuse of software per se, but the reuse of human problem solving" [4][p. 13]. To accelerate the process of turning isolated problem solving episodes into reusable assets, tools are needed that manage knowledge assets and support their refinement into reusable software artifacts. Not only must mature domains be supported with formal reusable artifacts and domain-specific languages and tools, but initial information about emerging domains needs to be captured and disseminated. Initial trail-blazing efforts begin by documenting significant problems and their solution as part of the development process. This information is initially structured as "we had this problem and here's how we chose to solve it for our situation." This represents critical knowledge that begins to explore problem domain and its potential solution space. As subsequent development efforts further explore these issues, domain knowledge begins to emerge that can be transformed into domain models or other domain-specific assets. Initial problem solving episodes lay the initial groundwork that can support subsequent development efforts by showing examples of how similar problems have been solved.

Previous observations of a large development organization [21] have demonstrated that knowledge of how CASE tools can be adapted to organization-specific problems plays a significant rile in the development process. This "tool mastery burden" [10] occupies a sizable part of developer's time, not only because of the steep learning curves for CASE tools [22], but because a great deal of effort goes into using these resources to solve the domain specific development problems demanded by the organization's business needs. Off-the-shelf CASE tools are not sufficient by themselves. Organizations need to build "scaffolding" [9] around these tools that adapt them to the specific kinds of problems encountered in the organization. Reusing this scaffolding and other kinds of knowledge can provide the kinds of productivity and quality improvements that software reuse techniques strive to achieve.

We have been exploring these issues with an in-house software development organization for a major railroad corporation in the U.S., Union Pacific Railroad (UPRR). This organization employs about 300 developers and managers to develop sophisticated information systems to help run their business. Projects are typically small to medium-scale, with about 26 currently active projects. This distribution of knowledge makes communication between projects difficult, making the need for domain analysis and organization-wide reuse efforts all the more important. The focus of our project has been to help UPRR understand how CASE tools can be used more effectively by identifying techniques used successfully in different domains. As opposed to conducting a static domain analysis, our approach has been to develop the infrastructure to help organizations create their own domain knowledge. To accomplish this, we have used an "industry as laboratory" approach [30] where we study the software development organization to understand the pragmatic issues involved in developing software systems. From these observations we have developed an organizational learning approach to software development in which problem solving knowledge is refined from isolated problem solving episodes to reuse-oriented design environments that formalize knowledge in a domain that is important to the organization.

In what follows, we begin by introducing an organizational learning approach to software development through a domain lifecycle that formalizes the maturation process of domain knowledge. The domain lifecycle defines a multi-year research effort we are conducting with UPRR and other development organizations. This paper is a preliminary report that primarily describes the issues we have encountered in developing a case-based repository defining an organizational memory for software development knowledge. A third generation prototype, named BORE , is used to instantiate and explore these issues. The examples used focus on knowledge about using tools to solve problems. This is meant to demonstrate the kinds of development infrastructure that needs to be created, and not to argue that tool knowledge is the only or most important form of knowledge needed by software developers. We have also been researching project-specific knowledge [21] and interface guidelines [20] as other forms of knowledge needed in our approach. The paper concludes with a brief overview of related research and an assessment of our experiences thus far.

Supporting the Domain Lifecycle


Support for software development and reuse is needed for new and evolving domains as well as mature domains. Our approach is to provide the means to support a domain lifecycle [31] in which appropriate levels of support is provided as a domain matures from a couple of isolated instances to a well-understood domain with well-defined bounds. This process is supported with case-based reasoning tools that capture problem solving experiences within an organization to identify specific solutions to problems faced by software developers throughout the development lifecycle. As experiences accumulate, the organization collectively learns about the domains so people can begin to build a culture based on success, avoid duplicate efforts, and avoid repeating mistakes. This defines an organizational learning approach to software development that naturally incorporates reuse into the product and domain lifecycles.


Figure 1: Organizational Learning Support for the Domain Lifecycle.

Figure 1 depicts how an organizational learning approach to software development supports the domain lifecycle. As frequently encountered problem domains mature from novel problems to repeated problems to a fully mature domain, support is provided in increasing levels of automation. CASE tools supporting the three main steps in the domain lifecycle are identified:

These steps define increasing levels of automation and support mirroring domain maturity. Problems that have yet to be analyzed are supported by searching for similar problems in a case-based repository of project and tool experiences. The cases will contain information that is specific to the original project and may need work to apply to the current context, but at least there are some prior experiences to help guide design decisions. As activities are repeated, case-based technology is employed to identify recurring development issues and support the process of generalizing from individual cases to domain-specific abstractions such as design guidelines, domain models and other formal structures. Using handbooks, guidelines, and domain models provides a generalized level of support as the knowledge has been processed by domain analysts into a form that is applicable to general problems in the domain. As the domain matures, tool designers can use the synthesized knowledge and components to construct design environments that automate development tasks and provide intelligent support for mature domains repeatedly encountered in the organization.

This paper will primarily focus on the infrastructure needed to create a case-based repository of problem solving experiences. We are currently in the process of developing domain abstractions in the domain of security issues for client/server application that includes not only network security issues, but controlling access to application components for users with specific access rights. We are also investigating component-based software development frameworks [12, 25, 29] as an infrastructure to construct design environments that create customized frameworks for significant portions of an application. We introduce the domain lifecycle here to underscore our conviction that collecting and disseminating informal, and at times anecdotal, information is a first and necessary step to accelerating the process of domain analysis.

An Organizational Memory Repository for Software Development


Creating an organization memory repository for problem solving experiences is a first and necessary step in supporting the domain lifecycle. Case-based technology [24] is one approach to creating such a repository. A case-based repository for decision support helps users reason "from old cases or experiences in an effort to solve problems, critique solutions, explain anomalous situations, or interpret situations." [23][p. 53]. Similar to design patterns [15], cases bundle together a description of the problem, its solution and the context for the problem and solution. This has the advantage of putting all the information a person needs to adopt a solution in one place. Users of a case-based organizational memory repository begin the problem solving process by describing a problem to the case-based system. The system retrieves cases with similar features. Using these cases as a basis for decision making, the user adapts case solutions appropriately to meet their specific problem solving needs.

A case-based approach to problem solving goes against the traditional focus of abstraction in software reuse approaches [26]. There is a trade-off between generally applicable knowledge and specific knowledge. Specific knowledge, when it applies, provides more powerful support because it can be easily adapted to the current situation. The problem is that it is only applicable to a narrowly defined problem situation, creating the desire to generalize the knowledge for wider applicability. General knowledge will need to be instantiated in some manner before it can be used. Of course, automatic specialization of components eliminates this problem, but these second-order library techniques are most applicable to mature domains [8], and our concern is to provide some support for emerging domains and lay the foundation for creating generative and transformation-based approaches. As cases accumulate, the applicability problem of specific cases diminishes while providing some examples of how a problem can be approached.

Therefore, the case-based repository provides a valuable level of support by itself. In fact, studies of usability guidelines has uncovered problems with using generalized information that needs to be converted into design rules that are immediately applicable. Designers had trouble interpreting the guidelines and understanding their applicability to the problem at hand [33]. Specific examples were found to be most useful. Even when the examples did not match the design problem, designers found them useful for understanding guidelines and how they could be applied. Augmenting generalized knowledge with concrete cases (examples) help designers interpret the information, making it easier to comprehend and apply to the current design problem [20].


Figure 2: The Case Window.

Structure of the Case-Based Repository

The central element of a case-based repository is the case. Figure 2 shows the user interface for a case in BORE. The case is titled "Data Window Retrievals Functions Available" and consists of nine fields describing the case. The 'Description' field provides a description of the problem and 'Solution' describes the solution to the problem. The 'Characteristics' field displays key terms used to index the case. The 'Resources For This Case' shows a number of resources that are used in this case or otherwise serve to describe the context in which this case works. 'Source Code' is the type of resource currently selected which shows the names of reusable functions. Other types of resources include tools, project issues, people, and development methods. 'Resource Categories' shows the links in the repository to which this case is attached. For example, the case shown in Figure 2 is linked to the 'Reusable Objects' attribute of the 'PowerBuilder' tool descriptor in the 'Tools' resource (see Figure 3). Using the 'Link Resource Category' to add a new link to the case is demonstrated in a later section. The 'Related Cases' field shows links between this case and related cases. Finally, the bottom of the window shows some general accounting information about the owner(s), the current status of the case resolved, unresolved, or active) and the date of case creation.


Figure 3: Viewing the Resource Descriptor for PowerBuilder.

Links in the repository are used to organize the cases by specific development resources, such as CASE tools, development methods, projects, or people. Resource descriptor windows, such as the one shown for the PowerBuilder tool in Figure 3, are one-stop locations to get information on a specific resource. The attributes displayed in the resource descriptor interface are instantiated by cases. Note, for example, that the "Data Window Retrievals Functions Available" case is displayed in the 'Reusable Attributes' field for PowerBuilder. Double-clicking on one of these case titles will display the full case window as shown in Figure 2.

The attributes shown in the resource descriptor field are dependent on the type of resource. The fields we have chosen for the 'Tools' resource were derived from a number of Lotus Notes databases used to exchange information at UPRR. The Description field gives a brief description the tool. The How-To field contains tips and techniques that have been used to solve problems with the tool. The entries in this and the rest of the fields point to cases in the repository that can be displayed by clicking on the entry. Notice that the How-To entries contains organization-specific knowledge about how the tool is used in the development context at UPRR which includes an eclectic mix of other off-the-shelf CASE tools, in-house systems, projects, and other issues. For example, 'TCS' refers to the "Train Control System", a mainframe application used to collect large amounts of data about the railroad, while 'Watchdog' refers to an existing project.

The Caveats field is intended to collect information about idiosyncratic issues users may need to be aware of when using the tool. For example, some UPRR projects have discovered that PowerBuilder's control of the system can interfere with communications software. The Projects field collects all the UPRR projects that have used this tool. Open Questions is a forum for unresolved questions. Once an open question is answered, it should migrate to the How-To or Known Bugs and Fixes field. The Known Bugs and Fixes field holds information about bugs with the tool or using the tool in certain environments. Fixes and work-arounds are displayed in indented text. Reusable Objects points to information about reusable objects associated with the tool along with pointers to the source. Standards holds corporate standards for using the tool, naming standards, etc. General Info. helps users find people with expertise about the tool. It includes local experts (TPM's are Technology Product Managers that are assigned to tools to help developers use the tool to its fullest potential). It also has contact information for the CASE tool vendor.

Knowledge Dissemination

With over 90 different development tools in use at UPRR, choosing an appropriate set of tools for a project is becoming a significant problem. The sheer number of tools is a formidable barrier, but the complexity and overlapping nature of these tools, ranging from operating systems, databases, and languages to CASE tools, development methodologies and word processors creates an information overload situation. Our approach to disseminating case-based knowledge has been to provide CASE tools to support exploring the repository [21]. Two methods are provided for retrieving and browsing information in the repository. The first is to find a specific tool and search its categories for needed information. The second is to search across all cases, receiving matching cases that cross tool boundaries. These methods are described in the following paragraphs.


Figure 4: Searching for Cases.

Finding Tool Information. Figure 3 demonstrates how information about resources are viewed. The "Open a Resource" window on the left-hand side of Figure 3 is used to choose a type of resource, which includes tools, development methods, project issues, source code, and projects. Once the type is chosen the user can choose a specific resource from the scrollable window. Double-clicking on the resource name displays the window on the right-hand side of figure, in this case the PowerBuilder CASE tool. Recent feedback has indicated that with over 90 different tools, another level of categorization may be necessary to make the process of finding the tool easier. For example, the tools could be categorized by CASE tool, operating system, word processor, etc. Users would then have to choose the type of tool to get to the "View a Resource" window shown in the figure.

Querying for Similar Problems. Developers may not always need information that is tied to a specific tool. In these cases we have provided users with a search mechanism that finds cases across different tools and projects. Figure 4 shows the query interface and the result of a query about combo boxes for access to TCS (Train Control System) databases. The matching cases shown in the window on the right-hand side of Figure 4 display the titles of cases and the description field of the selected case. Double-clicking on the title of selecting and choosing "View Case" displays the case's window. In this instance the user has chosen to search the entire repository of cases. By choosing the "Restrict By" box, the user can restrict the search to a particular type of resource and (optionally) a specific resource (such as PowerBuilder or IEF).

Searching can be performed through either an exact or partial match retrieval algorithm, depending on which button the user chooses (see upper right-hand side of the 'Case Search' window in Figure 4). Cases are indexed by key terms and phrases called "characteristics", as shown in Figure 2. Characteristics define a controlled vocabulary that fits many organizations where standard terminology and acronyms are often used to communicate common issues [21]. Choosing the exact match button retrieves all cases that are indexed by any the characteristics specified in the query (i.e. a Boolean OR of all query terms). This method uses a simple inverted index to find cases. Simple matching techniques have been shown to inadequately support the process of satisfying an information need, especially when the query is ill-defined [7, 18]. Methods are needed that can retrieve noisy and inexact patterns with a soft matching retrieval algorithm. This is accomplished by choosing the 'Partial Match' button, which uses a spreading activation algorithm that retrieves cases either matching or associatively related to query terms (a technical description of this search method can be found in Henninger (1995) [19]). Each time a search is requested a new 'Matching Cases' window appears, allowing users to modify the query and compare results.

This query method is invaluable not only for answering specific queries, but for finding out what kinds of type of problems a given tool can be used for. By querying the repository for a given problem, cases are returned that match that kind of problem. By perusing the tools that have been used, one can begin to understand which tool should be used for a particular problem. For example, it could be found that the CASE tool IEF (Information Engineering Facility) has been used for a number of systems in which access to windows and buttons need to be secured for certain users. Using this tool for a development project with similar requirements ensures that some of the issues have already been documented, and increases the likelihood that reusable objects exist.

Constructing Domain Knowledge Through a Community of Practice


Developing a large-scale, real-world, knowledge base to support the development process is not a simple matter of engaging in an up-front knowledge acquisition effort. A process of continuous incremental refinement [32] must be in place so the repository can evolve as new problems and solutions are discovered [14]. Generally there are two approaches to knowledge acquisition in software design environments. The first is to take the naïve position that designers will readily perceive the future benefits of engaging in the often difficult, and always extra, task of putting knowledge into the system. A second approach is to appoint a "knowledge librarian" to maintain a knowledge base. While this shifts the workload away from developers and ensures that the knowledge base is continually updated, it does not ensure that relevant and accurate information is acquired.

This brings us to a third approach that utilizes the collective knowledge of the people in an organization to truly create an organizational memory. The method is to provide knowledge acquisition tools that help developers document their work and coordinate with other project members. Our studies have shown that there are currently many information collection activities in development practices at UPRR [21]. Managers and developers were observed devoting 30 - 40% of their time to knowledge collection activities such as entering tips and techniques into Lotus Notes databases, writing up meeting notes, and coordinating development activities. Scribes are often appointed at meetings to take notes and keep track of action items.

The primary knowledge collection tool for our repository is the case window (see Figure 2). When documenting a problem, a developer can either begin by modifying an existing case and saving it with a new name or creating an empty case. To allow the creation of unresolved cases, all of the fields are optional. Developers can therefore create place holders for issues that have been identified but not yet resolved. The repository can be analyzed for unresolved cases to find common issues that are currently being worked on. As developers work on the problem, they can modify the case to show progress or enter the final solution to the problem. We are working on tools that can be used to document and manage projects through the maintenance of cases in the repository, modifying current documentation practices to take advantage of BORE's capabilities. The advantage of project documentation with BORE is that a single repository contains information on all projects. Reuse is enhanced, and documentation effort can be reduced by simply pointing to cases that are re-used.


Figure 5: Linking Cases to a Resource Category.

The case shown in Figure 2 directs users toward some reusable source code that has been developed for the PowerBuilder platform. Associating this case with the "Reusable Objects" category of the PowerBuilder tool will help other PowerBuilder users find this resource. Clicking on the "Link Resource Category" button in the case window of Figure 2 brings up the window shown in Figure 5. We used a different case for this image that has to do with asynchronous processing with the IEF tool. After clicking on the "Done" field the case will become associated with the "How-To" category of the IEF tool. The case will appear on the "Resource Categories" combo box in the case's window and can be chosen from the "How-To" field in the tool window (shown for the PowerBuilder tool in Figure 2). Cases can be associated with any number of attributes in any of the resource descriptors.

Changes to Development Practice


Making an organizational learning approach to software development work involves more than technology and supporting CASE tools. Changes to development practices are needed to integrate tool usage into the development process. In the very least, development becomes a process of basing decisions on previous experiences, thus advocating reuse throughout the development process. Institutionalizing reusability procedures in organizations is currently a hot topic, and few cases of true organizational change have been reported [17]. The domain lifecycle itself advocates viewing software development as producing product lines [16, 31] with implications across the organization. This is a sizable departure from the current software development culture, which focuses exclusively on development projects.

The strength of the domain lifecycle is that proper levels of formalization can be applied as a domain matures. When the domain is new or the issues will not necessarily recur, keeping a semi-formal case-based repository will suffice. This kind of process is in alignment with many development organizations that are using informal e-mail and discussion database software, such as Lotus Notes, to disseminate and archive information. It is, in many ways, an extension of the traditional office memorandum and filing cabinet method. It is not until a domain has recurring problems or is part of the development network that more formal methods need to be applied. This allows a level of discrimination in terms of what kind of documentation and rigor is needed for a given problem. As opposed to applying rigorous methods universally, developers can place their time and effort where it is needed the most.

The other strength of the organizational learning approach is that it embraces diversity. Instead of trying to fit CASE tools into problems or domains they are not well-designed for, this approach seeks to learn which tools is best for a given type of problem. This flexibility allows people to work with familiar tools and process models, but comes with the potential expense of having to train developers in a wide range of CASE tools. Our observations at UPRR indicate this happens anyway, but we are investigating ways in which the expertise of project members can provide an input to the process of choosing and using CASE tools.

Related Work


Our work applies techniques from artificial intelligence and human-computer interaction to software engineering problems. In many respects our approach operationalizes the domain analysis prescription to identify reusable information in the problem domain, capture relevant information, and evolve the information to meet current needs [2]. Efforts to create wide-spectrum [27], or comprehensive [6] reuse methods are quite similar in focus to our approach. Lubars focused mainly on code-related knowledge such as algorithms, data types, and abstract designs. Basili and Rombach are much closer to our approach by defining a reuse candidate as any type of experience accumulated in the context of software projects. They write in particular about practices, methods, tools and the development process. The difference between their approach and our is their focus on abstract models of reusable artifacts and the schemes, meta-schemes and reference architectures used to organize this information [5, 6]. Our approach is unique in that we start with concrete instances and move toward more widely applicable models. We have also presented some specific tools that can be used to support our approach.

There are also a number of similar efforts that focus on domain analysis at the component and algorithm level. The experience factory [5] defines an organizational framework that separates component design from application development, but largely focuses on "experience" at the level of source code components. Technology books formalize knowledge about algorithms and formal models for classes of problems[3]. While this research has focused on the end products, tools, methods, and handbooks, Simos' notion of an Organon views domain analysis as a continuous, incremental, process that leads to the domain lifecycle that follows the maturation of a domain [31]. Our approach combines some of these ideas and provides CASE tools that can help an organization accumulate and use expertise to streamline the entire development process.

Design rationale techniques, which advocate a process of deliberation in which design decisions are reached by consulting the design issues an alternatives stored in a repository [13], have also had a significant impact on our approach. Our goal will be not only to capture the rationale of why a system was designed a certain way, but also what occurred as a result of the decision, and how future efforts of a similar nature can be improved.

Our approach is also very close in spirit to the patterns movement in the object-oriented community [15]. A pattern, which has the elements of a name, a problem description, a solution, and the consequences of applying the patterns, has the essential attributes of a case. The perspective of the pattern community, which is attempting to write down some of the folklore of the object-oriented community is also shared by our approach. The major deviation is that patterns are restricted to object-oriented designs and, while useful, only define one kind of knowledge that we wish to capture in our repository.

The closest efforts to ours have focused on creating corporate repositories, often referred to as organizational memory. Answer Garden [1] was built to capture recurring questions in a central database using a branching network of multiple-choice questions and answers. The Designer Assistant integrated a repository with existing practices in a development organization at AT&T [32]. An interesting aspect of this project is that modification of the repository was included as part of the design review process, ensuring that the Designer Assistant evolved with changing organization needs. We are currently in the process of creating similar procedures in UPRR's design process. The primary difference between our approach and the Designer Assistant and Answer Garden is that our approach uses a repository of cases, whereas the others are structured as an advice-giving systems. Part of the output of a domain analysis could be a structured set of questions leading to a piece of advice, but putting the knowledge in that form is labor-intensive, and it has been noted that some users prefer a more open-ended mode of interaction, especially when users want to find information on a subject area [32].

Much of the current research in software engineering and domain analysis is at least tacitly based on the dubious premise that principles and models are necessary to build artifacts. But scientific and engineering knowledge begins with observation and can only create models after testing a number of hypotheses. Bridge design and construction did not begin with a priori knowledge of statics and dynamics. Instead, theories of statics and dynamics were derived from experiences with real bridges. This approach brings the scientific method to software development. It can empirically help developers discover the intricacies of reuse in practice by collecting experience cases and providing tools to detect common patterns of problem solving activities that can lead to improved domain abstractions and software development tools.

Conclusions and Future Directions


To effectively support the knowledge-intensive activity of software development, a continuum of problem solving knowledge from informal how-to information to formal reusable frameworks needs to be collected and disseminated. Many kinds of knowledge, including how to make CASE tools work in the specific environment of an organization is necessary to make this work. To accelerate the process of turning this knowledge into formalized reusable assets, tools are needed that can support a domain lifecycle that takes an explicitly cross-project view of the issues and development problems that recur in an organization. Tools that collect and disseminate knowledge about specific problem solving episodes are a first and necessary step in this process.
Centering the information around a single repository through an ongoing process of capturing project experiences can prevent the duplication of efforts, avoid repeating common mistakes, and help streamline the development process. Similar projects have shown that such a system will be used by development personnel, provided it contains relevant, useful and up-to-date information [32].

Ongoing and future work is focusing on integrating the case-based repository into work practices and developing tools to support the domain lifecycle. We are working with a pilot project to refine our prototype and achieve a better understanding of the kinds of problems and issues that have organization-wide implications. We have also been investigating techniques that help domain analysts detect recurring patterns of development problems across an organization with the case-based repository [21]. Spreading activation [19] and analogy-based matching [11, 28] can be used to identify cases with potentially similar characteristics, but tools to support the creation of models and other domain-specific tools are needed. The process of synthesizing similar cases into knowledge that is applicable to a class of problems naturally supports the maturation of domain knowledge. The repository provides a comprehensive and convenient mechanism for performing the analysis. It is precisely this kind of support for domain analysis that is necessary to help accelerate the process of identifying and refining key domain knowledge.

A key question that exists for our work as well as work in the areas of domain analysis, design rationale, and organizational memory, is how the process of generating and using repositories of design information can be embedded in the everyday practice of software development so that the repository evolves with the ever-changing goals and accomplishments of the organization [32]. Our approach advocates using the repository to both track project progress and as an information resources to support design and decision making. Much more work is needed to accomplish this goal. We are approaching this problem in a user-centered or participatory design method in which we deploy prototypes to collect feedback and refine our model to fit the organization's needs. Successful deployment of this system will not only help the software development process at UPRR, but will provide a crucial first step toward better understanding the software development process and how it can be improved.

Acknowledgments. I gratefully acknowledge the efforts of Lynden Tennison and Jim Montequin at Union Pacific Railroad. I am also indebted to a number of graduate students, particularly Kurt Baumgarten, Shawn Clymer, and Kyle Haynes. This research is funded by the National Science Foundation (CCR-9502461), Union Pacific Railroad, and the Applied Information Management Institute in Omaha, NE.

References


[1] M.S. Ackerman, T.W. Malone, "Answer Garden: A tool for growing organizational memory," Proceedings of the Conference on Office Information Systems, 1990, pp. 31-39.

[2] G. Arango, "Domain Analysis: From Art Form to Engineering Discipline," Proceedings Fifth International Workshop on Software Specification and Design, Pittsburgh, PA, 1989, pp. 152-159.

[3] G. Arango, E. Schoen, R. Pettengill, "A Process for Consolidating and Reusing Design Knowledge," 15th International Conference on Software Engineering (ICSE '93), Baltimore, MD, 1993, pp. 231-242.

[4] B.H. Barnes, T.B. Bollinger, "Making Reuse Cost-Effective," IEEE Software, 8(1), 1991, pp. 13-24.

[5] V.R. Basili, G. Caldiera, G. Cantone, "A Reference Architecture for the Component Factory," ACM Transactions on Software Engineering and Methodology, 1(1), 1992, pp. 53-80.

[6] V.R. Basili, H.D. Rombach, "Support for Comprehensive Reuse," Software Engineering Journal, 1991, pp. 303-316.

[7] N.J. Belkin, W.B. Croft, "Retrieval Techniques," in Annual Review of Information Science and Technology (ARIST), vol. 22, M. E. Williams, Ed., 1987, pp. 109-145.

[8] T.J. Biggerstaff, "The Library Scaling problem and the Limits of Concrete Component Reuse," Third International Conference on Software Reuse, 1994,.

[9] F.P. Brooks, The Mythical Man-Month, Essays on Software Engineering. Reading, MA: Addison-Wesley, 1979.

[10] F.P. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, 20(4), 1987, pp. 10-19.

[11] P. Chaiyasu, G. Shanks, P. Swatman, "A Computational Architecture to Support Conceptual Data Model Reuse by Analogy," IEEE Seventh International Workshop on Computer-Aided Software Engineering - CASE '95, 1995, pp. 10-19.

[12] G. Fischer, A. Girgensohn, K. Nakakoji, D. Redmiles, "Supporting Software Designers with Integrated, Domain-Oriented Design Environments," IEEE Transactions on Software Engineering, Special Issue on Knowledge Representation and Reasoning in Software Engineering, 18(6), 1992, pp. 511-522.

[13] G. Fischer, A.C. Lemke, R. McCall, A. Morch, "Making Argumentation Serve Design," Human-Computer Interaction, 6(3-4), 1991, pp. 393-419.

[14] B. Gaines, "Social and Cognitive Processes in Knowledge Acquisition," Knowledge Acquisition, 1(1), 1989, pp. 38-58.

[15] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995.

[16] H. Gomaa, L. Kerschberg, "Domain Modeling for Software Reuse and Evolution," IEEE Seventh International Workshop on Computer-Aided Software Engineering - CASE '95, 1995, pp. 162-171.

[17] M.L. Griss, "Software Reuse: From Library to Factory," IBM Systems Journal, 32(4), 1993, pp. 548-565.

[18] S. Henninger, "Using Iterative Refinement to Find Reusable Software," IEEE Software, 11(5), 1994.

[19] S. Henninger, "Information Access Tools for Software Reuse," Journal of Systems and Software, 30(3), 1995, pp. 231-247.

[20] S. Henninger, K. Haynes, M.W. Reith, "A Framework for Developing Experience-Based Usability Guidelines," Proceeding of the Symposium on Designing Interactive Systems (DIS '95), Ann Arbor MI, 1995, pp. 43-53.

[21] S. Henninger, K. Lappala, A. Raghavendran, "An Organizational Learning Approach to Domain Analysis," Seventeenth International Conference on Software Engineering, Seattle, WA, 1995, pp. 95-104.

[22] C.F. Kemerer, "How the Learning Curve Affects CASE Tool Adoption," IEEE Software, 9(3), 1992, pp. 23-28.

[23] J.L. Kolodner, "Improving Human Decision Making through Case-Based Decision Aiding," AI Magazine, 12(1), 1991, pp. 52-68.

[24] J.L. Kolodner, Case-Based Reasoning. Morgan-Kaufman, San Mateo, CA, 1993.

[25] W. Kozaczynski, E. Liongosari, J. Ning, A. Ólafsson, "Architecture Specification Support for Component Integration," IEEE Seventh International Workshop on Computer-Aided Software Engineering - CASE '95, 1995, pp. 30-39.

[26] C.W. Kruger, "Software Reuse," Computing Surveys, 24(2), 1992, pp. 131-183.

[27] M.D. Lubars, "Wide-Spectrum Support for Software Reusability," in Software Reuse: Emerging Technology, W. Tracz, Ed.: IEEE Computer Society, Los Alamos, CA, 1988, pp. 275-28.

[28] N.A. Maiden, A.G. Sutcliffe, "Exploiting Reusable Specifications Through Analogy," Communications of the ACM, 35(4), 1992, pp. 55-64.

[29] W. Myers, "Taligent's CommonPoint: The Promise of Objects," IEEE Computer, 28(3), 1995, pp. 78-83.

[30] C. Potts, "Software-Engineering Research Revisited," IEEE Software, 10(5), 1993, pp. 19-28.

[31] M.A. Simos, "The Growing of an Organon: A Hybrid Knowledge-Based Technology for Software Reuse," in Domain Analysis and Software Systems Modeling, R. Prieto-Díaz and G. Arango, Eds.: IEEE Computer Society Press, 1991, pp. 204-221.

[32] L.G. Terveen, P.G. Selfridge, M.D. Long, "'Living Design Memory' - Framework, Implementation, Lessons Learned," Human-Computer Interaction, 10(1), 1995, pp. 1-37.

[33] L. Tetzlaff, D.R. Schwartz, "The Use of Guidelines in Interface Design," Proceeding of the Conference on Human Factors in Computing Systems (CHI '91), 1991, pp. 329-333.

[34] W. Tracz, Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Reading, MA: Addison Wesley, 1995.