Iterative and incremental development
Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment with the cyclic interactions in between.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/a/ac/Iterative_development_model_V2.jpg/300px-Iterative_development_model_V2.jpg)
Part of a series on |
Software development |
---|
Iterative and incremental development are essential parts of the Rational Unified Process, Extreme Programming and generally the various agile software development frameworks.
It follows a similar process to the Plan-Do-Check-Act of Business process improvement.
The Basic idea
A common mistake is to consider "iterative" and "incremental" as synonyms, which they are not. In software/systems development, however, they typically go hand in hand. The basic idea is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing the developer to take advantage of what was learned during the development of earlier portions or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.
The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.
The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a mission-critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/1/19/Development-iterative.png/320px-Development-iterative.png)
Iterative/Incremental Development
Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment. The unified process groups increments/iterations into phases: inception, elaboration, construction, and transition.
- Inception
- identifies project scope, risks, and requirements (functional and non-functional) at a high level but in enough detail that work can be estimated.
- Elaboration
- delivers a working architecture th - incomplete
- Construction
- ()
- Transition
- ()
Waterfall vs Iterative/Incremental Development
Waterfall development completes the project-wide work-products of each discipline in a single step before moving on to the next discipline in the next step. Business value is delivered all at once, and only at the very end of the project. Backtracking is possible in an iterative approach.
Implementation guidelines
Guidelines that drive the implementation and analysis include:
- Any difficulty in design, coding and testing a modification should signal the need for redesign or re-coding.
- Modifications should fit easily into isolated and easy-to-find modules. If they do not, some redesign is possibly needed.
- Modifications to tables should be especially easy to make. If any table modification is not quickly and easily done, redesign is indicated.
- Modifications should become easier to make as the iterations progress. If they are not, there is a basic problem such as a design flaw or a proliferation of patches.
- Patches should normally be allowed to exist for only one or two iterations. Patches may be necessary to avoid redesigning during an implementation phase.
- The existing implementation should be analysed frequently to determine how well it measures up to project goals.
- Program analysis facilities should be used whenever available to aid in the analysis of partial implementations.
- User reaction should be solicited and analysed for indications of deficiencies in the current implementation.
See also
- Rapid application development
- Dynamic Systems Development Method
- Extreme Programming
- Kaizen
- Rational Unified Process
- Unified Process
- Microsoft Solutions Framework
- Interaction Design
- OpenUP/Basic
- Object-oriented analysis and design
- Goal-Driven Software Development Process
- Spiral model
Notes
![]() | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (September 2010) |
References
- Dr. Alistair Cockburn (2008). "Using Both Incremental and Iterative Development". STSC CrossTalk. 21 (5). USAF Software Technology Support Center: 27–30. ISSN d0000089. Retrieved 2009-01-10.
{{cite journal}}
: Check|issn=
value (help); Unknown parameter|month=
ignored (help) - Craig Larman, Victor R. Basili (2003). "Iterative and Incremental Development: A Brief History". IEEE Computer. 36 (6). IEEE Computer Society: 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162. Retrieved 2009-01-10.
{{cite journal}}
: Unknown parameter|month=
ignored (help)
External links
- Going round and round and getting nowhere eXtremely fast? Another look at incremental & iterative development from www.methodsandtools.com
- The “Case” for Waterfall Development from www.fromthetrench.com
- Iterative Development and The Leaning Tower of Pisa from www.fromthetrench.com]