Beyond Process Modelling Languages: A Metamodelling Approach to Customizable Concepts and Enactability in MetaCASE Proposal for a licentiate thesis Minna Koskinen Department of Computer Science and Information Systems University of Jyväskylä P.O. Box 35, SF-40351 Jyväskylä, Finland
[email protected]
Abstract MetaCASE environments are emerging with support for method engineering and methods’ use. In this scope, also the importance of process engineering has been recognized and the research on methodical process support has started to seek appropriate forms. One of the problems faced in process support customization is the increasing variety of process modelling techniques and methods with extremely variating philosophical and conceptual approaches. Yet none of these approaches may be claimed superior of inferior to others in general. Since metaCASE environments should be designed to support a wide range of arbitrary methods, the conceptual coverage of process modelling language (PML) supported by a metaCASE environment needs to be exceptionally wide. In the thesis we claim that mechanisms for defining and modifying PMLs with different underlying orientations and conceptual foundations need to be developed in metaCASE environments. The main objective of the thesis is to investigate the possibility to apply metamodelling principles in defining situational process modelling languages for automated process support in metaCASE. The research questions addressed are (1) what alternatives there are for process support customization in existing process support environments and to what extend the solutions could be applied in metaCASE, (2) what concepts and tools are needed to define customizable PMLs and how they can be implemented in MetaEdit+, and (3) what kind of process enaction mechanisms are needed for the concepts and how they can be implemented in MetaEdit+. The proposed approach is further evaluated through defining an example PML. The research method is therefore constructive and the questions are addressed through an incremental and iterative cycle of theory building, system development, and experimentation.
1. Introduction and Motivation for the Research Area 1.1. Process Engineering in MetaCASE The introduction of methods into information system development (ISD) is an attempt to establish disciplined practices to overcome the maladies continuously afflicting the field. ISD methods include guidelines, procedures, techniques and tools for ISD based on a particular philosophy of system development and of a particular system domain [34]. They are expected to provide means for better understanding and producing the target system, managing the overall development effort, and to help in communication and organizational learning. A given method, however, is applicable only for certain purposes and yet tends to be more or less adapted into local practice in response to situation specific needs [25, 26, 33, 1] while adaptation may continue after method introduction as users’ understanding accumulates through actual use [12, 31]. The method adaptation is addressed by method engineering, which is the systematic and structured process of developing, modifying and adapting methods for ISD by describing the components of the method and their relationships [8]. Marttiin et al. [18] distinguish three main aspects of ISD methods that method engineering should or may address: the techniques used, the development process, and the organizational environment and group interactions. This information is captured in a method definition, which is composed of three separate yet tighly integrated models. The meta data model contains the specifications of techniques (such as of DFD, and ER) used in a method, i.e. the conceptual structure and notation for the IS models. The process model describes the procedural aspects of a method, like its stages, tasks, or steps, thereby defining how a variety of IS models are derived. The agent model defines the social and organizational environment in which the development group works. The approach is based on the assumption that concentration on each domain separately results in richer modelling support than if all the aspects are mingled together. Also, it is stated that process models and agent models are not always necessary nor desired to be addressed in method definitions. Within the scope of method engineering, process engineering thus denotes a disciplined activity that concentrates on analysing, defining, maintaining and assessing the process aspects of methods based on a certain process engineering method. Similarily to methods as a whole, no single process can be identified that is suitable to any ISD effort, but the process and hence also the respective support technology need to be tailored before it ‘fits’ a given engineering effort. This is a key feature for the practicality of process support in any environment since the users are unlikely to conform to a process model unless its use appears effective and convenient for them [29]. We see that the issues that process support concern and reflect are not as much simply technical procedures but practices deeply interwowen within the culture of a given ISD organization. Any process modelling
or overall process support approach is constrained by the stakeholders’ way of thinking, i.e. the way of perceiving ISD and by their understanding, assumptions and beliefs of the ‘essentials’ of processes and (thus) the ‘right way’ of modelling them, and is therefore also subject to change according to organizational learning. To enhance the applicability of methods in use, a multitude of method supporting CASE tools have been introduced. However, the drawbacks of the traditional CASE tools with “hard coded” methods have been widely recognized, e.g. the replacement of methods already deployed and the change of current working practices [1, 16, 28], users’ dissatisfaction and resistance [33], and the limited possibilities to assess and evaluate different methods to select suitable methods [2, 7]. From this standpoint there has emerged studies on metaCASE with the aim at constructing CASE tools with customizable method support [3]. With term metaCASE environment we denote a CASE environment where a set of metaCASE tools with customizable method support are used as CASE tools. A metaCASE environment also offers a suite of Computer Aided Method Engineering (CAME) tools to define and change the method support. The function of a metaCASE environment, therefore, is to support both system engineering and (incremental) method engineering. A major shortcoming of the early metaCASE environments is that they concentrate on the product aspects of methods [19] leaving process aspects without consideration. Most of these environments either provide no process support or impose a uniform, “hard-coded” way of development [20]. This is a tendency indicated to hold true also in recent practice [32]. The importance of tailoring process support for a specific method has been recognized [21, 17, 32] and the research has started to seek appropriate forms of methodical process support [9, 7, 24, 13].
1.2. Process Modelling Languages in MetaCASE A variety of techniques and methods for process engineering with related process support functionality have been introduced. These techniques and methods are based on extremely variating philosophical and conceptual approaches, yet none of the approaches can be claimed to be superior or inferior to others in general. On the contrary, different process engineering techniques and methods with different underlying approaches are likely to be applicable in different situations depending on a given development effort and the nature of development organization. The process modelling language (PML) used to represent process models together with the related process support reflects the perspectives and approaches taken on ISD and limit the aspects that can be captured during process modeling and during the actual process [4, 27]. Since the variety of techniques and methods proposed for process modelling is increasing and introducing ever more diversed set of concepts and structures with variations, the demands set for the conceptual coverage of a PML supported by a metaCASE environment are increasing as well.
In traditional process support environments the evolving language requirements are addressed through three alternative language architectures [30]. The first alternative is a single, semantically broad language that provides comprehensive and integrated syntax and semantics across multiple process aspects and subdomains. However, this kind of language needs to be extremely large and it is still unlikely to support all required aspects. The second alternative is to use multiple, independent and special-purpose languages. This approach in turn face problems concerning the issues of uniformity, understandability, and analyzability as a whole, as well as the interoperability between different languages and their respective models for e.g. control, data, and consistency. The third alternative is to use a common core language with specializable extensions. How to define the core language is still a problem, and whether a certain capability should belong to the core or to an extension. Also, translation between the core language and the various extensions is required. As Sutton et al. [30] further point out, each of these approaches seems plausible in principle but each also suffers from limitations and more work is warranted on all approaches. Due to the exceptional range of method alternatives, also the conceptual coverage of the PMLs used in metaCASE needs to be exceptionally wide. If applied in metaCASE, the approaches mentioned above suffer from even more severe limitations. Therefore, alternative approaches with mechanisms for defining process modelling languages with different underlying ways of thinking and conceptual foundations need to be developed in metaCASE. We further assume that not only process engineering is an incremental process that countinues throughout the actual development effort but also the process engineering techniques and methods including PMLs may and should be allowed to evolve throughout the development effort in response to learning. To summarize, easy and flexible ways are needed to define a diversity of new process modelling languages and to change and evolve the existing ones. This is found to be a proper (and challenging) approach for metaCASE research.
2. Research Objectives and Questions This study is part of research conducted in MetaPHOR project (University of Jyväskylä, Finland), the main goal of which is to develop architectures, models and technical solutions for user-tailorable metaCASE environments and principles for their effective use through method engineering. The project is developing a metaCASE environment, MetaEdit+, which is fully object-oriented [11] with all parts implemented in VisualWorks™/Smalltalk [23]. It is designed to support incrementally customizable methods based on metamodelling principles. The objectives of process support in MetaEdit+ are understanding and guidance of users and coordination of modelling tasks. The main difficulty faced in earlier studies concerning processes [17] is how to build process support for different projects by increasing the tailorability of a PML. Our aim is to design and implement a conceptual model and a related toolset to maintain flexible PMLs to
support the incremental customizability of process models and PMLs during process execution. Since the existing modelling capabilities cover large part of the requirements set on process models as well (i.e. they can be used for describing processes), we are especially interested in the possibility to apply metamodelling also in defining customizable PMLs. Extending these capabilities also to prescription/proscription of processes is, however, not a trivial task without at the same time making the PMLs in practice conceptually fixed. The enactability of process models designed using arbitrary PMLs further sets special requirements for the enaction mechanisms used in the support environment. The main objective of this thesis is thus to investigate the possibility to apply metamodelling principles in defining situational process modelling languages for automated process support in metaCASE. The research questions addressed are (1) what alternatives there are for process support customization in existing process support environments and to what extent the solutions could be applied in metaCASE, (2) what concepts and tools are needed to define customizable PMLs and how they can be implemented in MetaEdit+, and (3) what kind of process enaction mechanisms are needed and how they can be implemented in MetaEdit+. The proposed approach is further evaluated through defining an example PML. The study is constructive and it proceeds through an incremental and iterative cycle of theory building, system development, and experimentation [22]. Systems development is used to serve both as feedback and a proof-of-concept for the research as well as to provide a baseline for further research.
3. Thesis Contents and Contributions 3.1. Alternative Ways to Customize Process Support An obvious source of insights into methodical process support is the research on process support environments (PSEs), since these fields undeniably have much in common. However, the idea of basing a metaCASE solution strongly on approaches originally proposed for PSEs may justifiably be questioned. Instead of adapting formal approaches to specific contexts, the focus in metaCASE is on extending customizable process modelling scripts to support process automation. In the first paper we describe an investigation on different solutions for the customizability of process support in some PSEs as described in the literature [14]. The aim of the study was to gain insights into how a suitable solution could be realized in a metaCASE environment and to propose some guidelines based on the findings. In the following we present the study and some key findings relevant to our topic.
We based our framework on four main aspects of process support that are widely discussed in the literature as part of PSE architectures: the process definition, the process language (syntax and semantics) used in process definitions, the process engine used in interpretation and enaction of process definitions, and the tool functionality to which the process engine may interpret a process definition and which it can evoke. We further examined the customizability of each aspect in regard to four core architectural patterns frequently used in different aspect designs: composition of aspects, decomposition of aspects, the contents of components, and the structure of components. In addition to examining the individual aspects, we were also interested in different solutions for aspect integration in PSEs. We expect that aspect integration (both cross and within aspects) has a great influence on the overall process support customizability, but that it also contributes most to the features of PSEs that are not desired in metaCASE. In the PSEs reviewed, different aspects were often overlapping and not clearly distinguished as separate entities. All the aspects were addressed in form or another, but it was not always straight-forward to distinguish different architectural patterns. It is clear, however, that several alternative ways and combinations can be used to offer process support customizability but an attempt to address all possible ways to customizability lessens flexibility since it makes an environment too fragmented and complex to be managed easily. This applies also to aspect components. Finding a set of optimally primitive basic structures to design arbitrary structures both for components and constraints between them seems to be one key feature to flexibility. In the PSEs, process languages are managed either as built-in features of process engines or process chunks. Even if ‘new’ concepts can be defined they are mere labels on more specialized process chunks. A challenging alternative for metaCASE would be to externalize process language from the process engine and to use it as configuration data. A given process definition could then be enacted in different ways depending on the configuration and, moreover, a process engine could use several process languages as its configuration. The use of concept primitives and primitive interpreters is a likely means to achieve this, since such a solution would provide a process engine design without fixed semantics or process specific interpretation. We also detected a variating degree of semantic generality in language concepts, which implies that customization mechanisms to define constraints for internal integration of language concepts need to be evolved.
3.2. Concepts and Tools for Languages in MetaEdit+
Defining
Process
Modelling
We see a process as highly evolutionary and unstructural in nature, thus requiring the tailorability of not only process models but also PMLs. For this purpose, a metaCASE environment should provide primitives and tools for customizing process concepts for projects to adapt their own PMLs for designing enactable process models. In the first paper we introduce a metamodelling approach to PML
customization and introduce the process meta metamodel, GOPRR-p, and tools for modelling PMLs [15]. The approach supports graphical notation, customizable PMLs and process models, and the automated enaction of process models. The aim of our approach is to provide process models that are easy to understand, flexible and efficient for the user, and yet rich and precise enough to be enacted by the environment. Despite there are major differences between these processes that suggest incompatible requirements, a model prescribing a process should fully supply both the users and the environment when enacting the model. To overcome this problem, our approach perceives a computer aided modelling process fundamentally as a composition of two distinct but highly intertwined and interdependent processes: a user process and an environment process supporting the user process (see Figure 1). The former denotes the activities performed by a human and the latter denotes the actions performed by a CASE environment. We see that to achieve this in metaCASE it is necessary to distinguish the models and PMLs for prescribing these two and thereafter to find a way to flexibly but still effectively integrate them. User Process Human Agents
Environment Process Technical Agents
Figure 1. User and environment processes
As mentioned above, PMLs are defined by means of metamodelling process modelling techniques in our approach. GOPRR-p model designed during this study serves as the process meta-metamodel. GOPRR-p conceptualizes graphical, possibly imprecise and ambiguous user PMLs and formal, precise environment PMLs and enables their flexible integration so that process models can be informal, imprecise and ambiguous from the user point of view but also enactable by the environment at the same time. GOPRR-p consists of a set of primitive predefined metatypes and constraints between them. The metatypes are instantiated into abstract types (which are further subtyped) or types used in PMLs, i.e. PML concepts. The types are further instantiated to be used in process model templates and customized process models. An overview of GOPRR-p model is provided in Figure 2. An atomic fragment of process is seen as a combination of a process element and action. A process element (i.e. an instance of a process element type) specifies any fragment of a user process, such as a task or a deliverable. To specify how the environment is intended to support the process element, an action can be attached to it. An action type holds information on the tool type to be used, a message to specify the desired operation, and types of products to be operated on. This information is supplemented in a process model to identify the exact executable operation. The integration type that constrains the allowed action types is attached to a process element type: to an action of a certain type, based on a certain aspect,
or no constraints at all. This mechanism provides a possibility to vary the basis of integration and the level of semantic generality. In process models actions are integrated to process elements according to this constraint.
Figure 2. Overview of GOPRR-p model
Another point that is emphasized in our approach, is the dependencies between process elements. These are distinguished from process elements and specified using a binding, where a relationship involves a set of roles, which further are participated by a set of process elements. A relationship is a connection between a set of process elements. It implies that certain process elements are in some way dependent on certain other process elements. A role connects a process element to a relationship and defines how the process element takes part in the relationship. Configuration for enacting bindings (channeling) is provided in features of concept types. Each of the features define a specific aspect of environment behavior, and they jointly define how a specific kind of binding is channeled (i.e. enacted and controlled). Process element types specify how their instances are accessed by a user and whether they act as starting or ending points for enaction in a graph. Relationship types specify whether a binding is enacted mandatorily, optionally or conditionally, whether all preceding process elements are needed to proceed enaction, and whether all succeeding process elements should be activated. Role types specify the ‘direction’ to which enaction proceeds and whether a role initializes/finishes a single or parallel enaction sequence. Binding definitions can be further specialized through additional rules if necessary. A process model is composed of a set of graphs. A graph is a model of some restricted part of process. The graph structure is accomplished through bindings. Graph types integrate a set of concept types to be applied in process modelling and thereby form a process modelling language (process meta model). Also the allowable binding types and decomposition link types (process elements can be decomposed to other graphs) are defined within the scope of a graph type. Any of
the concepts a graph contains can be reused elsewhere. Properties are a means to store data (e.g. name, text field or number), reference to other objects, or store collections thereof in the concepts above. These may appear as textual labels such as name, text field or number. The PMLs are defined and maintained using process metamodelling tools, which are extensions of the method modelling tools in MetaEdit+ [17, 11]. These tools are used to produce user-defined types, which can be instantiated to enactable process models components. Being form-based, they aim at providing flexibility and ease of use in PML creation and management. PMLs can be defined from scratch, built from predefined components, or through reuse of existing structures. The specifications are directly compiled into the repository as separate components, which means that they (as well as any changes to them) can be immediately tested within the environment.
3.3. Enaction Mechanisms for Customizable PML Concepts The enactability of process models designed using arbitrary PMLs sets special requirements for the enaction mechanisms. In MetaEdit+ PMLs are externalized from the process engine and the actual process chunks by means of metamodelling and further used both as language definition to constraint process modelling and as configuration data for guiding the process engine. In the third paper we will describe how customizability and enactability aspects of process concepts are combined in MetaEdit+. The contribution of this paper will be the elaboration and implementation of enaction mechanisms that can use GOPRR-p based PML definitions as their configuration data. This means that process element types do not contain any process specific behavior as in existing extension based approaches. Instead, concept types hold information on controlling and enacting the bindings, i.e. they define how the concepts appear in process models and how they behave as an interface between the user and the environment. The action types provide a basis to activate tool functionality. The approach to process model enaction is heavily based on bindings. GOPRR-p does not handle bindings as part of process elements (e.g. preconditions and postconditions of activities) or as a single basic structure (e.g. a binary relation). Instead, a binding in GOPRR-p collects a set of process elements attaching them to roles, which are further attached to a relationship. Features of the concepts guide a process engine, which consists of a set of primitive interpreters distributed and attached along the bindings in process models. In this way, flexibility is achieved still leaving the concepts themselves untouched. Data contained by concepts are accessed or updated only if instructed by a process model or specified through channeling rules, which further specify the intended way of enaction. GOPRR-p allows extreme flexibility for process model enaction: due to late binding, parts of process models may be incomplete or even undefined when that particular part is encountered during enaction. In such a case, an ‘exception’ is raised and the necessary information is prompted from an authorized user. Also,
changes to both process models and PMLs can be made at runtime using only small local interruptions in the ongoing process if necessary. The implementation of GOPRR-p forces consistency on process models and PMLs at any time. The runtime consistency is preserved since the primitive process model structures are enacted at a meta level process which can manage any possible combination of features and channeling rules based on the current state of a process instance.
3.4. Evaluation of the Proposed Approach through Defining Example PML Concepts In the fourth paper we will evaluate the capabilities of GOPRR-p and the implemented process metamodelling tools by designing a variety of PML concepts in MetaEdit+. The concepts will be selected as sets from divergent PMLs so that they will act in their original context and represent different ways of thinking. The contribution of this paper is to offer (partial) proof-of-concept and to indicate limitations and further development needs of the proposed approach.
References [1]
[2]
[3]
[4] [5]
[6] [7]
[8]
Aaen, I., Siltanen, A., Sørensen, C., Tahvanainen, V.-P., “A Tale of Two Countries CASE Experiences and Expectations”, In: The Impact of Computer Supported Technologies on Information Systems Development (eds. Kendall K.E., Lyytinen K. and DeGross J.I.), Amsterdam, NorthHolland, 1992, pp. 61-93. Avison, D., and G. Fitzgerald, Information Systems Development: Methodologies, Techniques and Tools, Blackwell Scientific Publications, Oxford, UK, 1988. Bubenko, J.A. jr., “Selecting a strategy for computer-aided software engineering (CASE),” SYSLAB Report No 59, SYSLAB, University of Stockholm, June 1988. Curtis, B., Kellner, M.I., Over, J., “Process modeling”, Communications of the ACM, 35, 9, September 1992, pp. 75-90. Dowson, M., Fernström, C., “Towards Requirements for Enactment Mechanisms”, in Procs. of the Third European Workshop on Software Process Technology, (ed. B. Warboys), LNCS #772, Springer-Verlag, 1994. Fuggetta, A., “Functionality and Architecture of PSEEs”, Information and Software Technology, 38, 1996, pp. 289-293. Harmsen, F., Brinkkemper, S., Oei, H., “Situational Method Engineering for Information System Projects”, Procs. of the IFIP WG8.1 Working Conference CRIS’94, eds. T.W. Olle, and A.A. Verrijn Stuart, IFIP/NorthHolland, Amsterdam, The Neatherlands, 1994, pp. 169-194. Heym, M., Österle, H., “Computer-Aided Methodology Engineering”, Information and Software Technology, 35, 6/7 (June/July), 1993, pp. 345354.
[9]
[11]
[12]
[13]
[14] [15]
[16] [17]
[18]
[19]
[20]
[21]
Jarke, M., Pohl, K., Rolland, C., Schmitt, J.-R., “Experience-Based Method Evaluation and Improvement: A process modeling approach”, Procs. of the IFIP WG8.1 Working Conference CRIS’94, eds. T.W. Olle, and A.A. Verrijn Stuart, IFIP/North-Holland, Amsterdam, The Neatherlands, 1994, pp. 1-27. Kelly, S., Lyytinen, K., Rossi, M., “METAEDIT+ — A Fully Configurable Multi-User and Multi-Tool CASE and CAME Environment”, Procs. of 8th Int. Conf. on Advanced Information Systems Engineering, Heraklion, Crete, Greece, May 1996, eds. P. Constantopoulos, J. Mylopoulos and Y. Vassiliou, LGNS#1080, Springer-Verlag, Germany, 1996, pp. 1-21 Kelly, S., Tahvanainen, V.-P., “Support for Incremental Method Engineering and MetaCASE”, Procs of the 5th Workshop on the Next Generation of CASE Tools, Utrecht, The Netherlands, May 1994, ed. B. Theodoulidis, Memoranda Informatica 94-25, University of Twente, The Netherlands, 1994, pp. 140-148. Koskinen, M., “Designing Multiple Process Modelling Languages for Flexible, Enactable Process Models in a MetaCASE Environment”, Procs. of the 7th Workshop on the Next Generation of CASE Tools, Heraklion, Crete, Greece, May 1996, eds. A.-H. Seltheit and B.A. Farshchian, Norwegian University of Science and Technology, Trondheim, Norway, 1996. Koskinen, M., “Customizable Aspects of Automated Process Support: A Framework for Flexibility”, submitted for publication in 1997. Koskinen, M., Marttiin, P., “Process Support in MetaCASE: Implementing the Conceptual Basis for Enactable Process Models in MetaEdit+”, Procs. of the 8th Conference on Software Engineering Environments (SEE’97), Cottbus, Germany, April 1997, IEEE Computer Society Press, 1997. Loh, M., Nelson, R., “Reaping CASE Harvest”, Datamation, July, 1989, pp. 31-34. Marttiin, P., “Towards Flexible Process Support with a CASE Shell”, Procs. of 6th Int. Conf. on Advanced Information Systems Engineering, Utrecht, The Netherlands, June 1994, eds. G. Wijers, S. Brinkkemper, and T. Wasserman, LGNS#811, Springer-Verlag, Germany, 1994, pp. 14-27. Marttiin, P., Lyytinen, K., Rossi, M., Tahvanainen, V.-P., Smolander, K., Tolvanen, J.-P., “Modeling Requirements for Future CASE: Issues and Implementation Considerations”, Information Resources Management Journal, 8,1, Winter 1995, pp. 15-25. Marttiin, P., Rossi, M., Tahvanainen, V.-P., Lyytinen, K., “A Comparative Review of CASE Shells: a preliminary framework and research outcomes”, Information and Management, North-Holland, The Netherlands, 25, 1993, pp. 11-31. Merbeth, G., “Maestro II — das integrierte CASE-System von Softlab” (in German), CASE — Systeme und Verkzeuge, (ed. H. Balzer), BI Wissenschaftsverlag, Mannheim, Germany, 1991, pp. 319-336. Norman, R.J., Stevens, W., Chikofsky, E.J., Jenkins, J., Rubinstein, B.L., Forte, G., “CASE at the Start of 1990’s”, Procs. of the 13th Int. Conf. on Software Engineering, Austin, Texas, USA, March/April 1991, IEEE Computer Society Press, USA, 1991, pp 128-139.
[22] Nunamaker, J.F., Chen, M., Purdin, T.D.M., “Systems Development in Information Systems Research”, Journal of Management Information Systems, Winter 1990-91, 7, 3, 1991, pp. 89-106. [23] ParcPlace Systems, Inc., VisualWorks®: User’s Guide, Revision 1.0, ParcPlace Systems Inc., CA, USA, August 1994. [24] Pohl, K., Process-Centered Requirements Engineering, Research Studies Press Ltd., UK, 1996. [25] Pyburn, P., “Linking the MIS Plan with Corporate Strategy: An Exploratory Study”, Management Information Systems (MIS) Quarterly, June 1983, pp. 1-14. [26] Russo, N., Wynekoop, J., Walz, D., “The Use and Adaptation of System Development Methodologies”, Procs. of Int. Conf. of IRMA (International Resources Management Association), Atlanta, May 1995. [27] Sommerville, I., Kotonya, G., Viller, S., Sawyer, P., “Process Viewpoints”, Procs. of the 4th European Workshop on Software Process Technology, Noordwijkerhout, The Netherlands, April 1995, ed. W. Schäfer, LNCS #913, Springer-Verlag, Germany, 1995, pp. 2-8. [28] Smolander, K., Tahvanainen, V.-P., Lyytinen, K., “How to Combine Tools and Methods in Practice — a Field Study”, in LNCS, Second Nordic Conference CAiSE’90, (eds. B. Steinholtz, A. Sølvberg, L. Bergman), Stockholm, Sweden, May, pp. 195-211. [29] Stenning, V., “On the Role of an Environment,” in Procs. of 9th Int. Conf. on Software Engineering, 1987, pp. 30-34. [30] Sutton, S.M., Tarr, P.L., Osterweil, L.J., “An analysis of Process Languages,” CMPSCI Technical Report 95-78, Dept. of Computer Science, Univ. of Massachusetts, USA, August 1995. [31] Tolvanen, J.-P., “Incremental method development for business modeling: an action research case study”, in Procs. of 6th workshop on Next Generation CASE Tools, (eds. G. Grosz), University of Paris-1, 1995, pp. 79-98. [32] Verhoef, T.F., Hofstede, A.H.M. ter, “Feasibility of Flexible Information Modelling Support”, Procs. of 7th Int. Conf. on Advanced Information Systems Engineering, Jyväskylä, Finland, June 1995, eds. J. Iivari, K. Lyytinen, and M.Rossi, LNCS #932, Springer-Verlag, Germany, 1995, pp. 168-185. [33] Wijers, G., van Dort, H., “Experiences with the Use of CASE Tools in the Netherlands”, Advanced Information Systems Engineering, (eds. B. Steinholz, A. Sølvberg, and L. Bergman), LCNS #436, Springer-Verlag, 1990, pp. 5-20. [34] Wynekoop, J.D., Russo, N.L., “System development methodologies: unanswered questions and the research-practice gap”, Procs. of 14th Int. Conf. on Information Systems, (eds. J.I DeGross, R.P Bostrom, D. Robey), Orlando, USA, 1993, pp. 181-190.
