Page 68 -

ITERATION IN SYSTEMS ANALYSIS AND DESIGN 53
Implications for Practice

We have indicated that the essential difference between what is widely considered to be “iterative
development” and traditional software development is the audience for design activity. “Iterative
development” allows visibility to other developers or some portion of the managerial and user
community earlier in the process, and at a more granular level. With such activity, developers are
also relinquishing a degree of control. Because of the dual nature of software code—acting as a
representational artifact of the system as well as a fundamental physical structure within the task
system—analysis of iterations solely on the basis of the presence of evolutionary prototyping
may be a distraction from the issues that drive better results. The iterative processes by which
key concerns arise throughout the development process are essential for understanding success.
These processes can be facilitated by evolutionary prototyping, but also by the creative use of other
representational artifacts, generative language and dialogue, or other collaborative mechanisms.
Rather than attempting to implement new methodologies blindly, software developers would be
better served in first determining who needs design input, at what level of granularity, and at what
stage of the design process.

Implications for Research

In systems analysis and design literature, cognitive iterations are addressed (usually implicitly)
through the iterative treatment of representational artifacts. The perspectives and meanings that
designers ascribe to artifacts are rarely tackled. Instead the technical artifact itself is the central
concern. Typically, the actual cognitive practices within development are not dealt with, but
rather the formal steps and stages of the methodology as reflected in representational outcomes
are treated at length. Genres of representations are typically advocated and designed to enable
communication and human interaction at specific steps and junction points, and such artifacts are
expected to change iteratively. This communication is not always seen as unproblematic, and the
nature, content, and scope of these representations is seldom fully explicated in how they support
the cognitive activities of design groups or their iterations (with some exceptions, of course; e.g.,
Checkland, 1981; Hirschheim, Klein, and Lyytinen, 1995).
This review of the literature related to iteration points to two broad areas of future research in
systems analysis and design. First, cognitive iterations of software developers and other stakehold-
ers need to be better understood. Perspectives of individuals associated with the design process do
impact the design process, and understanding the evolution of these perspectives is imperative to
improving outcomes. Second, future research should involve opening the black box of iteration over
code and other representational artifacts to understand outcomes associated with particular design
practices. By opening this black box, we encourage researchers not to treat the term “iteration”
as an undifferentiated construct, but rather to look at the degrees of visibility, granularity, timing,
and control associated with evolutionary changes of the code, various forms of documentation,
and the perspectives of the various stakeholders.

CONCLUSION

The contribution of this chapter is to illustrate the multidimensional nature of the concept of
iteration. Iteration is often characterized in the literature as a straightforward concept: either
a development process is iterative or it is not. We have shown that this characterization is too
simplistic, as all development practices contain significant levels of iteration. We also identified
two fundamental dimensions of iteration: cognitive and representational. Cognitive processes of