The Iterative Development Process Model

The iterative enhancement (IE) approach (Basili and Turner, 1975), or the iterative development process (IDP), was defined to begin with a subset of the requirements and develop a subset of the product that satisfies the essential needs of the users, provides a vehicle for analysis and training for the customers, and provides a learning experience for the developer. Based on the analysis of each intermediate product, the design and the requirements are modified over a series of iterations to provide a system to the users that meets evolving customer needs with improved design based on feedback and learning.

The IDP model combines prototyping with the strength of the classical waterfall model. Other methods such as domain analysis and risk analysis can also be incorporated into the IDP model. The model has much in common with the spiral model, especially with regard to prototyping and risk management. Indeed, the spiral model can be regarded as a specific IDP model, while the term IDP is a general rubric under which various forms of the model can exist. The model also provides a framework for many modern systems and software engineering methods and techniques such as reuse, object-oriented development, and rapid prototyping.

Figure 2.4 shows an example of the iterative development process model used by IBM Owego, New York. With the purpose of "building a system by evolving an architectural prototype through a series of executable versions, with each successive iteration incorporating experience and more system functionality," the example implementation contains eight major steps (Luckey et al., 1992):

Figure 2.4. An Example of the Iterative Development Process Model

Source: P. H. Luckey, R. M. Pittman, and A. Q. LeVan, 1992, "Iterative Development Process with Proposed Applications," IBM Federal Sector Division, Route 17C, Owego, NY 13827.

1. Domain analysis
2. Requirements definition
3. Software architecture
4. Risk analysis
5. Prototype
6. Test suite and environment development
7. Integration with previous iterations
8. Release of iteration

As illustrated in the figure, the iteration process involves the last five steps; domain analysis, requirements definition, and software architecture are preiteration steps, which are similar to those in the waterfall model. During the five iteration steps, the following activities occur:

• Analyze or review the system requirements.
• Design or revise the solution that best satisfies the requirements.
• Identify the highest risks for the project and prioritize them. Mitigate the highest priority risk via prototyping, leaving lower risks for subsequent iterations.
• Define and schedule or revise the next few iterations.
• Develop the iteration test suite and supporting test environment.
• Implement the portion of the design that is minimally required to satisfy the current iteration.
• Integrate the software in test environments and perform regression testing.
• Update documents for release with the iteration.
• Release the iteration.

Note that test suite development along with design and development is extremely important for the verification of the function and quality of each iteration. Yet in practice this activity is not always emphasized appropriately.

The development of IBM's OS/2 2.0 operating system is a combination of the iterative development process and the small team approach. Different from the last example to some extent, the OS/2 2.0 iterative development process involved large-scale early customer feedback instead of just prototyping. The iterative part of the process involved the loop of subsystem design subsystem code and test system integration customer feedback subsystem design. Specifically, the waterfall process involved the steps of market requirements, design, code and test, and system certification. The iterative process went from initial market requirements to the iterative loop, then to system certification. Within the one-year development cycle, there were five iterations, each with increased functionality, before completion of the sys-tem. For each iteration, the customer feedback involved a beta test of the available functions, a formal customer satisfaction survey, and feedback from various vehicles such as electronic messages on Prodigy, IBM internal e-mail conferences, customer visits , technical seminars , and internal and public bulletin boards . Feedback from various channels was also statistically verified and validated by the formal customer satisfaction surveys. More than 30,000 customers and 100,000 users were involved in the iteration feedback process. Supporting the iterative process was the small team approach in which each team assumed full responsibility for a particular function of the system. Each team owned its project, functionality, quality, and customer satisfaction, and was held completely responsible. Cross-functional system teams also provided support and services to make the subsystem teams successful and to help resolve cross-subsystem concerns (Jenkins, 1992).

The OS/2 2.0 development process and approach, although it may not be universally applicable to other products and systems, was apparently a success as attested by customers' acceptance of the product and positive responses.