Up Previous Next Title Page Contents

1.2 Methodical support for information system development

One widely acknowledged approach to solve these problems has been to improve and apply systematic guidelines and procedures for ISD[1]. This type of knowledge is typically incorporated into ISD methods, which we can briefly define here as systematic and predefined guidelines for carrying out at least one complete task of ISD effort[2]. As the considerable amount of effort poured into the method development indicates (cf. Jackson 1976, Gane and Sarson 1979, Lundeberg 1982, Rumbaugh et al. 1991, Booch 1994), the current paradigm within the scientific community advocates methods. Maybe an analogy to the use of methods and techniques in other engineering disciplines (e.g. electronics, civil) or even in less engineering-oriented disciplines, such as recording and composing (Jaaksi 1997), is so close that methods are sought for ISD as well. It is a general opinion among both practitioners and academics that ISD failures are resulting from the application of irrational approaches. ISD methods are viewed as one solution to these problems (Fitzgerald 1996). In fact, the drive towards better methods and practices is common in all fields of systems development, including business modeling and re-engineering (Bubenko and Wangler 1992, Smith and McKeen 1993), development of IS architectures (Bidgood and Jelley 1991, Stegwee and van Waes 1993), system analysis and design (Olle et al. 1991), and implementation (Jeffrey 1987). In particular, improvements in early phases are believed to lead to higher productivity.

The goal of method development is to build up collective experience of IS development and utilize it to craft systematic development practices. Such experience is obtained through participating in ISD, evaluating methods, and conducting studies on method use. Based on this experience, method developers promote their own concepts, beliefs, modeling languages and procedures. In general, methodical approaches are expected to lead to more acceptable and successful solutions, and to a better-managed development process.

As a result, we currently find hundreds of methods. By taking into account organizations’ own “dialects”, i.e. methods developed in-house, we can assume that thousands of more or less similar methods are available (Bubenko 1986, Grant et al. 1992). In addition new or improved methods are being introduced continuously. Similarly, there are thousands of tools available for automating and assisting these methods. In fact, nearly all tasks of ISD are supported with software products varying from business modeling tools (Spurr et al. 1994) and CASE tools (Computer-Aided Systems Engineering, Chen et al 1989, Nilsson 1989) to programming environments. Most methods or techniques for ISD are considered impractical or even impossible to use without automated support (Wasserman 1980, Yourdon 1986, McClure 1989, Smolander et al. 1990). For example, there is little point in writing first in some programming language and then making a translation by hand into a machine language, or in checking the correctness and consistency of system designs without tool support. Accordingly, in this thesis our interest is in those method aspects that can be supported with automated tools.

Paradoxically, despite the efforts poured into method development, there seems to be no universal agreement on whether methods are useful in ISD (Lyytinen 1987, Cotterman et al. 1992, Wynekoop and Russo 1993, Wynekoop and Russo 1997). One major reason for this contradiction is the limitation and narrow focus of research: there is surprisingly little empirical knowledge of method use. The vast majority of research has concentrated on developing new methods, or developing frameworks for method analysis (cf. Olle et al. 1982, 1983, 1986, 1988, Blum 1994), comparison (cf. Hackathorn and Karimi 1988, Hong et al. 1993), and selection (cf. Davis 1982, Kotteman and Konsynski 1984)[3]. Furthermore, most empirical studies on method development or method comparison are based on cases, and on limited experiences of method use (Fitzgerald 1991). Because we know so little about how methods are used in practice, there are only shallow generalizations that could explain the success or failure of method use.

Although we do not know the effects or usefulness of ISD methods, the market has put a great emphasis on tool use and productivity. The market for development tools, such as CASE tools and application generators, has grown steadily during the last decade, and several new approaches have emerged, such as object-orientation and business process re-engineering. As Welke and Konsynski (1980) and Norman and Chen (1992) point out, tools for supporting ISD have evolved together with technical and methodical innovations. Likewise, vendors’ investments in building ISD tools have increased. As a result, organizations world-wide have invested in new ISD tools (embodying various methods) such as business modeling tools, CASE, 4GL’s (4th generation languages), integrated programming environments etc. (Benjamin and Blunt 1992). Although the rate of diffusion of CASE tools has been slower than expected, it is relatively widely recognized that the rate of diffusion of these tools will continue to increase in the future (Conway et al. 1995, Hobby 1993, Benjamin and Blunt 1992, Friedman and Cornford 1989). For example, a prediction of the CASE world market in 1997 is $1.2 bn (Hobby 1993), and the estimated annual rate of growth is 35% (Conway et al. 1995).

[1] Some other organizational and technical innovations include CASE (Computer Aided Systems/Software Engineering), 4GL (fourth generation languages), application package-based ISD, development and use of reusable designs and code, and quality assurance programs.

[2] ISD methods are defined and characterized in more detail in Chapter 2.

[3] Although the literature offers several approaches to classify, understand, compare and select methods there has been no validation of these approaches.

Up Previous Next Title Page Contents