Method Rationale in Method Engineering - CiteSeerX

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Method Rationale in Method Engineering Matti Rossi Helsinki School of Economics, P.O. Box 1210, FIN-00101 Helsinki, Finland, [email protected] Juha-Pekka Tolvanen Ylistönmäentie 31, FIN-40500 Jyväskylä, Finland,[email protected] Balasubmaraniam Ramesh Georgia State University, J. Mack Robinson College of Business, CIS Department, 35 Broad Street, Atlanta, GA 30341, USA, [email protected] Kalle Lyytinen, Janne Kaipala University of Jyväskylä, Department of Computer Science and Information Systems, P.O.Box 35, 40351 Jyväskylä, Finland, {klyytinen|jkaipala}@jytko.jyu.fi Abstract In this paper we discuss the need to integrate formal metamodels with an informal method rationale. Like design rationale method rationale establishes a systematic and organized trace of method specifications and their maintenance, and maintains knowledge of the method use context and its history. The need for method rationale is based on our observations of the role of method knowledge in software organizations and the failure to introduce "one-shot" method engineering initiatives. The paper demonstrates also how method rationale can be used to share knowledge of method use between method users and engineers, to support method engineers to understand the evolution of the method base, and to improve learning about systems development within a community of designers.

1 Introduction and Motivation Information systems developers face nowadays a pace of change never seen before. Just as we thought that object-oriented methods like OMT and OODA would be used for the rest of the millenium together with C++, we already see the appe arance of a new breed of “standard” OO methods (e.g. UML [1] and STEP [2]) and the flood of Java and visual programming environments. The simultaneous appearance of an abundance of new implementation techniques (e.g. web and mobile clients, group technologies and plug-in components to name a few) has resulted in a situation, where methods in use are outdated, or

provide a poor match with practices and platforms in use. So it is no wonder that as soon as the methods have been taken into use, a need arises to modify them for the situation at hand. In practice the use of methods is a complex and reflective endeavor, where the contents of the method, as well as its interpretations, change over time. The abundance of variants of UML for special purposes is a prime example of this kind of modification to contingencies of a given development situation. There are UML extensions for web site development [3] and component development (e.g. Catalysis). Contradictory to these claims method engineering (ME) as a discipline has matured mostly based on "one shot" approaches to method development (e.g. see [4] etc.), where “method cowboys” ride into the organization and develop a method and its use process and the users just perform the steps mentioned in the manuals. However, research shows that most of the ME processes are incremental in nature and they take place over a long period of time. In such a process, the ability to track changes is often lost. As the methods are a vital part of organizational memory we see the recording of method rationale as part of the ME effort crucial for the success of ME. We claim that to maintain organization's method knowledge and to keep track of changes in ISD practices organizations need to maintain Method Rationale (MR). Furthermore, the recording of changes and the rationale leading to them can act as a powerful change and learning agent, as the users can follow the reasoning behind the changes. Our message is that the

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

1

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

documentation of method rationale can lead to new ways of applying the method and can also provide new tools for communicating and learning the method. This paper is organized as follows: In the second section we introduce research challenges identified by previous research. In the third section we sketch the method development process and tools and show how they answer the questions raised in previous section. The next section provides a short example of the tools in use by modifying a support environment for parts of the UML method and recording the design rationale. In the last section we discuss the possibilities that this kind of environment offers for systems developers and outline some future research topics.

2 Method Engineering and Design Rationale In information systems development, the object of inquiry is the target system under development, whereas in method development or ME the object of inquiry is the software development process and its tools. These two processes can be separated in time and space as traditional method engineering literature assumes, or they can be partly coevolving and interdependent processes. An IS language provides a means and an environment for linguistic communication which encompasses the use, nature, content, context and form of signs included in the IS [5]. Similarly, Method Engineering languages are used to provide a means to specify, make explicit, codify, and communicate method knowledge. In order to model methods we thus need a set of concepts that is able to capture the content and form of a development method. Brinkkemper defines meta languages, according to van Gigch [6], as languages that capture the semantics of other languages [7]. In its simplest form, we can say that a metamodel is a conceptual model of a development method [7]. Consequently, metamodeling can be defined as a modeling process, which takes place on one level of abstraction and logic higher than the primary modeling process [6]. Every modelling process thus implies a metamodeling process because a metamodel captures concepts, representation forms, necessary to use a method. This part of method knowledge has been a subject of intensive research for quite some time [8]. In contrast, information about decisions that lead to a certain meta model, i.e. method rationale,

