Incremental and Iterative Models, also called phased development models (Graham 1992), share the common objective of reducing the cycle time for development. Although the terms tend to be used almost interchangeably, distinctions are sometimes made. Iteration entails, as the word implies, a repeated series of attacks on a problem. Each attack or iteration is like a miniature development life cycle. Iterative development tends to mean developing a prototype of the entire product in the first phase and then repeatedly improving the product in subsequent phases of successive refinement until an effective system is created (Pfleeger 1998). The incremental approach also enacts a series of iterations, but the successive iterations are understood as adding incremental functionality to the product. Incremental development tends to be viewed as building a part of the intended system in each of a sequence of partial releases until the entire system is completed.
The incremental and iterative models might be„ compared to depth-first and breadth-first approaches. In a depth-first (incremental) approach, a new functional behavior of the system is implemented in detail at each stage. In breadth-first (iterative) approach, the set of functions is initially implemented in a broad but shallow manner; many functions are included but only tentatively realized. These shallow functions are then refined as development proceeds. However, as already observed, the usage of these terms is by no means consistent in the literature. For example, the Iterative Enhancement Model of Basili and Turner (1975) is quite similar to the incremental models that Graham (1992) reviewed. Similarly, although so-called evolutionary development is usually viewed as an incremental version of the Waterfall Model (Graham 1992), Pressman (1996) categorized incremental development as a subclass of the Evolutionary Model.
Consider the Evolutionary Development Model, which was a reaction to difficulties with the Waterfall Model. In this approach, "increments of system capability" are released with subsequent stages of development based on user and developer experience with earlier releases. The initial release of the system must not be trivial and must provide "sufficient capability to serve as a basis for user exercise and evaluation" (Boehm 1996). A potential difficulty with evolutionary development is that the initial release may be so far off target that users fail to use it and may even lose confidence in the entire development process. Evolutionary Development also suffers from the same tendency as the Waterfall Model by potentially creating an "inflexible point-solution" (Boehm 1996), with the result, for example, that the initially prescribed software architecture may not scale to the entire system.
As already observed, incremental development models develop the entire system as a "series of partial products, generally with increasing functionality" (Graham 1992). The idea is to develop a succession of small, self-contained systems that eventually converge to a final completed system. The delivery of such systems is said to be incremental if these partial products are delivered to users as they are developed, which has been called evolutionary delivery (Gilb 1988). The major advantage of evolutionary delivery is the extensive opportunity provided for user feed-ii back, thus allowing recommendations to be folded back into the development process (Graham 1992).
Each incremental step must include not only implementation, but also testing, documentation, and training. indeed, each step is intended to constitute a mini-life cycle, complete with its own functional product manuals, requirement specifications, review reports, etc. increment development reflects a recognition that it is often only at the end of development that one clearly realizes how a project should have been defined, designed, and implemented in the first place. This applies to the developer who creates the system as well as to the users who, when finally seeing a completed system, may only then realize that this is not system that they had expected, even though they may have been closely involved in specifying the system. Such surprising user behavior can occur because, just as for the developer, "user knowledge also grows throughout the development process" (Graham 1992). Of course, surprises could be avoided if the complete system specifications were frozen from the beginning as they are in the Waterfall Model, but this would reduce the benefits that occur from the growing user and developer knowledge that occurs precisely as a consequence. of the incremental development. Another beneficial side effect of incremental or evolutionary delivery is that it brings the new system into an organization inch by inch, thereby decreasing organizational disruption and following users to gain familiarity with the use and benefits of the system gradually, without requiring a steep learning curve. This practice can significantly promote user acceptance, a concern that is typically one of the key problems in the successful adoption of new systems.
Graham (1992) contrasted incremental development unfavorably with the monolithic character of the Waterfall Model. The Waterfall approach fixes requirements, costs, and schedule at the earliest point in order to be able to meet "contractual restrictions" (Graham 1992). The monolithic life-cycle approach also postpones the major system test to the end of development because of the dual impact of the magnitude of testing and scheduling deadlines, this can lead to an opportunistic contraction of the system test. According to Graham, such a monolithic approach is suitable only for "small systems, of short duration, where the requirements are well known at the beginning of development and unlikely to change"
It is important when doing incremental development to "keep the increments as small as possible, provided they will provide a useful function to the users". The requirements must be frozen during each incremental step; however, because the steps are incremental, unlike in the Waterfall Model, this is comparable to freezing "ice cubes instead of icebergs" (Graham 1992)- a droll analogy. Graham also alludes to Boehm's classic observation that "developing software requirements in like walking on water, it's easier if it's frozen" (Graham 1992), observing in respect to incremental development that "it is easier to freeze a pond than an ocean."
Various strategies are possible for deciding which increments to develop in which order. For example, critical tasks can be implemented first to reduce development risk, or one may possibly develop interface components to allow testing, of possibly important functional features to support incremental product delivery. Graham recommends three guidelines: think small, think useful, and think complete. Think small refers to developing as minimal an increment as possible to produce a partial product. Think useful refers to the need to remember a key motivation behind incremental development that is, rapidaly providing a benefit to the user. Think complete refers to the intention that each incremental phase should be treated as a small, self-contained life cycle.
Similar to the incremental development discussed by Graham, Basili and Turner (1975) very early defined what they called iterative enhancement as a practical way to achieve step-wise refinement. A paradoxical or systemic problem with step-wise refinement is that it side steps the dilemma that it is difficult to identify a good design for a solution to a problem at the beginning because the difficulties with a design only show up as the implementation proceeds. As a response to this, Basili and Turner proposed to develop the system through a series of subsystems; the emerging system would be understood more thoroughly as the process proceeded just like what happens in a learning process. This learning process can be used to improve the design as the system is iteratively extended through a sequence of partial systems, ultimately converging to the complete solution. The outcome at each iterative step in a simple extension of the functionality of the system or a redesign of the preceding implementation "motivated by a better understanding of the problem, obtained through the development process" (Basili & Turner 1975).