Software Development: Iterative & Evolutionary
- Jan 9, 2004
- Iterative Development
- Risk-Driven and Client-Driven Iterative Planning
- Timeboxed Iterative Development
- During the Iteration, No Changes from External Stakeholders
- Evolutionary and Adaptive Development
- Evolutionary Requirements Analysis
- Early "Top Ten" High-Level Requirements and Skillful Analysis
- Evolutionary and Adaptive Planning
- Incremental Delivery
- Evolutionary Delivery
- The Most Common Mistake?
- Specific Iterative & Evolutionary Methods
- What's Next?
- Recommended Readings
This chapter is from the book
Experience is that marvelous thing that enables you to recognize a mistake when you make it again.
—F. P. Jones
OVERVIEW
-
Basic practices of iterative and evolutionary methods, including timeboxing and adaptive planning.
-
A common mistake adopting iterative methods.
-
Specific iterative and evolutionary methods, including Evo and UP.
Iterative and evolutionary development is a foundation not only of modern software methods, but—as the history section of the "Evidence" chapter shows—of methods used as far back as the 1960s. Agile methods are a subset of iterative and evolutionary methods. This chapter summarizes key practices:
|
iterative development |
evolutionary development |
|
risk-driven and client-driven |
evolutionary requirements |
|
timeboxing |
adaptive planning |
Iterative Development
Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. The goal for the end of an iteration is an iteration release, a stable, integrated and tested partially complete system. To be clear: All the software across all the teams is integrated into a release each iteration. Most iteration releases are internal, a baseline primarily for the benefit of the development team—they are not released externally. The final iteration release is the complete product, released to the market or clients. See Figure 2.1.
)
Figure 2.1. iterative and incremental development
Although an iteration can in theory be only for clean-up or performance tuning, usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development. The concept of growing a system via iterations has been called iterative and incremental development (IID), although simply "iterative development” is common. Some older process literature [Wong84] used the term “incremental development" to mean a combination of frozen up-front specifications followed by iterative development of the features, but there is no widespread agreement on usage. In this era, most development methods are IID methods. And, IID is at the core of all the agile methods, including Scrum and XP.
Most projects have at least three iterations before a final public release; I've seen a two-year Valtech project composed of close to 20 iterations averaging around four weeks each, and I know of at least one long project with 45 iterations.
In modern iterative methods, the recommended length of one iteration is between one and six weeks.
Each iteration includes production-quality programming, not just requirements analysis, for example. And the software resulting from each iteration is not a prototype or proof of concept, but a subset of the final system.
More broadly, viewing an iteration as a self-contained mini-project, activities in many disciplines (requirements analysis, testing, and so on) occur within an iteration (see Figure 2.2).
)
Figure 2.2. disciplines across iterations
