Iterative

An iterative — or evolutionary — lifecycle repeats a full development cycle over the whole product, each pass producing a more complete version than the last. You use it when you do not yet know exactly what to build, and expect to find out by building.

Pressman states the output plainly: “Evolutionary process models produce an increasingly more complete version of the software with each iteration” [1]. The motivation is uncertainty — “there are many situations in which initial requirements are reasonably well defined, but the overall scope of the development effort precludes a purely linear process” is the case for incremental; evolutionary models exist for the case where the requirements themselves move.

1. Iteration buys information, not just progress

The distinction from incremental delivery is what each pass is for. An increment delivers a slice of an agreed system. An iteration produces a version whose purpose is partly to tell you what the next version should be — the feedback is the deliverable, alongside the software.

That is why “how many iterations” is the wrong question to ask about a project. Both models repeat. Only one of them repeats in order to learn.

Example — the Space Shuttle primary avionics. The flight software was developed across seventeen iterations over roughly thirty-one months, each accommodating requirement changes that had emerged since the last [2]. The requirements were not withheld out of carelessness: nobody yet knew what flying the vehicle would demand, and each iteration settled part of that question.

2. It is much older than the agile movement

Iterative development is routinely presented as a reaction against waterfall, which gets the chronology backwards. Larman and Basili document iterative practice from the late 1950s onward — Gerald Weinberg’s recollection of the IBM Service Bureau in 1957, and Project Mercury in the early 1960s running half-day increments with test-first development [2]. Michael Fagan’s first-hand account of IBM in 1971 describes work already running “in a series of cycles, similar to what we call ‘iterative development’… today” [3].

So iteration was never absent. What happened is that a sequential documentation of the process became the standard being audited against, and the iteration stopped being written down.

3. What it costs

Iterating without a stopping rule is the failure mode, and it has a name — endless iteration. Because each pass legitimately changes the target, there is no internal signal that says done; that signal has to come from outside, as a fixed budget, a release date or an explicit acceptance condition.

The second cost is that continuous change is hard to contract for and hard to audit. Someone paying for a fixed deliverable cannot easily buy a process whose output is defined by what it learns, which is the same tension the spiral runs into when it meets contract acquisition.

How solid is this?

  • The iterative/evolutionary definition here is Pressman’s [1] — a textbook distinction, chosen because it is clean and citable, not because a study established it. Other sources draw the line differently or not at all.
  • The historical claims are well sourced but secondary. Larman and Basili’s article is a history and reports no evidence of its own [2]; the 1957 date rests on a personal recollection by Weinberg, related decades later. Attribute it to Weinberg and cite it to Larman and Basili.
  • Fagan’s is an invited retrospective [3], which is recollection rather than record.
  • None of this compares iterative development’s outcomes to anything. It establishes that the practice is old and widespread, not that it performs better.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [4] on software project management.

References

  1. R. S. Pressman,
    Software Engineering: A Practitioner’s Approach, 7th ed. McGraw-Hill, 2010.
  2. C. Larman and V. R. Basili,
    “Iterative and incremental developments. a brief history,” Computer, vol. 36, no. 6, pp. 47–56, June 2003, doi: 10.1109/MC.2003.1204375.
  3. M. Fagan,
    “A History of Software Inspections,” in Software Pioneers: Contributions to Software Engineering, M. Broy and E. Denert, Eds., Springer, 2002, pp. 215–222.
  4. D. Root,
    Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.