The literature suggests many approaches to analyzing and characterizing different facets of methods including their structure, content and use (e.g. Olle et al. 1982, 1983, 1986, 1988, Lyytinen 1986, Hackathorn and Karimi 1988, Wijers 1991, Blum 1994, Krogstie and Sølvberg 1996). These different categorizations are almost as numerous as the methods available. For the purposes of ME, we combine some of them which have been applied in ME research (Wijers 1991, Kronlöf 1993, Jarke et al. 1998) to analyze what type of knowledge ISD methods contain.

The categorization applied here is illustrated in Figure 2-2, whose shape leads us to call it a shell model. According to the model, methods are based on a number of concepts and their interrelations. These concepts are applied in modeling techniques to represent models of ISs according to a notation. Processes must be based on the concepts and they describe how models are created, manipulated, and used with the notation. The concepts and their representations are derived, analyzed, corrected etc. by various stakeholders. In addition, methods include specific development objectives about a ‘good’ IS, and have some underlying values, “weltanschauung” and other philosophical assumptions (Olle et al. 1991, Wijers 1991, Krogstie and Sølvberg 1996).

FIGURE 2-2 Types of method knowledge.

The shape of a shell emphasizes that different types of method knowledge are neither exclusive, nor orthogonal. Each type of knowledge complements the others and all are required to yield a “complete” method, although many methods focus only on the concepts and notations included in modeling techniques. To illustrate relationships between different types of method knowledge we can use the concept of functional decomposition as an example (cf. Table 2-1). In the procedural guidelines of Structured Analysis (DeMarco 1979) this concept is described as a top-down refinement of the system starting from the high level diagram. In the modeling technique this concept is implemented as the possibility for every process to have a sub-diagram, and in the balancing of the data flows between the decomposed process and its sub-diagram. The concept of decomposition also affects other method knowledge in several ways: the method should explain who identifies, specifies, and reviews decompositions; the partitioning of the system into a hierarchical structure dominates the design decisions and reveals the underlying assumptions of the method, i.e. that an IS can be effectively designed by partitioning the system based on its processes.

TABLE 2-1 Examples of method knowledge.

Because of these dependencies it is often impossible to focus only one type of method knowledge. For this thesis, this means that metamodeling the conceptual structures behind modeling techniques is not meaningful if other parts of the method knowledge are not considered. Similarly, it is not meaningful to use a modeling technique just to represent the designs if the underlying values or design objectives are not known. Therefore, when specifying functional decompositions we need to also consider aspects related to the process, or how various design alternatives can be sought using data flow diagrams.

Accordingly, in the following we shall analyze examples of method knowledge using the shell model. The analysis of method knowledge is based on the methods studied in Chapter 4 and on a method survey carried out by Tolvanen and Lyytinen (1994). The analysis allows us to understand methods in more detail as subjects of ME: the applicability of a method is determined partly by how well its specific composition of method knowledge is suitable for the ISD task at hand. By highlighting various aspects of methods, the shell model also provides a clear delimitation of the types of method knowledge that interest us (conceptual structures of modeling techniques). Consequently, the shell model is also applied in Chapter 3, where we inspect what types of method knowledge are addressed with available ME approaches.

During ISD it is impossible to analyze and represent the system to be built in its full richness. It is therefore necessary to restrict attention to a smaller number of concepts which are meaningful and sufficient to conceptualize and interpret the relevant parts of the object system. Such a conceptualization consists of a set of concepts, relationships between them and constraints applying to them, forming a conceptual structure.

The conceptual structure forms the basis for other types of method knowledge and therefore all ISD methods are based on a conceptual structure. Some of the concepts are applied directly in notations, e.g. a class with a rectangular symbol as in Rumbaugh et al. (1991), whereas some are related more to the process, e.g. a top-down modeling approach via decomposition; or to design objectives, e.g. clear responsibilities on data usage. Because of the importance of the conceptual structure most arguments supporting a specific ISD method deal with promoting specific concepts. Similarly, most research on method analysis and comparison (e.g. CRIS-conferences, Olle et al. 1982, 1983, 1986, 1988) focus mainly on the conceptual structures of methods. It must be noticed that while defining what aspects can and must be considered during ISD, the conceptual structure of a given method also excludes some other aspects as irrelevant. In this way methods can be seen as enforcing a particular world view via their conceptual structure (Welke and Konsynski 1980). The conceptual structures behind different methods differ for various reasons, but most importantly they vary because of differences in the domain, levels of rigor, and other types of method knowledge considered. These differences are described in the following.