has been not so well codified in the past. When model change is continuous metamodels are modified and extended due to contextual needs. This amplifies the need to keep a track of changes in the metamodels, as, both formal metamodels and their informal “change histories” are needed to collect, structure and analyze experiences. They should thus increase the "fit" of the method into a given situation and ease its learning, and applicability. In the following we shall first clarify the idea of formal ME, and then discuss the concept of design rationale in the context of method engineering.

2.1 Traditional method engineering and the need for a new approach The dominant approach underpinning ME and most ISD methods can be characterized as what Schön [9] calls “technical rationality”: situations in practice can be scientifically categorized, problems are firmly bounded, and they can be solved by using standardized principles [10]. In fact, the main principle of method development can be said to be to provide knowledge about ISD, which is explicit and applicable for future ISD efforts. However, not all tasks of ISD fit into this view. In real world situations, it is not possible to have full knowledge about the problem (and thus the applicable method) beforehand, nor can predefined method knowledge cover all possible situations. Moreover, part of the knowledge related to ISD in general and to methodical knowledge in particular is tacit and thus can not be expressed. As a result, it is our belief that system development can not be completely carried out by following pre-defined methods. A new perspective to support method development is what Schön [9] calls “reflectionin-action”. Here, the fundamental assumptions are uniqueness of situations and tacit, intuitive knowledge [11]. Part of our knowledge of ISD is based on our reflection on the situations in which we find ourselves, rather than being bound solely by using predefined methods. Thus, methods need to be maintained based on reflections from practice, transforming tacit knowledge into explicit knowledge. On the other hand, all ISD efforts can not be carried out based on pure intuition and tacit knowledge. Therefore, we see the views of reflection-in-action and technical-rationality as complementary views of method development and use: both explicit and tacit knowledge are necessary and useful for successful ISD.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

2

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Accordingly, a good method should consider both aspects, on the one hand, providing knowledge, which can be rigidly followed as routines and on the other hand allowing human creativity and spontaneity. The second assumption of "situational method engineering" [12] is that the developer can obtain detailed knowledge about situation and thereby decide about the applicable method. This view expects that all “necessary” knowledge about the method, whether it is tacit or explicit, is available. In addition the adoption of methods as readily pluggable “routines” is seen to be relatively easy, and the method use is assumed to lead to processes which are repeatable. Accordingly, the key problem for IS developers would be to select the right method rather than how to use it! We question this by emphasizing that method use is a learning process in which the current level of expertise is crucial to successful ISD [13]. The learning process occurs at two levels; in the domain of IS, and in the domain of ISD. The former means learning about successful (or unsuccessful) ISs. The latter means that any organization that builds ISs, not only delivers systems  they also learn how to carry out ISD, and use associated knowledgge (methods). This means that during ISD an organization (or rather its members) gains experience about the method applicability. These experiences complement the method knowledge an organization already possesses and lead to new insights of its applicability and scope. This view has parallels with the process improvement movement (e.g. the repeatability and optimization of processes in CMM). Like Lyytinen and Robey argue [14] much of this organizational experience is currently lost because most of the experiences are never collected and made sense and organizations fail to use their internal experiences. They only live as "war stories" that are narrativised as part of the organizational culture. According to [15] contextual method development can be interpreted as a kind of double loop learning in which “error is detected and corrected in ways that involve the modification of an organization’s underlying norms, policies and objectives”. In the context of ISD the double-loop learning means modification and augmentation of the ISD methods. Because ME aims to improve ISD methods, it can be viewed as a learning process in which an individual [9], or even an organization [11], creates new knowledge about methods and how to apply them. Similarly, [16] have suggested that both the developer and user

learn through the dialectic approach, and Floyd [17] has advocated a second-order learning process in which past experiences are guidelines for using a method. The emphasis on learning is important in our discussion because it allows us to rationalize the maintenance of method rationale. Although experience is known to be crucial to ISD it is not easy to build up and maintain.

