The Incremental approach 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 product is defined as finished when it satisfies all of its requirements

The 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 intended to ultimately improve the quality and functionality of a design. In iterative design, interaction with the designed system is used as a form of research for informing and evolving a project, as successive versions, or iterations of a design are implemented.

It seems both methods are about creating a part of the system , refining it to pass all the test cases , adding another component of the system and refining it again , these gets repeated untill the system is finished.

What is the actual difference between these two ways of designing software

How is it possible to combine these two methods to form iterative and incremental design approach


3 Answers 3


The Incremental Approach uses a set number of steps and development goes from start to finish in a linear path of progression.

Incremental development is done in steps from design, implementation, testing/verification, maintenance. These can be broken down further into sub-steps but most incremental models follow that same pattern. The Waterfall Model is a traditional incremental development approach.

The Iterative Approach has no set number of steps, rather development is done in cycles.

Iterative development is less concerned with tracking the progress of individual features. Instead, focus is put on creating a working prototype first and adding features in development cycles where the Increment Development steps are done for every cycle. Agile Modeling is a typical iterative approach.

The incremental model was originally developed to follow the traditional assembly line model used in factories. Unfortunately, software design and development has little in common with manufacturing physical goods. Code is the blueprint not the finished product of development. Good design choices are often 'discovered' during the development process. Locking the developers into a set of assumptions without the proper context may lead to poor designs in the best case or a complete derailing of the development in the worst.

The iterative approach is now becoming common practice because it better fits the natural path of progression in software development. Instead of investing a lot of time/effort chasing the 'perfect design' based on assumptions, the iterative approach is all about creating something that's 'good enough' to start and evolving it to fit the user's needs.

tl;dr - If you were writing an essay under the Incremental Model, you'd attempt to write it perfectly from start to finish one sentence at at time. If you wrote it under the Iterative Model, you'd bang out a quick rough draft and work to improve it through a set of revision phases.


I modified my definition for 'Incremental Approach' to fit a more practical example.

If you have ever had to deal with contracting the Incremental Approach is how most contracts are carried out (especially for the military). Despite the many subtle variations of the typical 'Waterfall Model' most/all of them are applied the same way in practice.

The steps go as follows:

  • Contract Award
  • Preliminary Design Review
  • Critical Design Review
  • Specification Freeze
  • Development
  • Fielding/Integration
  • Verification
  • Reliability Testing

The PDR and CDR are where the spec is created and revised. Once the spec is complete, it should be frozen to prevent scope creep. Integration occurs if the software is used to extend a pre-existing system. Verification is for checking that the application matches the spec. Reliability is a test to prove that the application will be reliable over the long term, this can be specified much like a SLA (Service Level Agreement) where the system is required to sustain a certain percentage of uptime (ex 99% uptime for 3 months).

This model works great for systems that are straightforward to specify on paper but difficult to produce. Software is very difficult to specify on paper to any appreciable degree of detail (ex UML). Most 'business types' in charge of management/contracting fail to realize that -- when it comes to software development -- the code itself is the spec. Paper specifications often take as much or more time/effort to write as the code itself and they usually prove to be incomplete/inferior in practice.

Incremental approaches attempt to the wasted time/resources by treating the code itself as the specification. Instead of running the paper spec through multiple revision steps, the code itself goes through multiple cycles of revision.

  • +1 for nice example, although Incremental description looks wrong to me
    – Basilevs
    Commented Mar 9, 2014 at 6:35
  • @Basilevs Is that better? Commented Mar 9, 2014 at 22:08
  • 13
    Waterfall is not incremental. Incremental specifically refers to building (design through test) software piece by piece. In the traditional waterfall model, you do all of your design, then all of your implementation, and then all of your testing. It's not incremental at all. There are variations of waterfall, such as where you would handle your requirements engineering up front, and then break the project into increments where each increment is designed, implemented, tested (and integrated and tested with other increments), but this isn't traditional waterfall.
    – Thomas Owens
    Commented Mar 10, 2014 at 0:58

As with any adjective, and most things in software development... it depends!

It depends on context, and how the term is being used. So you’re asking about the difference between incremental and iterative approaches to software development, but your quote looks at iterative design, which is a different thing (although similar).

So answering specifically as an approach to software development..

The question is misplaced. It’s not one or the other. You can’t compare them directly as they refer to different parts of the process.

Iterative software development is by its nature incremental. Incremental software development does not have to be iterative.

An increment is a small move, hopefully forward. It’s a way of referring to each step of the work that is carried out.

An iteration is a cycle of work.

So, an iteration refers to the overall development cycle that is used. An increment refers to each individual step of the work. An iteration will produce an increment, which is made up of one or more actual increments to the software (usually more).

In Conclusion...

Iterative software development is a specific type of approach to software development, working in iterations as opposed to a traditional waterfall approach. Scrum is a good example.

Incremental software development is more general, and refers to moving work forward in steps, which is a feature of most (perhaps all?) approaches. With that said, the term is more often used in relation to modern, agile approaches, which probably explains the confusion between the two very similar terms.

And finally, of course, it depends how the term is meant when used, which often varies significantly by the speaker, time of month, etc!

A more interesting question is, where does an empirical approach to software development fit in all this. The beauty of an iterative approach is that it enables empiricism, which is where the magic happens.

Hope this helps.

This article describes it well, with examples.


In a nutshell: the iterative approach embraces the fact that requirements are rarely static, while the incremental approach does not necessarily do this.

When going incremental, you go in several steps that implement a growing subset of the full requirements.

When going iterative, you go in several steps, where each step implementing the full set of requirements for that step (incl. testing and often deployment), but change (revise or extend) the requirements from one step to the next.

The iterative approach embraces the fact that requirements usually evolve during the development process or the life of software, and even are often discovered only during testing or after deployment of the software.

Not the answer you're looking for? Browse other questions tagged or ask your own question.