First, because of different ISD contingencies, and differences in the systems being built (from business administration systems to automated robots), a variety of fundamental concepts exist. This is also one of the main reasons why so many methods have been developed. For example, methods which aim to develop single systems (e.g. Yourdon 1989a, Jackson 1976, Ross and Schoman 1977) include concepts such as local functions, data structures, data flows, control flows, and functional decomposition. Methods for managing system architectures (e.g. IBM 1984) focus on internal business processes, data sharing and access rights. Methods for business modeling (e.g. Vepsäläinen 1988, Ciborra 1987, Macdonald 1991) include concepts such as organizational structures and responsibilities, value adding, production and transaction costs (cf. Tolvanen and Lyytinen 1994).

Second, conceptual structures can differ based on their rigor and degree of formality. These explain how well and strictly the relationships between the concepts, constraints and verification rules are defined mathematically. Some less formal and general concepts of a method, such as flexibility in the face of business changes, e.g. in BSP (IBM 1984), are loosely related to other concepts of a method, whereas some other concepts can be defined in more detail. For example, SA/SD (Yourdon 1989a, p 278) defines that each process must be specified with a decomposition or process specification, but not with both. Typically, methods which focus on earlier phases of the ISD life-cycle, such as business modeling or requirements engineering, include less rigorous conceptual structures compared with methods targeted for later phases, such as software design. For example, in BON (Walden and Nerson 1995) the concept of a class is related closely to the equivalent concept applied in a specific object-oriented programming language called Eiffel (Meyer 1992). A more rigorously specified method leads to more uniform descriptions and process, but it will also limit the system developers’ freedom in method use situations by reducing the opportunities for contextual modification of the method.

Third, conceptual structures differ among methods in how they cover other types of method knowledge. For example, most methods, like UML (Booch et al. 1997), focus only on the concepts behind modeling techniques. In contrast, other methods like BSP (IBM 1984) also specify procedural guidelines, different user roles, and even state which kinds of deliverables are considered good. Thus, the conceptual structure of BSP also includes concepts which are related to other types of method knowledge, such as processes, participants and design objectives.

Concepts defined as part of the conceptual structure can be discussed and represented only by using some kind of a notation. In a modeling technique, a notation is always associated with a conceptual structure (cf. Figure 2-1). The association between notation and the conceptual structure defines the semantics of the notation. Notations can be characterized according to the degree of their underlying formal semantics into formal (logic, rules), semi-formal (structured and object-oriented methods), and free form (e.g. rich pictures in (Checkland, 1981)). The degree of formality reflects the underlying conceptual structure, and methods apply modeling techniques with different degrees of formality in different phases of the ISD life-cycle, typically moving from informal to formal (Pohl 1996).

To understand the method knowledge behind notations, its relation to the underlying conceptual structure must be clarified. This relationship is also called the conceptual-representational dimension (Smolander et al. 1990). Viewed from the notation point of view, each notational construct in a modeling technique must be related to some part of the conceptual structure. Ideally, each concept of the modeling technique has only one notational representation, e.g. a symbol. This principle minimizes the overload of notational constructs, and guarantees that all concepts can be represented in the technique. Accordingly, the completeness of representations (Batani et al. 1992, Venable 1993) or representational fidelity (Weber and Zhang 1996), i.e. availability of only one notational construct for each concept, is a well-known criterion for dealing with interpretations between modeling concepts and notations. For example, to describe classes, a modeling technique must have a related construct (i.e. apply the concept defined in the conceptual structure of the method) and define how it is represented (e.g. the “cloud” symbol in Booch (1991)).

From the conceptual structure point of view, each concept does not necessarily have a single notational construct, and may not be supported in the notation at all. The former can be characterized as construct redundancy and the latter as construct deficiency (Weber and Zhang 1996). Although these situations can be considered undesirable they are typical: notations are not necessarily designed to cover the whole conceptual structure, and object system characteristics can be represented by using several notational constructs and modeling techniques. Examples of the former are modeling techniques which apply only a subset of the concepts defined in the conceptual structure. For example, the graphical modeling technique EXPRESS-G is a subset of the EXPRESS language (ISO 1991). An example of construct deficiency is the concept of ‘object life-cycle’ which does not have any single modeling construct or notational symbol, but can be perceived from a state model of a class (i.e. through instances). Similarly, in BSP (IBM 1984) one key concept is to establish clear data responsibilities. During modeling this is achieved by allowing only one (or as few as possible) process to create a single data class. Therefore, a concept of ‘clear data responsibility’ can be represented only by perceiving the whole system architecture derived within BSP, as no single construct is available in the modeling technique to represent that notion. In fact, one can claim that ‘clear data responsibility’ is related to design objectives or to underlying values of the method but not to the modeling technique. Although this claim is true it must be noticed that the modeling technique and notation should also support modeling of data responsibilities. Otherwise, such a design objective can not be represented and alternative choices to achieve it can not be analyzed (Tolvanen and Lyytinen 1994).

