Page 60 -

ITERATION IN SYSTEMS ANALYSIS AND DESIGN 45
tual understanding, better design quality, and enhanced system implementability (Boland, 1978).
In another study, researchers found that novice developers benefited from sequential processes
in database design, whereas experts leveraged iterative behaviors to improve design outcomes
(Prietula and March, 1991).

ITERATIONS OVER REPRESENTATIONAL ARTIFACTS

Whatever the content of a designer’s cognitive activity, it relies on representations that act as tools
by which designers extend their cognition (Bucciarelli, 1994; Hutchins, 1995; Simon, 1996). A
representation is a “way in which a human thought process can be amplified” (Churchman, 1968,
p. 61). Designers represent their designs, the design process, and other associated information
using symbolic and physical artifacts. In the making of these artifacts, in manipulating and navi-
gating through them, and in reflecting on artifacts, design ideas crystallize and change, or new
ideas emerge. Representational artifacts can take the form of documentation such as data models
or system requirements documents, or the executable code itself (code, components, database
schemata, etc). Table 4.3 describes a number of iterating representational artifacts identified in the
literature. Again, this is intended as an illustration of the wide range of representational iterations
that are prescribed in methodologies.
To appreciate the nature and role of representational artifacts in systems design, it is important
to view an information system as a dynamic entity (Orlikowski and Iacono, 2001). Systems evolve,
get revised, and behave differently in different contexts. In fact, there is no single entity or thing
that is the system. Rather the system is a shared, ambiguous, and ambivalent conception about
a slice of reality that can only be more or less accurately approximated through representations
(Lyytinen, 1987). Yet throughout the process, individuals often discuss the information system as
if it were a single, discrete entity, although all individuals have only partial views (Turner, 1987).
Early in the design process, the information system may be little more than an idea invented by
a handful of people whose only tangible artifact is a vague requirements memo or note. Later in
the process, the system may become represented by lines of incomplete code, dozens of use cases,
and a great number of varying rationales of the system’s utility.
In the following sections we analyze how representational artifacts that are deemed pivotal in
the information systems development and software engineering literature iterate. There are two
broad categories of these artifacts: the descriptive documents associated with the design object
and the executable code. We treat them differently because ultimately only the code inscribes new
behaviors in the target system—the technical and sociotechnical system. The system descriptions
are needed to make the code inscribe behaviors that are intended, acceptable, and correct. We then
address the idea of “iterative development” as reflected in the ways in which artifacts iterate, as
well as what we know about the impacts of “iterative development” on design outcomes.

Iterating Documents

Early representations of the system center on descriptions of system requirements. Over the course
of the design, these representations change regularly and often evolve into other representations,
such as “as built” software documentation. Because of this need for connecting requirements with
downstream documentation and ultimately with the executable code, no development methodol-
ogy can overlook iteration across documents entirely, although some, such as XP (Beck, 2002),
aspire to remove a majority of documentation from the critical design path.
Traditional system development life-cycle and “heavy-weight” methodologies are thought to