Method Engineering

Traditional methodologies for information system (I.S.) development are—by nature—general purpose. As such, they contain an ideal set of methods, techniques, and guidelines that in reality can never be followed literally. They must be tuned to the situation at hand. Steps are sometimes omitted, added, or modified. Guidelines are often modified or ignored to fit special circumstances, such as technology, development expertise, the application, and external factors. [Harmsen, 1994]

The organizational structure has to do with human relationships, and is distinguished from the various artifacts (like information technology, systems development methods, and other mechanical products) that reflect those relationships. Information technology represents a first-level artifact and systems development methods represent a second-level artifact. This paper explains and illustrates a theory in which method engineering introduces third-level structural artifacts in organizations. A demonstration is included that uses security as one of the system imperatives that must be captured by third-level structural artifacts such as method engineering. This demonstration shows how method engineering may produce methods that are more complete and more harmonized with the organizational situation.

The relationship between project context and project situation is described by defining a number of contingency factors and components of a project approach. The applied contingency model is based on existing literature about situated method engineering. Relationships between contingency factors and the components of the project approach are analyzed for nine non-standard projects of the systems development department of a bank organization. The conclusion is that the choices of project managers concerning the project approach can be related to the project situation. The result of this research is a starting point for a contingency approach of information systems development projects in a bank.

In order to facilitate better Information Systems Development (ISD), Method Engineering technqiues and tools are needed that support flexible creation, modification, and reuse of ISD methods and tools for use on specific problem domains. A metamodelling notation is needed for specifying and integrating different design notations. MetaCASE support is required for building, reusing and evolving tools for these design notations. Process modelling tools for both the coordination of these design notation tools and the evolution of software processes are also needed. We describe our work on developing an integrated environment which supports metamodelling, metaCASE and flexible software process modelling, and illustrate its use for supporting Method Engineering.

CASE environments with method customisation capabilities and Computer Aided Method Engineering (CAME) environments have emerged during the last few years. While many research papers discuss the principles of method engineering and suggest requirements for new environments, we do not have critical evaluations of CAME environments using a wider method engineering framework. The aims of this study are twofold: 1) to build a preliminary framework for comparative studies of CAME environments, and 2) to increase the knowledge of the ‘state of the art’ in CAME by evaluating two CAME environments. We adapt a functional framework — originally built for CASE technology — to examine the following two research questions: How well can a method be defined in a CAME environment?, and How well is the defined method supported in a customisable CASE environment? The environments chosen for evaluation are Maestro II /Decamerone, and MetaEdit+. As an outcome, we will describe what framework aspects these environments support, and discuss the aspects not supported.

While the major aspect in method engineering is method assembly, a second aspect is the argumentation behind the methods. This paper introduces the concept of method rationale in method engineering and use as a communication vehicle between method and software engineers, and describes tools that support the capture and management of method rationale in a computer-aided method engineering environment.

Faced with the intensive business process reengineering activities in many companies, it is not surprising that the issue of process modelling has become a central concern. This paper shows that object-oriented system development methods can be applied to the field of business process modelling, but that certain steps are needed in advance. For example, it is necessary to compose a goal-means hierarchy, to establish necessary activities and roles, and to determine the input and output for each activity. In this paper, we examine step by step how business processes can be modelled, which data are needed for each step and which result would be produced during each step.

Computer systems are increasingly being used for communication and coordination of work, while object-oriented modelling techniques aim at modelling the problem domain of the computer system. Current techniques have been developed with respect to easy implementation, while we argue that further development of the modelling techniques should also be based on knowledge about human work in organisations.

We outline a learning cycle of modelling technique and point to where such knowledge should be included.

We have carried out two alternative approaches to development of object oriented techniques based on these ideas, and we outline these development processes. One approach is based on semiotic concepts, the other is based on activity theory.

This paper presents an automated transition from OMT* (a formal variant of OMT) towards SDL. This work is a partial result from a larger research effort proposing an integrated methodology and toolset based on the combination of Object-Orientation and Formal-Description Techniques. In this project OMT is used as the systems requirements analysis technique and OMT* for for System Design, while SDL (Specification Description Language) is targeted for the design phase. The transition from OMT to OMT* is manual process described by a set of guidelines (Holz et al. 1995) We developed a transformational semantic for OMT*, i.e. a set of transformation rules mapping OMT* constructs to SDL constructs. The translation from OMT* to SDL preserves the logical structure of the specification. This way it is possible to preserve the efforts done in the analysis phase and to make a smooth transition towards design.