2.2 Design rationale in ME Where all current ME approaches fall short in this perspective is in the maintenance and analysis of different method versions. Typically, only the products of the design process are ‘documented’, not the process of arriving at design solutions. At the level of modeling decisions a variety of design rationale approaches have been proposed. They aim at recording the design decisions made using a predefined schema to represent the context in which these decisions are made [18]. Originally the decision-oriented models focused on decisions behind designs, not behind methods, e.g. why an inheritance between two classes is defined as virtual. Design rationale can be also used in two other ways, which are beneficial to ME: decisions related to method use and decisions related to method construction. An example of the former could be an IS developer’s justification why a concept of multiple inheritance is used in inheritance structures. Approaches of this type focus on decisions related to the ISD process. For example, [19] proposes a traceability model for tracing processes defined in a guidance model.

2.3 Support for learning and change using Method Rationale Instead of viewing methods as finished articles methods must be viewed from an evolutionary perspective. An indication of method evolution is that organizations must deal with different method versions, as for example with UML [1], introduce new method types, such as object-oriented methods, and abandon old methods which have been found inapplicable for new technologies and applications . Basically, two different types of evolution exist: those reflecting general requirements of technical evolution as well as business needs, and those relevant to the ISD situation at hand. The former deals with the general historical perspective and the latter with how these general

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

3

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

requirements are adapted into local situations and how they affect the method evolution. To achieve support for these we suggest tools that support method evolution by recording comments from method users that can lead to changes in methods as well as method development processes. This feedback loop from the users has been seen crucial for successful ISD [20].

