Page 62 -

ITERATION IN SYSTEMS ANALYSIS AND DESIGN 47
focus on documentation and its iterations. They encourage “freezing” documentation upstream in
order to move in a disciplined manner to the next steps in the design. This conceptualization is not,
however, always the case, as most major methodologies allow for iteration of upstream documents
at least to some extent (Boehm, 1981, 1988; Humphrey, 1989; Kruchten, 2000).
The waterfall model (Royce, 1970) is the best-known life-cycle methodology and is often char-
acterized as top-down, unidirectional, and noniterative. Contrary to this claim, even in its earliest
manifestation Royce suggested that unwanted changes and associated iterations are inevitable, and
he recommended a number of practices to address such problems, including piloting any sizable
software project with a “preliminary program design” (Royce, 1970, p. 331). This concept was later
popularized by Brooks when he stressed “plan to throw one away; you will, anyhow” (Brooks, 1995,
p. 116). Royce also suggested iterative maintenance of design documentation. He understood that
requirements change as the developer learns, and therefore the requirements should evolve through a
series of at least five classes of documents to the final documentation of the design “as built.” Updates
to design documentation occur for two primary reasons: to guide or to track development.
The extant literature addresses various forms of iterations related to upstream system representations
—such as requirements determinations (Davis, 1982), data models (Hirschheim, Klein, and Lyyt-
inen, 1995), and the wide array of technical and social documentations associated with formal
methodologies (Boehm, 1981, 1988; Davis, 1974; Humphrey, 1989; Kruchten, 2000; Mumford,
2003; and others). Although most of the literature addresses changing documents throughout the
design, the value of these changes is not elaborated beyond guiding and tracking. Even the more
nuanced views of documentation that treat its creation as problematic and argue its content to
be flawed (Parnas and Clements, 1986) have made no distinction between the value and cost of
iterations across representations. There are some exceptions to this, however. For example, the
“inquiry cycle model” (Potts, Takahashi, and Anton, 1994) describes iterative requirements refine-
ment where stakeholders define, challenge, and change requirements. Using requirement goals
to drive such practice is expected to be efficient, since many original goals can be eliminated,
refined, or consolidated before entering the design step (Anton, 1996).
Iterating Software Code

The code evolves through multiple instantiations in many development approaches including
“throw-away” prototypes (Baskerville and Stage, 1996), prototypes that evolve into a final system,
or maintenance of different versions of a system. The common usage of “iterative development”
normally refers to software design that proceeds through “self-contained mini-projects” where
each produces partially complete software (Larman, 2004). This has traditionally been referred
to as evolutionary prototyping (Alavi, 1984; Beynon-Davies et al., 1999; Floyd, 1984). Such
“iterative development” practices emerged soon after waterfall was made the orthodox model.
The idea of “stepwise refinement” involved a blunt, top-down design of the system, then a phased
decomposition and modular improvement of the code—largely to increase system performance
(Wirth, 1971). Stepwise refinement was criticized for requiring “the problem and solution to be well
understood,” and not taking into consideration that “design flaws often do not show up until the
implementation is well under way so that correcting the problems can require major effort” (Basili
and Turner, 1975, p. 390). To address these issues, Basili and Turner recommended an “iterative
enhancement,” where designers start small and simple, by coding a “skeletal sub-problem of the
project.” Then developers incrementally add functionality by iteratively extending and modifying
the code, using a project control list as a guide, until all items on the list have been addressed. Each
iteration involves design, implementation (coding and debugging), and analysis of the software.