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.
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:
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.
What Is Software Quality?
Software Development Process Models
Fundamentals of Measurement Theory
Software Quality Metrics Overview
Applying the Seven Basic Quality Tools in Software Development
Defect Removal Effectiveness
The Rayleigh Model
Exponential Distribution and Reliability Growth Models
Quality Management Models
In-Process Metrics for Software Testing
Complexity Metrics and Models
Metrics and Lessons Learned for Object-Oriented Projects
Measuring and Analyzing Customer Satisfaction
Conducting In-Process Quality Assessments
Conducting Software Project Assessments
Dos and Donts of Software Process Improvement
Using Function Point Metrics to Measure Software Process Improvements
A Project Assessment Questionnaire