2.4 Current situation in developing method rationale In practice, method rationale normally lies in the heads of the people who have developed methods and accompanying tools. Other method stakeholders such as method users cannot contribute to method construction because of communication problems related to time or place disjuncture observed earlier. As a result, important information is lost and the method and tool adaptation is typically done partially and in ad-hoc fashion. Essentially, there is a lack of tool support for collecting, integrating and organizing the rationale systematically. While some work on conceptual aspects of method rationale use is available, yet there is lack of a comprehensive review of the requirements needed for tool support. However, it has been stated that the rationale should be captured and integrated in designer’s natural usecontext [21], implying that capturing must be supported within method engineering and design tools. Overall, method rationale and method use experiences can be represented at different levels of formality. The most informal approach is considering rationale as a free form textual annotation (e.g. [22]), whereas more formality can be provided in approaches where design rationale is considered as an argumentation process organized into specific discourse structures (e.g. IBIS [23], DLR [24], QOC [25]). In available stand-alone systems for capturing design rationale (like gIBIS, [23], the fixed conceptual model of the argumentation structure is represented as a directed graph. Available functionality to analyze the argumentation structure includes manipulation of graph nodes and links and making queries of

node contents. However, the poor interoperability of these isolated systems constrains their usability in building method rationale. Within CASE tools, the design rationale implementations include both annotation and argumentation models for collecting rationale at the modeling level (e.g. [18, 26-30]). Yet, according to our knowledge, there is no tool support for collecting method rationale simultaneously at the level of method engineering tools. Consequently, tools provide no support to access comments of method use at the modeling level from within method modeling tools and vice versa. This, however, is critical for evolutionary method modification and use and the creation of the “double loop” method engineering life cycle.

3 Method modification lifecycle The data flow diagram below shows the steps of ME. These steps deal with gathering experiences, analyzing method use, and refining a method. They form an iterative cycle in which method improvements can take place gradually using method stakeholders’ experience (cf. [31]). Method selection is the process, where high level decisions about methods are made. The selection process has been discussed extensively elsewhere [4]. In short it deals with selecting an appropriate method for each IS development situation or project. In method construction, a metamodel makes method knowledge explicit. Metamodels provide a mechanism to collect and structure experience: method stakeholders’ comments, observations, and change requests can be related to the types and constraints of the method. For the analysis step, metamodels allow the detection of those parts of the method, which are subject to further analysis. As in method construction, alternative method refinements can be made and compared by using the metamodeling constructs. Processes 1 - 3 have been the focus of a lot of metamodeling and ME research in the past ten years. However, most of the previous literature has neglected method refinement and the collection of usage experiences.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

4

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

ME criteria

Method rationale

ME criteria on - contingencies - development problems - stakeholders’ values

method construction rationale

1

2 selected method

Method selection

characteristics

constructed method: - manuals - tutorials - etc.

3

Method construction

constructed method

Tool adaptation

Method components

available method specifications

ISD environment

method supporting tool

tool related specifications

CAME tool

CASE tool

ISD project

refined method

Method components

experiences 6 Method rationale

Rationale for refinements

Method refinement models and methods method changes

past construction rationale 5 ME criteria updated criteria

Analysis of method use

experiences

4 Collection of experiences

project outcomes

Figure 1. A data flow diagram specifying the incremental method engineering process We claim that the collection of experiences and incremental changing of methods based on these improves experience-based learning and the acceptance of methods. The accuracy of collected experiences is enhanced by relating experiences to metamodels and to the method construction decisions. Collecting models and metamodels, by collecting outcomes of an ISD project, and by interviewing stakeholders enhances the availability of method use experiences. The collection of models as deliverables is similar to the ideas proposed by Fitzgerald [32] and [33]. Collection of method design decisions has been briefly introduced in [29]. This research suggests that recording of method rationale should be such that the method development methods and tools can easily support it. Kaipala has suggested a set of tools, based on the well-known gIBIS model, for arguing about design decisions and collecting the experiences [34].

In addition to the model-based deliverables, the outcomes of the project are inspected. These deal with the results of the ISD process changing or improving the problem situation of the object systems. Typically a refinement demand becomes apparent from the modelers’ observations of the limitations of a method in use situations. In current method engineering tools there is no support for recording the use situations and the collection of experiences is largely done in ad-hoc fashion. We believe that availability of tools for this kind of commenting and reflecting-in-action would enhance the method development process and also contribute for the easier and more accurate collection of experiences and change requests. Each of the metamodel-based refinements can be operationalized through method construction. Tool and documentation re-adaptation is a necessity if a metamodel has changed. An improved method is not the only outcome of the

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

5

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

ME approach, because the evaluation allows the creation of new knowledge for future ME efforts. Based on current ME approaches this knowledge should be related to the ME criteria in two ways: to confirm or to reject the criteria used in the method construction, or to add totally new criteria. This means that method engineers should analyze the ISD environment continuously, not just for the initial method construction. Paradoxically, ME approaches, which aim to apply available frameworks of ME criteria have neither validated them nor considered how information about situational applicability is found.

3.1 Method rationale engineering process

in

method

Metamodels alone are inadequate to manage method refinements, because they can not explain the evolution of a method. Therefore we need method rationale. Method rationale occurs at two different levels depending on the users and the scope of the changes [19, 29]. For method engineers, method rationale is an explanation why certain types or constraints of the method are included in the constructed method. We call this method construction rationale. The use of method rationale during method construction requires that more detailed explanations of the reasons for building the metamodel in a specific way are related to

metamodel as a whole or to specific constructs. It helps in understanding the effects of method modifications: what capabilities are lost from the original method if a method element is removed or changed. It also makes argumentation about possible new method component types possible. Method users understand method rationale differently. For them method rationale explains why certain types or constraints of the method are or are not used in models. We call this method use rationale. The collection of method use rationale is important because it reduces the “subjective” bias in method use, makes a decision on method use more explicit, and allows users to relate their method experiences directly to available method knowledge. This is important, individuals have different goals and work histories, and therefore can have contradictory opinions of the necessity to use the method in a specific way. The rationale of method use, however, is not normally documented and to our knowledge none of the modeling tools allows the capture of decisions about method use; only decisions about design choices (i.e. design rationale [18]). In the following we will develop a simple metamodel based tool to support method rationale capture and argumentation about different design choices. The tool is implemented in MetaEdit+ method engineering tool and uses the REMAP model for capturing design decisions.

Object model

Name

decompose

Class name string

Attribute string

Unique id

Class

id Name

0,M

Attributes collection

0,M

Supercl ass 1,1

Attribute

Default value string

Data type string

Subclass

1,1

Inheritance

!

id

Discriminator string

Figure 2. Example of a method model

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

6

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

4 Example of method rationale In this section we develop an example of method modification and the use of method rationale in the process. We assume that UML method has been modeled previously by using MetaEdit+ tool. Now the users have raised the

issue that the current version of UML does not support code generation for Java well. We will elaborate the use of design rationale for solving this problem. Figure 2 shows a part of UML method definition using GOPRR metamodelling language. The model follows normal Role based entity modeling and should be self-descriptive.

Table 1. Symbols used in Method Rationale models Shape Oval Diamond Circle Rectangle Rectangle Rectangle

Shade White White White White Light gray Gray

Method Rationale Component Issue Alternative Argument Assumption Decision Artifact (e.g., method component) Allow multiple inheritance?

Responds To Responds To

Yes

No

Supports Supports

Better Support for Java and C++

Supports

Easier to understand

Better support for Smalltalk

Resolves

Qualifies

Java is the mainstream now Add Multiple Inheritance Depends On Defines Java will dominate over better langs (i.e. Smalltalk)

New OO Method

Figure 3. Rationale for multiple inheritance

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

7

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

We also assume that the method has been used for sometime and now some designers have questioned the validity to use single inheritance. This is indicated by the exclamation mark below the inheritance relationship. The exclamation mark serves here as an anchor point, where from one can jump to the design rationale document dealing with this method engineering decision. The resulting design rationale is shown in figure 3 below. Here, the REMAP model [18] has been used to represent rationale. REMAP extends the Issue Based Information Systems (IBIS) framework for modeling argumentation processes [23]. In REMAP, issues represent questions or concerns of interest to ME. Alternatives or positions represent different ways of responding to an issue. Arguments that either support or oppose these alternatives are also clearly identified. In addition, any assumptions behind the above primitives are also explicitly captured to represent the comprehensive context under which decisions are made. Decisions select one or more alternatives to resolve the issue at hand. The REMAP model has been successfully used in a wide variety of complex organizational problem solving situations and has been incorporated in several CASE tools [35]. In Figure 3 the design rationale is represented as issues, arguments and decision about the use of multiple inheritance. This small example reveals the gap between currently proposed ME criteria and their linkages to detailed metamodels: none of them support relating situational requirements to individual types or constraints of a method. Some of the ME approaches (e.g. [4, 36]), however, support relating information about method use situations and contingencies to metamodels based on predefined schemata. These approaches, however, do not explain how these more detailed descriptions are obtained, nor are they related to detailed metamodels.

5 Discussion and Conclusions Method Rationale can act as a powerful mechanism to maintain systems development knowledge in an organization. In most cases every time a method is changed, or new technology is introduced, most of the knowledge relating to the old version or the need for a change is lost. Yet, when method rationale is maintained, it can provide guidance for future decisions and aid new method users to become familiar with the method. Regular method users can also benefit from this

kind of method knowledge, because it makes the peculiarities and limitations of the method more understandable. If method rationale was routinely recorded and could be used easily while using the method, it could aid in a dialectical exchange of ideas for modifying the method and thus improving the ISD process. This should be useful for example for organizations that aim at a continuous development of their ISD processes and tools and who want to learn from their experience [14]. Comprehensive representation of knowledge about MR requires that some components of this knowledge be formally specified and linked to informal knowledge components that are unsuitable for formal representation. Management of such process knowledge requires facilities for constructing, querying and maintaining structured knowledge bases. A MR tool that provides automatic inferencing to enable access to the knowledge and maintain the integrity of the knowledge base made up of interdependent components that get incrementally defined and modified be of much value. Such inferencing will be aided by mechanisms for aggregation, classification and generalization of knowledge components. As the overhead involved in capturing MR knowledge, is a genuine concern, mechanisms to support automated collection and use of this information will be very valuable. For example, mechanisms to maintain and manage dependencies among various components of MR and artifacts would be very valuable. Such a network can be used to readily identify appropriate method components for a given situation or to alert the method users about the changes in the situation that necessitates reexamination of the methods. A hypermedia interface for browsing the contents of the knowledge base will be useful to provide easy access and user friendly presentation. Further, a concept map that visually depicts the relationships among informal knowledge components would facilitate navigation through related fragments of knowledge. There are negative sides to such tool support. One of them is that it increases the work that is not seen as directly “productive” and therefore such traces are not necessarily easily recorded. Such changes can also be objected based on the fact that they demand designers to expose their internal knowledge and working habits to the larger community of practice. This may demand changes both in the incentives and culture of the development organizations as well as in

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

8

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

organizational processes. Clearly there is room for empirical research on this important topic and we are planning to engage ourselves in such initiatives. As mentioned earlier, a basic premise of our research is that method engineers and method users can be supported in their tasks with MR information. Services that could be provided to support these groups include facilities for easy capture of MR knowledge, evolution of methods with changing situations (represented as say, changes in assumptions), replay of method construction and use, and dependency management.

[13]

[14]

[15]

References

[16]

[1] Rational Software Corporation, “UML Document Set,” , 13 January, 1997 ed. http://www.rational.com/uml/references/index.html : Rational Software Corporation, 1997. [2] B. Henderson-Sellers, “OPEN Modelling Language (Light notation) Version 1.0,” , 5.2.1997 ed. http://www.csse.swin.edu.au/cotar/ OPEN/shortnotation.html: Swinburne University, 1997. [3] J. Conallen, “Modeling Web Application Architectures with UML,” Communications of the ACM, vol. 42, pp. 63-71, 1999. [4] F. Harmsen, “Situational Method Engineering,” in Dept. of Computer Science. Twente: University of Twente, 1997, pp. 310. [5] K. Lyytinen, “Different Perspectives on Information Systems: Problems and Solutions,” ACM Computing Surveys, vol. 19, pp. 5-46, 1987. [6] J. v. Gigch, Systems design and modeling and metamodeling. New York: Plenum Press, 1991. [7] S. Brinkkemper, “Formalisation of Information Systems Modelling,” in Computer Science Department. Amsterdam: Univ. of Nijmegen, 1990. [8] J.-P. Tolvanen, M. Rossi, and H. Liu, “Method Engineering: Current Research Directions and Implications for Future Research,” in Method Engineering, Principles of Method Construction and Support, S. Brinkkemper, K. Lyytinen, and R. Welke, Eds.: Chapman-Hall, 1996, pp. 296-317. [9] D. Schön, The Reflectice Practitioner. New York: Basic Books Inc., 1983. [10] J.-P. Tolvanen, “Incremental Method Development for Business Modelling: An Action Research Case Study,” presented at 6th Workshop on the Next Generation of CASE Tools, NGCT'95, Paris, 1995. [11] I. Nonaka, “A dynamic theory of organizational knowledge creation,” Organization Science, vol. 5, pp. 14-37, 1994. [12] F. Harmsen, S. Brinkkemper, and H. Oei, “Situational Method Engineering for Information

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

System Project Approaches,” in Methods and Associated Tools for the Information Systems Life Cycle (A-55), A. A. Verrijn-Stuart and T. W. Olle, Eds.: Elsevier Science B.V. (North-Holland), 1994, pp. 169-194. J. Hughes and E. Reviron, “Selection and evaluation of information system development methodologies: The gap between the theory and practice,” in Lessons learned from the use of methodologies, N. Jayaratna and B. Fitzgerald, Eds., 1996, pp. 309-319. K. Lyytinen and D. Robey, “Learning Failure in Information System Development,” Information Systems Journal, vol. 9, pp. 85-101, 1999. C. Argyris and D. Schön, Organizational Learning, A theory of action perspective: Addison-Wesley, 1978. B. Curtis, H. Krasner, and N. Iscoe, “A field study of the software design process for large systems,” Communications of the ACM, vol. 31, pp. 12681287, 1988. C. Floyd, “Outline of the paradigm change in software engineering,” in Computers and Democracy: A Scandinavian Challenge, G. Bjerknes, P. Ehn, and M. King, Eds. Brookfield Vermont: Avebury Gower, 1987. B. Ramesh and V. Dhar, “Supporting Systems Development by Capturing Deliberations during Requirements Engineering,” IEEE Transactions on Software Engineering, vol. 18, 1992. M. Jarke, K. Pohl, C. Rolland, and J.-R. Schmitt, “Experience-Based Method Evaluation and Improvement: A Process Modelling Approach,” in Methods and Associated Tools for the Information Systems Life Cycle (A-55), A. A. Verrijn-Stuart and T. W. Olle, Eds.: Elsevier Science B.V. (North-Holland), 1994, pp. 1-27. G. J. Hidding, J. K. Joseph, and G. M. Freund, “Method Engineering at Andersen Consulting: Task Packages, Job Aids and Work Objects,” in 2nd International Summerschool on Method Engineering and Meta Modelling conference binder. Enschede, the Netherlands: Univ. of Twente, 1993. G. Fischer, A. G. Lemke, R. McCall, and A. I. Morch, “Making Argumentation Serve Design,” Human-Computer Interaction, vol. 6, pp. 393-419, 1991. B. Reeves and F. Shipman, “Making It Easy for Designers to Provide Design Rationale,” presented at AAAI’92 Workshop on Design Rationale Capture and Use, San Jose, CA, 1992. J. Conklin and M. L. Begeman, “gIBIS: A Hypertext Tool for Exploratory Policy Discussion,” ACM Transactions on Office Information Systems, vol. 6, pp. 303-331, 1988. J. Lee, “A Qualitative Decision Management System,” in Artificial intelligence at MIT: Expanding Frontiers, P. Winston and S. Shellard, Eds.: MIT Press: Cambridge, Massachusetts, 1991.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

9

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

[25] A. MacLean, R. Young, V. Bellotti, and T. Moran, “Questions, Options, and Criteria: Elements of A Design Rationale for User Interfaces,” Journal of Human Computer Interaction, vol. 6, pp. 201-250, 1991. [26] J. Bigelow, “Hypertext and CASE,” IEEE Software, vol. 14, pp. 23-27, 1988. [27] J. L. Cybulski and K. Reed, “A Hypertext-Based Software Engineering Environment,” IEEE Software, vol. 18, pp. 62-68, 1992. [28] K. Pohl, R. Dömges, and M. Jarke, “PRO-ART: PROcess based Approach to Requirements Traceability,” in Poster Outlines: 6th Conference on Advanced Information Systems Engineering, Utrecht, Netherlands, June 1994, 1994. [29] H. Oinas-Kukkonen, “Method Rationale in Method Engineering and Use,” in Method Engineering, Principles of Method Construction and Support, S. Brinkkemper, K. Lyytinen, and R. Welke, Eds.: Chapman-Hall, 1996, pp. 87-93. [30] JinXiang and Griggs, “A Tool for Hypertext-based Systems Analysis and Dynamic Evaluation,” presented at The 27th Annual Hawaii International Conference on system Sciences, Hawaii, 1994. [31] P. B. Checkland, Systems Thinking, Systems Practice. New York: J. Wiley, 1981. [32] G. Fitzgerald, “Validating new information systems techniques: a retrospective analysis,” in Information Systems Research: Contemporary Approaches and Emergent Traditions, H.-E. Nissen, H. K. Klein, and R. Hirschheim, Eds.: Elsevier Science Publishers B.V., 1991, pp. 657672. [33] M. Schipper and S. Joosten, “A Validation Procedure for Information Systems Modeling Techniques,” presented at Workshop of Evaluation of Modeling Methods in Systems Analysis and Design EMMSAD'96, 1996. [34] J. Kaipala, “Augmenting CASE Tools with Hypertext: Desired Functionality and Implementation Issues,” presented at Advanced Information Systems Engineering, Barcelona, Spain, 1997. [35] B. Ramesh and M. Jarke, “Towards Reference Models for Requirements Traceability,” IEEE Transactions on Software Engineering, vol. fortcoming, 1999. [36] M. Heym, “Methoden-Engineering Spezifikation und Integration von Entwicklungsmethoden für Informationssysteme,” . St. Gallen: Hochschule St.Gallen, 1993.

0-7695-0493-0/00 $10.00 (c) 2000 IEEE

10