We define ISD as “a change process taken with respect to object systems in a set of environments by a development group using tools and an organized collection of techniques collectively referred to as a method to achieve or maintain some objectives” (Welke 1981, Lyytinen 1987). ISD is understood to include development of both manual and computerized parts of an object system. An IS can therefore include both manual and computer-supported parts. Although the definition emphasizes essential components of ISD, such as its social nature and varying objectives, in this thesis we shall mainly focus on the italicized parts of the definition, i.e. on the role of methods and techniques, and their supporting tools.

By a technique we mean a set of steps and a set of rules which define how a representation of an IS is derived and handled using some conceptual structure and related notation (Smolander et al. 1990). Olle et al. (1991) and Wijers (1991) call this knowledge a way of modeling. This definition is illustrated in Figure 2-1. By using a technique, system developers perceive, define and communicate on certain aspects of the current or desired object system. These aspects are defined by the conceptual structure of the technique and represented by the notation. By a tool we generally mean a computer-based application which supports the use of a modeling technique. Tool-supported modeling functionality includes abstraction of the object system into models, checking that models are consistent, converting results from one form of model and representation to another, and providing specifications for review (Olle et al. 1991).

Examples of modeling techniques are data flow diagrams and activity models. Other techniques can be found from Table 4-1. As a technique, a data flow diagram identifies and names the objects (e.g. process, store) and relationships (e.g. data flow, control flow) which it considers important in developing an IS. Other techniques include other sets of objects and relationships. Modeling techniques also have a notation and a representation form. In a data flow diagram the notation for a process is a circle, and for a data flow a solid line with an arrow-head. The representation form of a data flow diagram is a graphical diagram. Furthermore, a technique defines some principles on how the models should be derived (e.g. decomposition of processes while modeling with data flow diagrams). In other words, a modeling technique specifies which kind of aspects of an object system need to be perceived, in what notation each aspect is represented, and how such representations should be produced.

A method can be considered as a predefined and organized collection of techniques and a set of rules which state by whom, in what order, and in what way the techniques are used (Smolander et al. 1990)[8] to achieve or maintain some objectives. In short, we call this method knowledge. Thus, our definition of method includes both the product and process aspects, although dictionaries define the term “method” as meaning “the procedure of obtaining an object” (Baskerville 1996) and therefore emphasize the process rather than the representation (i.e. product of the method use). In contrast, Wijers (1991) notes that most ISD method text-books focus on feasible specifications rather than on the process of how to develop such specifications. In addition, a method also includes knowledge about method users, development objectives and values. We will analyze the types of method knowledge in more detail in the next section.

Examples of methods include Structured Analysis and Design (SA/SD, Yourdon 1989a), and the object-oriented methods of Booch (1991) and Rumbaugh et al. (1991). A short example of method knowledge is in order. The method knowledge of SA/SD can be discussed in terms of the techniques (e.g. data flow diagram, entity-relationship diagram) and their interrelations. In SA/SD the overall view of the object system is perceived through a hierarchical structure of the processes that the system includes. This overall topology is completed by data transformations; how data is used and produced by different processes, how it is transformed between processes, and where it is stored. Moreover, the data used in the system needs to be defined in a data-dictionary and interrelations between data need to be specified with entity-relationship diagrams. Thus, methods describe not only how models are developed but also how they are organized and structured. Furthermore, since ISD methods aim to carry out the change process from a current to a desired state they should also include knowledge for creating alternative design solutions and provide guidelines to select among them (Tolvanen and Lyytinen 1994).

FIGURE 2-1 The role of methods in ISD (based on Lyytinen et al. 1989).

SA/SD and other methods put forward a defined and a limited number of techniques including their conceptual structures and notations. In the same way as there is variety in techniques, there is also diversity among methods (Welke and Konsynski 1980). Different methods include different types and sets of techniques. Interrelations between techniques can be defined differently even between methods which use the same techniques, and the procedures for building and analyzing models can be different. Although there is diversity among ISD methods they include similarities, e.g. they apply the same concepts and notations. To understand these differences and similarities we shall analyze several methods in more detail by describing types of method knowledge.

[8] We aim to avoid the use of methodology altogether; the use of this term has become confused as it originally means the study of methods, but is also used as a synonym for a method.