This paper proposes the use of a lazy functional programming language, such as Miranda or Haskell, as embedded language in meta-CASE tools. Functional programming saves time and effort, because method engineers write programs on the appropriate level of abstraction, without any concern about the order of computations. As a consequence, method engineers build more reliable tools for application engineers to work with. The argument is exemplified by a meta-CASE program, which defines the well known Entity-Relationship modeling technique. Two different semantics are presented to demonstrate typical use: one is the transformation to a relational model and the other is SQL code generation. The full Haskell program to do this is presented, showing the conciseness and the simplicity of that program. This illustrates the type of programming that is done by a method engineer to specify customized modeling techniques. This paper is written for designers of CASE and meta-CASE tools. The work is also interesting for functional programmers who wish to see an appropriate application of lazy evaluation.

This paper describes a working strategy for software tool evaluations that has resulted from work within Rolls-Royce plc in response to the difficulty, and mixed successes, we have experienced in the selection of software tools. The lack of an acceptable methodology has meant that industrial evaluations are commonly time-consuming, fail to capture both tool and problem knowledge in a form suitable to aid future evaluations, and frequently give inconclusive results. Even where rigorous selection methods are used we raise the concern that tool evaluators are failing to address perhaps the most important factors in determining final success namely the non-technical or ‘soft’ factors.

In an attempt to overcome some of these problems the proposed strategy provides a qualitative list of important issues distilled from many years experience of making tool selection decisions. This generic issue checklist is used to form domain specific criteria against which tools can be compared in a more quantitative manner. This process ensures traceability between issues, tool requirements criteria and supporting evidence in order to document decisions and provide assurance that all issues have been addressed. It also helps us to capture valuable corporate knowledge for future evaluations in order to become more efficient at evaluating tools, provide more consistent criteria and to limit the risk of expensive mistakes.

An extendible CASE tools environment is currently being researched at the Department of Computer Science, University of Sheffield. This environment is designed primarily for developing parallel system software but is configurable for other applications. It requires an underlying generic data repository to represent information about the system under development in a consistent and complete form. The representation must be independent of the source, and intended use, of its data.

The paper starts by explaining the importance of a CASE data repository and the overall hierarchical structure of our repository data model. Then, it goes on to suggest a meta-meta data model for a generic CASE repository.

The new emerging method engineering discipline acknowledges the need for the construction of methods tuned to specific situations of development projects. This raises at least three problems (1) the representation of method fragments in a method base, (2) the formalization of the notion of project situation and, (3) the retrieval of relevant fragments for the project situation at hand. Our contribution to the first two of these problems lies in the definition of a contextual approach which enables us to represent both method knowledge (i.e. the method base contents) and method meta-knowledge (i.e. knowledge about the potential use of method fragments) as pairs of the form <situation, decision>. This emphasizes both engineering decisions and method engineering decisions, their rationale and situations of applicability. We contribute to the third problem by proposing a tight coupling of method knowledge and method meta-knowledge in the method base. This enables the formal description of the context of use of every method fragment and shall facilitate the retrieval of relevant fragments according to the situation of the project under development. The paper presents and exemplifies the method knowledge and method meta-knowledge levels.

Currently, several languages to represent and manipulate parts of IS engineering methods, techniques and tools are being used. These so-called Method Engineering languages can be classified into four categories: product-oriented, object-oriented, process-and decision-oriented, and hybrid. In this paper representatives of each of these categories are being reviewed. Meta-models of the languages are given, and each description is illustrated by an example specification. Focus of comparison is expressive power. The Method Engineering languages are compared on the basis of a number of requirements, which are deduced from the notions used in the Method Engineering domain.

This paper reports from a large Danish effort to engineer an object-oriented method for analysis and design of computer systems. Over a period of six years a method was developed based on new ideas on how to learn object-orientation supplemented with well-known ideas of how to work object-oriented in systems development.

The experience from this method engineering effort is interpreted as an iterative process involving elements of theory, method and case records. These elements played different roles when engineering the method. But, what is more important, they became key elements in structuring and presenting the method to practitioners and students of the field.

