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.