18.4 Iterative Development

An iteration is the controlled reworking of part of a system to remove mistakes or make improvements. Iterative development is a collective term for development models where some or all of the activities are repeated in short cycles. Specific iterative models are the RAD Model by James Martin and the Spiral Model by Barry Boehm. The stages in iterative development, shown in Figure 18-5 (after James Martin), are

• Project initiationdetermining the vision and objectives of the product

• Developmenta set of iterations, refining and expanding the product

• Deploymentcut-over and use of a part of (and eventually) the full product

Figure 18-5. Stages in Iterative Development

Each of the stages may contain iterations, though only the development stage is shown with iterations in Figure 18-5. Frameworks supporting iterative development are, for example, Microsoft Solution Framework, Dynamic Systems Development Method, and Rational Unified Process.

Developing a product using iterative development is a planning decision. This decision has a strong impact on the configuration management performed during the product's life cycle. Project planning must take configuration management into account at an early stage.

Configuration Management Considerations

In iterative development, frequent releases are planned, and changes are not only planned but actively encouraged. This means that well-thought-out configuration management is important, not least if iterations overlapif iteration n + 1 starts before the result of iteration n is deployed. This occurs often, as a way of optimizing resources. Designers start the design of iteration n + 1 based on the design of iteration n while developers and testers are working on the release of iteration n .

Requirements Management

The part of configuration management concerned with requirements, often called requirements management, is particularly important for iterative development. The requirements are the basis for the product. In iterative development, the requirements in the total pool of requirements are constantly undergoing changes:

• Requirements are added to the pool.

• Requirements in the pool are changed.

• Requirements are taken out of the pool for implementation in a specific iteration.

• Requirements dedicated to a specific iteration are changed.

• Requirements dedicated to a specific iteration are implemented.

• Requirements dedicated to a specific iteration are tested .

• A specific iteration fulfilling requirements is released.

• Requirements dedicated to a specific iteration are postponed (rerouted to the pool).

• Released requirements are changed (in the pool) and need reimplementation.

All this requires strict and swift configuration management of the requirements. In iterative development, the coding stage is not early enough to start configuration management. Configuration management must start at least with requirements and preferably with high-level visions and objectives.

Identification

It's important to be able to identify versions and other historical information for configuration items in iterative development, where each new iteration is an expansion of the previous version. For planning and implementation, identification should include information about which iterations a requirement has been implemented in and which it is going to be implemented in. Tracing between requirements and other related configuration items is therefore part of identification that must be carefully considered , planned, described, and performed.

Storage

Since iterative development entails frequent restructuring of design and code, configuration management must facilitate easy fallback to a previous version of any item. Configuration management should also cater to frequent builds for fast extraction of configuration items, especially delivery items. Also, the configuration management system should cater to extracts for production, since the whole idea is to keep changing and expanding the product.

Change Control

Since changes are the norm, the relevant configuration control board(s) must be defined early on. Special care should be taken to make these accessible and fast working, able to make decisions and carry them through, and representative of as many stakeholders as possible. It may be worthwhile to simplify event registrations and change requests , but documentation of the connected decisions must not be compromised.

Status Reporting

Status reporting should be comprehensive and fast, not least concerning requirements, because an overview of the requirements and their progress through their life cycle is an indispensable tool for iterative development. Reports concerning deliveries are also important, especially so customers and users can comprehend what is included in a new iteration and what is not.