This particular method engineering effort has thus been governed by a paradigm for learning methods rather than a paradigm for working with methods. We discuss this paradigm by exploring three issues involved in method engineering: (1) the relation between learning the method and working with the method; (2) the role of principles, patterns, and guidelines in explaining the method; and, finally, (3) the relation between concepts for reflection and modelling and concrete representations used to create texts and diagrams.

We suggest that the primary customers of method engineering are those studying methods eager to learn a class of new systems development practices. Those actually working with the method should be thought of in a secondary role when structuring and presenting a new method — even though they are the ultimate judges of the method’s practical strengths and weaknesses.

The decentralization of organizations influences method engineering in two ways: Firstly, the distributed IS development process has to be supported by flexible, modular methods. Secondly, the interaction among methods and their users in the organizational network must be facilitated in order to ensure and improve process quality and efficiency. Our research starts from the observation that recent research in method engineering focusses on flexible, process-oriented integration of methods than on the organizational coupling of information flows between established methods that ensure high quality information exchange and continuous process improvement along feedback cycles. In order to show how organizational feedback cycles influence the efficiency and quality, we identified three kinds of information flows which can be categorized as task information, corporate memory and strategy information. Taking advantage of this categorization, we present a formal approach to method engineering in-the-large. This approach combines conceptual modeling of information flow models between federated methods and quantitative analysis of their short-term and long-term impacts on organizational performance by simulation. Technically, this is achieved by a two-fold application of meta modeling: firstly, to make short-term and long-term simulation techniques interoperate; and secondly, to link conceptual method models to the simulation models. These two links have been implemented in the MultiSim environment on top of the ConceptBase meta data manager. A case study that takes place in a setting of federated manufacturing methods shows how a change of methods influences the behavior of the overall company and how information flows along and across processes must be engineered to achieve a positive net outcome.

This paper first provides a historical perspective on approaches to developing information systems and argues that there are major weaknesses associated with the conventional waterfall model and the methodologies which followed. The paper suggests that a contingency approach to information systems development has much to offer and looks at Multiview, which is described as an exploration in information systems development. Some strengths and weaknesses of this contingency approach are highlighted and a new version of Multiview offered. This description enables a further discussion of information systems development and suggests that human and organisational aspect are at least as important as the technical ones which tend to be emphasised. Information systems development is seen as first a social process, though it will contain technical aspects. This social process is examined in more detail illustrating the arguments, for example, with different views of the systems analyst and the problem situation in this process. Such a broad approach also suggests that the area of which information systems development is a part, is multi-disciplinary where technology and computing are by no means dominant.

Although many conceptual frameworks for development and maintenance of information systems in organizations have been proposed, we experience a lack of integrated support of the evolutionary nature, the interconnectedness, and the social processes for developing such systems. This paper present a classification of methodological frameworks for evaluating important aspects of methodologies having this in mind. Contrary to most classification frameworks presented in literature which look solely upon different ways of supporting development of new information systems, we have in our framework a broader view, including larger parts of what we term computerized information systems (CIS) support in organizations.

In the end of the paper, we present the result of classifying a set of approaches to CIS-support in organizations described in academia and practice. No methodology is found to be sufficient in all respects, although newer approaches take more aspects into account.

In this study we investigate method engineering research by classifying studies into three contexts: technology, language and organization. Within each context we examine research bias, research outcomes and use of alternative research methods. This survey reveals the inherent bias of ME research towards tool and language development at the cost of empirical studies. We lack investigations of why organizations develop their own “variants” of system development methods, and how they manage their method engineering efforts. These observations lead us to suggest some directions for future research, which relate both to actual research questions and to the use of complementary research methods.

Is there a need for method engineering when only 20% of the developers perform modeling work? Is there a future for method engineering when the majority of practitioners subscribe to their “home-made” methods or methodologies during information systems development? These are the issues that will be discussed and argued during the panel.

Method Engineering is a topic of much research activity witness, for example, this conference. Much of the research focuses on contrasting and comparing various approaches, on repository design, or on design of Computer Aided Method Engineering (CAME) tools. Very little of the research focuses on whether methods are used or useful, let alone whether method engineering is used or valuable.