Iterative and incremental development

Iterative and incremental development

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model. It is an essential part of the Rational Unified Process, the Dynamic Systems Development Method, Extreme Programming and generally the agile software development frameworks.


Incremental development is a scheduling and staging strategy, in which the various parts of the system are developed at different times or rates, and integrated as they are completed. It does not imply, require nor preclude iterative development or waterfall development - both of those are rework strategies. The alternative to incremental development is to develop the entire system with a "big bang" integration.

Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. It does not presuppose incremental development, but works very well with it. A typical difference is that the output from an increment is not necessarily subject to further refinement, and its testing or user feedback is not used as input for revising the plans or specifications of the successive increments. On the contrary, the output from an iteration is examined for modification, and especially for revising the targets of the successive iterations. what?

The two terms were merged in practical use in the mid-1990s. The authors of the Unified Process (UP) and the Rational Unified Process (RUP) selected the term "iterative development", and "iterations" to generally mean any combination of incremental and iterative development. Most people saying "iterative" development mean that they do both incremental and iterative development. Some project teams get into trouble by doing only one and not the other without realizing it.

Development topics

The Basic idea

The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of 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 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.

Iterative development

Iterative development slices the deliverable business value (system functionality) into iterations. In each iteration a slice of functionality is delivered through cross-discipline work, starting from the model/requirements through to the testing/deployment. The unified process groups 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 that mitigates the top risks and fulfills the non-functional requirements.
* Construction incrementally fills-in the architecture with production-ready code produced from analysis, design, implementation, and testing of the functional requirements.
* Transition delivers the system into the production operating environment. Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full.

Waterfall vs. Iterative 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.

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 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.

ee also

*Rapid application development
*Dynamic Systems Development Method
*Extreme Programming
*Rational Unified Process
*Unified Process
*Interaction Design
*Object-oriented analysis and design


This page is extensively based on:

External links

* [ Going round and round and getting nowhere eXtremely fast? Another look at incremental & iterative development] from
* [ The “Case” for Waterfall Development] from
* [ Iterative Development and The Leaning Tower of Pisa] from

Wikimedia Foundation. 2010.

Look at other dictionaries:

  • Iterative design — is a design methodology based on a cyclic process of prototyping, testing, analyzing, and refining a product or process. Based on the results of testing the most recent iteration of a design, changes and refinements are made. This process is… …   Wikipedia

  • Incremental build model — The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The… …   Wikipedia

  • Dynamic Systems Development Method — (DSDM) is a software development approach originally based upon the Rapid Application Development (RAD) methodology. DSDM is an iterative and incremental approach that emphasizes continuous user involvement. Its goal is to deliver software… …   Wikipedia

  • Agile software development — poster Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self organizing, cross functional teams. It… …   Wikipedia

  • Software development process — Activities and steps Requirements Specification …   Wikipedia

  • Dynamic systems development method — Model of the DSDM Atern project management method …   Wikipedia

  • Outside-in software development — Of all the agile software development methodologies, outside in software development takes a different approach to optimizing the software development process. Unlike other approaches, outside in development focuses on satisfying the needs of… …   Wikipedia

  • Outside–in software development — Of all the agile software development methodologies, outside–in software development takes a different approach to optimizing the software development process. Unlike other approaches, outside–in development focuses on satisfying the needs of… …   Wikipedia

  • List of software development philosophies — This is an incomplete list of approaches, styles, and philosophies in software development.* Agile software development * Agile Unified Process (AUP) * Behavior Driven Development (BDD) * Big Design Up Front (BDUF) * Brooks s law * Cathedral and… …   Wikipedia

  • Open source software development — is the process by which open source software (or similar software whose source code is publicly available) is developed. These are software products “available with its source code and under an open source license to study, change, and improve… …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”