Furthermore, all aspects of an IS can not be represented with one modeling technique, and so methods apply multiple techniques, sometimes even to the extent of using several techniques to describe the same aspect. Such different views can serve important goals including communication, analysis, understanding and prediction. As a result, a concept can be perceived in different ways via the different notations applied by different modeling techniques. Hence, construct redundancy is typical in a whole method because it allows the user to interrelate models.

First, different notations can be used to represent models based on the same conceptual structure or the same concepts. An example of the former can be found from UML (Booch et al. 1997) which applies two modeling techniques with different notations yet based on the same underlying semantics, namely an event trace diagram and a collaboration diagram. An example of the latter is the concept of a class which can be represented as a graphical rectangle notation in a diagram or as a string in a cluster chart table (e.g. Walden and Nerson 1995). Second, a notational element may be related to more than one construct of a technique. In this case, the interpretation of the notation depends on the context in which the notation is used. For example, a rectangle can represent an entity in the data modeling context, whereas it represents a terminator in the data flow view. Therefore, the relationship between conceptual constructs of modeling techniques and notations can be many-to-many. On the other hand, all modeling related concepts do not necessarily have notational constructs at all. In particular, concepts related to connections between models (and modeling techniques) are often defined weakly, if at all (Tolvanen and Lyytinen 1994), and thus often have no notation. For example, in most of the object-oriented methods it is difficult to notice from a state model which states belong to different objects (i.e. instances of a class). This limitation, of course, comes from the limitations of representation-related completeness (Venable 1993) and shows overload of notational constructs (Weber and Zhang 1996). In other words, the notation does not distinguish all parts of the conceptual structure.

Independently of the notation, modeling techniques can be classified according to their representation form, the type of format in which the model is represented. The most frequently used representation forms include graphical diagrams, which dominate most methods; matrixes, often used in methods for IS planning (IBM 1984, Andersen 1991); tables, mostly used in methods for early phases of ISD (e.g. Critical Success Factors (Rockart 1979) or Root Definition (Checkland 1981)), indented lists (Goldkuhl 1993); text related to other representations or as separate textual specifications (e.g. Class Description (Coleman et al. 1994), or mini-specs (Yourdon 1989a)) and hyper-text (Isakowitz et al. 1995). Independence of the notation means that the same model can be described in different representation forms but still have the same notational constructs. For example, a graphical data flow diagram can also be represented in a matrix, and the notation elements, e.g. symbols for processes, can be the same (Kelly 1997). The representation form also implies some mappings to a technique and its underlying conceptual structure: For example, a graphical representation with nodes and links implies that a conceptual structure distinguishes between objects and relationships. The modeling techniques analyzed in this thesis are mostly graphical, but include also matrix and tabular representation forms.

Method knowledge also covers procedural guidelines which describe how an ISD effort should be carried out. The process aspect of the method can be distinguished based on several criteria, but most often it includes modeling related processes (way of working) and management related processes (way of controlling, Olle et al. 1991). The former describes how the ISD method produces its results, the outcomes of the method use, and the latter how the project is planned, organized, and managed. For this thesis, the former is of greater importance, since it is related more closely to the modeling techniques studied here.

Based on our definition of a modeling technique, processes define in what order, and in what way the techniques are used to produce the desired models. To be useful, processes must be based on the conceptual structure of the method. For example, in SA/SD (Yourdon 1989a) a concept of decomposition is reflected in a modeling process as a top-down refinement of the system starting from the context diagram. The possibility to add one sub-diagram for every process must also be supported by the conceptual structure. In contrast, a conceptual structure can also restrict some selections to be made in process. For example, it can include some process-related rules, e.g. that every data flow diagram, except the context diagram, must have a higher level process defined.

