Incremental development is the process of constructing a partial implementation of a total system and slowly adding increased functionality or performance. This approach reduces the cost incurred before an initial capability is achieved. It also produces an operational system more quickly by emphasizing a building-block approach that helps control the impact of changing requirements.
The incremental model performs the waterfall in overlapping sections, producing usable functionality earlier. This may involve a complete up-front set of requirements that are implemented in a series of small projects, or a project may start with general objectives that are refined and implemented in groups.
Boehm describes the incremental approach as combining elements of the linear sequential model and prototyping, and advocates developing the software in increments of functional capability. He reports that his experience is that this refinement of the waterfall model works equally well on extremely large as well as on small projects. In a short example of a product delivered in three increments, increment 1 would provide basic algorithms and basic output of results, increment 2 would add some valuable production-mode capabilities such as the ability to file and retrieve previous runs, and increment 3 would add various nice-to-have features for the user interface and added computational features.
The incremental model describes the process of prioritizing requirements of the system and then implementing them in groups. Generally, increments become smaller, implementing fewer requirements each time. Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented. This approach reduces costs, controls the impact of changing requirements, and produces an operational system more quickly by developing the system in a building-block fashion.
The early phases of the life cycle (planning, analysis, and design) consider the entire system to be developed. During these phases, the increments and the functions within them are defined for development. Each increment then proceeds through the remaining phases of the life cycle: code, test, and delivery.
A set of functions that are the core, or highest priority requirements critical to the success of the project, or that will reduce risk is constructed, tested, and implemented first. Subsequent iterations expand on the core, gradually adding increased functionality or performance. Functions are added in significant increments to meet user needs in a cohesive fashion. Each additional function is validated against the entire set of requirements.
The linear sequences may be staggered over calendar time, with each one producing a deliverable increment of software, as shown in Figure 4-13.
Figure 4-13. The Incremental Model
Figure 4-13. The Incremental Model
This type of development can be combined with other models. It is often integrated with the spiral model, the V-shaped model, and the waterfall model to reduce costs and risks in the development of a system.
Strengths of the Incremental Model
When applied to a project for which it is well suited, strengths of the incremental model include the following:
• Funds for a total product development need not be expended up-front because a major function or high-risk function is developed and delivered first.
• An operational product is delivered with each increment.
• Lessons learned at the end of each incremental delivery can result in positive revisions for the next; the customer has an opportunity to respond to each build.
® The use of the successive increments provides a way to incorporate user experience into a refined product in a much less expensive way than total redevelopment.
® The "divide and conquer" rule allows the problem to be broken down into manageable pieces, preventing the development team from becoming overwhelmed with lengthy requirements.
® Limited staff can be used, with the same team working sequentially to deliver each increment, keeping all teams working (labor distribution curve may be leveled out through the time-phasing of project effort).
® Starting the next build during the transition phase of the last smoothes staffing exchanges.
® Project momentum can be maintained.
® Costs and schedule risks may be revisited at the end of each incremental delivery. ® Initial delivery cost is lowered.
® Initial delivery schedule is faster, perhaps allowing response to a market window. ® Risk of failure and changing requirements is reduced.
® User needs are more controllable because the development time for each increment is so small.
® Because the leap from present to future does not occur in one move, the customer can adjust to new technology in incremental steps.
® Customers can see the most important, most useful functionality early. ® Tangible signs of progress keeps schedule pressure to a manageable level.
® Risk is spread across several smaller increments instead of concentrating in one large development.
® Requirements are stabilized (through user buy-in) during the production of a given increment by deferring nonessential changes until later increments.
® Understanding of the requirements for later increments becomes clearer based on the user's ability to gain a working knowledge of earlier increments.
® The increments of functional capability are much more helpful and easy to test than the intermediate level products in level-by-level top-down development.
When applied to a project for which it isnofwell suited, weaknesses of this model include the following: ® The model does not allow for iterations within each increment.
® The definition of a complete, fully functional system must be done early in the life cycle to allow for the definition of the increments. ® Because some modules will be completed long before others, well-defined interfaces are required. ® Formal reviews and audits are more difficult to implement on increments than on a complete system. ® There can be a tendency to push difficult problems to the future to demonstrate early success to management. ® The customer must realize that the total cost will not be lower.
® Use of general objectives, rather than complete requirements, in the analysis phase can be uncomfortable for management.
® It requires good planning and design: Management must take care to distribute the work; the technical staff must watch dependencies.
When to Use the Incremental Model
A project manager may feel confident that the incremental model is appropriate when several of the following conditions are met:
® When most of the requirements are understood up-front but are expected to evolve overtime; ® When there is a short market window and a need to get basic functionality to the market quickly; ® On projects that have lengthy development schedules, usually over one year; ® Wth an even distribution of different priority features; ® On low- to medium-risk programs;
® On a project with new technology, allowing the user to adjust to the system in smaller incremental steps rather than leaping to a major new product;
® When considerations of risk, funding, schedule, size of program, complexity of program, or need for early realization of benefits indicate that a phased approach is the most prudent;
® When it is too risky to develop the whole system at once;
® When deliveries occur at regular intervals.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.