The need for systematic principles to develop situation-specific methods has led to the emergence of method engineering (Bergstra et al. 1985, Kumar and Welke 1992). In a similar vein to ISD, we define method engineering (ME) as a change process taken with respect to an ISD object system in a set of ISD environments by a method engineering group using a metamethod and supporting tools to achieve or maintain methods for ISD. Figure 3-1 illustrates the relationship between method engineering and ISD. In the following we describe this relationship and define ME in more detail by explaining each italicized key concept of the definition.

FIGURE 3-1 Method engineering and information systems development.

Both ISD and ME are social processes, in which a number of people act and have an interest. At the level of ME, method engineers form a group which perceives the current state of ISD. They are in charge of defining, choosing, modeling and producing method specifications and customizing tools in a similar way to the ISD group creating IS specifications and implementing them. This also distinguishes method engineers from researchers, since the latter are more interested in studying methods (even with metamodels and metamethods) rather than implementing methods for the organization. Method engineers can therefore be considered as developers of ISs for ISD. Often they can be the same group as those carrying out ISD. Furthermore, because the end-users of ISD applications include ISD professionals, they can be expected to be more aware of technical possibilities and thus more demanding than end-users of other type of ISs. This partly explains the importance of stakeholder value based ME (Kumar and Welke 1984, 1992) which emphasizes the role of method users in ME efforts. By stakeholders we mean people who have an interest in method development and method use. These include method experts, tool experts, managers of ISD, IS developers, and IS users. Studies in ME, however, have so far concentrated on developing concepts and principles for ME (Brinkkemper 1990, Heym and Österle 1992), whereas only a few discussions (see e.g. Bubenko 1988, Tagg 1990, Nissen 1996) study the role of method engineers and other stakeholders.

Both ISD and ME aim to deliver an IS, often a computerized one. Method engineers carry out a change process resulting in methods and tools which support some tasks of ISD. An example of such a system is a CASE tool customized to support a specific method. During the ME process, a method, or its part, is created, modified, and removed to achieve or improve situation-specific methods. Thus, the goal of ME is to improve ISD by providing better methods and supporting tools. In the ME literature situation-specific needs are understood as a closer relationship between the method and the characteristics of ISD situations (Vlasblom et al. 1995), required problem solving capabilities (Punter and Lemmen 1996), or stakeholders’ values (Kumar and Welke 1984, 1992). The “better” in turn implies that the constructed method can be compared in detail with other alternative situation-bound methods or their parts. Each of these approaches to achieve the objectives related to methods is discussed in more detail in the next section.

Both ISD and ME can be supported by methods. To differentiate methods between these two levels we use the prefix meta to denote methods and tools at the metalevel, e.g. metamethods, metamodeling and metaCASE. This distinction is also important for this thesis since we focus on studying ME rather than ISD. Like ISD methods, metamethods can be viewed through the taxonomy of method knowledge (cf. Section 2.2). First, a conceptual structure of a metamethod includes concepts specific for engineering ISD methods. Second, the specifications of an ISD method are communicated with a metamodeling notation. Together, the metamodeling concepts and notation form a metamodeling language. As in the term metamethod, the prefix “meta” means that the metamodeling language represents parts of the ISD method in terms of a model of a method, i.e. a metamodel (Brinkkemper 1990, van Gigch 1991). Third, a metamethod includes procedures for metamodeling and constructing methods, and a set of criteria to meet the situational requirements of methods. However, other types of knowledge necessary to carry out ME supported by a metamethod, like the participation and different roles, have been studied far less in ME literature (cf. Tolvanen et al. 1996).

Like ISD, ME too can be supported by tools. This symmetry has introduced the term CAME, Computer Aided Methodology Engineering (Kumar and Welke 1992) to highlight the role of tools in ME. In this thesis we regard the supporting tools of method engineers as metaCASE tools (Kelly 1997), also called metasystems (Sorenson et al. 1988), or CASE shells (Bubenko 1988). These tools offer facilities to tailor CASE tools to specific methods.

Finally, an ME process is not performed just once because the ISD environment changes. This is emphasized in the definition by the inclusion of the maintenance of methods into ME. The environment also includes stakeholders, who have different, changing, or even conflicting objectives. For example, developers can require methods which minimize errors in a developed IS, managers want the method to improve productivity, and IS users want understandable design documents. The changes and experiences of the method’s use raise new requirements for methods and their tool support. As a result, a method constructed at one point of time is not necessarily applicable in the next similar project, or even later in the same project. Therefore, methods have to be maintained and revised. This observation leads to an evolution-based approach where methods are developed incrementally for local and changing needs.