The process aspect of the method, however, can not be found explicitly from every method. For example, methods may claim to cover the whole life-cycle of ISD, but actually they offer support for only a few tasks, and are based on limited views of ISD (Kronlöf 1993). The processes can be further divided into those which manipulate elements of the conceptual structure and those which manipulate notations (Lyytinen et al. 1998). Thus, the latter actions deal mostly with the “cosmetics” of the models, such as placing external entities on the border of data flow diagram, or placing super-classes above sub-classes.

ISD is a group activity in which multiple people participate in different roles, e.g. managers, programmers, designers, and end-users (Olle et al. 1991). Some methods also aim to describe these group aspects, such as organizational structures, responsibilities, and roles that the participating people have. For example, BSP (IBM 1984) defines the stakeholders and different roles needed to define system architectures.

It must be emphasized that most methods do not describe organizational structures related to method use or roles. In fact, most of the methods analyzed in Chapter 4 implicitly assume that they are used only by IS professionals, and mainly by analysts and designers. Partly the participation is implicitly defined according to the intended domain of use: methods which aim to develop a single system naturally have a more restricted set of stakeholders than methods which aim to manage multiple systems or re-design business processes (Tolvanen and Lyytinen 1994). Those which identify roles and other participation-related issues are usually tied to specific ISD tasks in which the participation of end-users or domain experts is important.

Methods are not only used to describe the current system, they also help to improve the current situation by carrying out the change process. To this end methods also describe how feasible specifications can be sought or alternative solutions generated (Tolvanen and Lyytinen 1994). This is based on the method’s implicit or explicit rationale on how a “good” IS should be developed.

Development objectives are general statements about types of solutions considered desirable, whereas development decisions are more explicit and closely related to method use. Examples of the former are the formulation of a system architecture so that it is flexible (e.g. IBM 1984), or re-designing business processes so that hierarchical structures are flattened (Hammer and Champy 1993). The latter are more concrete and describe how the objectives can be obtained. In IS integration methods (e.g. Kerner 1979, IBM 1984, Katz 1990) the main development decision is made based on the degree of (de-)centralization in the organization, and this choice then provides a basis for determining application boundaries. Some IS design methods recognize technical issues, such as hardware capacity, available database management system, and operating mode (Tolvanen and Lyytinen 1994), which should be considered while seeking design solutions.

Development objectives and decisions are related to other types of method knowledge. For example, it is hard to achieve an objective if it can not be perceived, represented and assessed within the method. Therefore, development objectives and decisions should be closely related to the process, notation and the conceptual structure. Sometimes the biggest differences between methods are found in the development objectives: the conceptual models can be partially or even totally alike, but the underlying development objectives can be different. For example, both architecture planning methods (Kerner 1979, IBM 1984, Katz 1990) and BPR methods (Harrington 1991) apply the same concept of a ‘business process’, yet architecture planning methods consider business process structures largely as immutable, while BPR methods aim to change them.

Unfortunately, the link between the objectives and notations and processes often remains unclear. It is rare that all important development decisions are described explicitly, and if described they relate to specific tasks considered problematic by the method developer. For example, Rumbaugh et al. (1991) describe four different approaches which could be chosen to create a schema for a relational database from class diagrams, mainly based on how an inheritance relationship should be transformed into a relational model.

Methods are always based on some underlying philosophical assumptions or “Weltanschauung”. These can also be called the “invisible” or “hidden” assumptions behind methods (Wijers 1991), or the way of thinking (Olle et al. 1991). For example, Krogstie and Sølvberg (1996) differentiate methods based on three views, constructivistic, objectivistic and mentalistic, based on how reality (in ISD the system to be developed) is observed and what kind of relationship it has with the models.

The distinction between development objectives and underlying values is important since many methods claim to have specific values, but they remain hidden in the method. Another situation is that two methods can aim for the same development objective but with different types of decisions and concepts. In fact, most of the methods do not explicitly define or even recognize the underlying assumptions.

In this section we described method knowledge using the shell model. The distinction of different types of method knowledge is relevant for our study to restrict our view of modeling techniques while seeing their role in context. This means that we can focus on those parts of the conceptual structure which are applied in IS modeling.

The shell model also emphasizes the dependencies between different types of method knowledge. Because of these dependencies it is impossible to focus on only one type of method knowledge. In this thesis this means that modeling of conceptual structures behind modeling techniques is not meaningful if other parts of the method knowledge are not considered. Most noteworthy is the conceptual-representational dimension: the dependency between a conceptual structure and a notation. While the notation itself is not one of our interests, the modeling of notational constructs is needed because both the development and use of modeling techniques is difficult without notations and representational forms.