Page 66 -

ITERATION IN SYSTEMS ANALYSIS AND DESIGN 51
tion is often credited with better user satisfaction (Naumann and Jenkins, 1982; Necco, Gordon,
and Tsai, 1987), designer satisfaction (Mahmood, 1987), ease of use (Boehm, Gray, and Seewaldt,
1984; Gordon and Bieman, 1993), and greater use of the system (Alavi, 1984; Mahmood, 1987).
Research on the effects of prototyping on system performance is generally mixed (Gordon and
Bieman, 1993). Some found prototyping to be positively related to higher system performance
(Alavi, 1984; Larman, 2004), but others found that prototyping might create less robust, less
functional systems, with potentially less coherent designs (Boehm, Gray, and Seewaldt, 1984),
and may call for “negotiable” quality requirements (Baskerville and Pries-Heje, 2004).
While Basili and Turner (1975) advocate iterative enhancement, they indicate that software
created through evolutionary prototypes can require less “time and effort,” and the “development
of a final product which is easily modified is a by-product of the iterative way in which the product
is developed” (1975, p. 395). A large number of subsequent studies indicate that prototyping can
shorten lead times for projects and/or require less effort, typically measured by fewer man-hours
(Baskerville and Pries-Heje, 2004; Boehm, Gray, and Seewaldt, 1984; Gordon and Bieman, 1995;
Naumann and Jenkins, 1982; Necco, Gordon, and Tsai, 1987; Subramanian and Zarnich, 1996). A
number of studies also support the claim that evolutionary prototyping results in more maintain-
able code (Boehm, Gray, and Seewaldt, 1984; Gordon and Bieman, 1993).
In most empirical studies, iteration is treated as an independent variable that affects outcomes.
Additional moderators are sometimes introduced, but not in a systematic manner. For example,
prototyping must be combined with other factors such as powerful development tools (Alavi, 1984;
Naumann and Jenkins, 1982), a standardized architecture (Baskerville and Pries-Heje, 2004),
greater developer expertise (Gordon and Bieman, 1995), a complementary culture (Beynon-Davies,
Mackay, and Tudhope, 2000; Lindvall et al., 2002), and “low technology” artifacts and processes
for scheduling and monitoring (Beynon-Davies, Mackay, and Tudhope, 2000). Also, if users are not
involved, prototype-based outcomes can suffer (Lichter, Schneider-Hufschmidt, and Zullighoven,
1994). Prototyping can also be seen as a dependent variable. For example, researchers find that
prototyping may pose challenges for management and planning (Alavi, 1984; Boehm, Gray, and
Seewaldt, 1984; Mahmood, 1987).
In recent years there has been a dearth of rigorous research on the effects of prototyping on
systems development. Most of the empirical literature on the impacts of agile methods is anecdotal
(Lindvall et al., 2002). Although past studies have typically compared prototype-based processes
with specification or plan-based processes, current empirical research will likely suggest com-
binations of iterative and specification-based processes (e.g., Mathiassen, Seewaldt, and Stage,
1995) or compare variations in agile practices. When pursuing either of these research avenues, it
would make sense to adopt a more granular and refined view of iteration and define the dependent
variables carefully.

DISCUSSION

“Iterative development” has been both advocated and contested as a systems analysis and design
principle. Yet it has remained a fundamental building block of system analysis and design meth-
odologies. In this chapter, we have consistently enclosed the term in quotation marks because
literally all systems development is iterative. Both cognitive and, consequently, representational
iterations are essential to every design practice. This begs the question: What is the difference, then,
between “iterative” practices of today, and the traditional “noniterative” practices? The answer is
not the presence or absence of iteration, as both types exhibit iteration.
One explanation of the difference can be the way in which the two types approach iteration.