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
Best Answer
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.
Update:
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:
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.