The staged-delivery model is another lifecycle model in which you show software to the customer in successively refined stages. Unlike the evolutionary-prototyping model, when you use staged delivery, you know exactly what you're going to build when you set out to build it. What makes the staged- delivery model distinctive is that you don't deliver the software at the end of the project in one fell swoop. You deliver it in successive stages throughout the project. (This model is also known as "incremental implementation.") Figure 7-9 shows how the model works.

Figure 7-9. Staged-delivery model. Staged delivery avoids the waterfall model's problem of no part of the system being done until all of it's done. Once you've finished design, you can implement and deliver the system in stages.

As Figure 7-9 suggests, with staged delivery you go through the waterfall model steps of defining the software concept, analyzing requirements, and creating an architectural design for the whole program you intend to build. You then proceed to do detailed design, coding, debugging, and testing within each stage.

The primary advantage of staged delivery is that it allows you to put useful functionality into the hands of your customers earlier than if you delivered 100 percent of the project at the end of the project. If you plan your stages carefully, you may be able to deliver the most important functionality the earliest, and your customers can start using the software at that point.

Staged delivery also provides tangible signs of progress earlier in the project than less incremental approaches do. Such signs of progress can be a valuable ally in keeping schedule pressure to a manageable level.

The main disadvantage of staged delivery is that it won't work without careful planning at both the management and technical levels. At a management level, be sure that the stages you plan are meaningful to the customer and that you distribute work among project personnel in such a way that they can complete their work in time for the stage deadline. At a technical level, be sure that you have accounted for all technical dependencies between different components of the product. A common mistake is to defer development of a component until stage 4 only to find that a component planned for stage 2 can't work without it.