Acism's Offshore Outsourcing Guide > Interative Processes

The central theme in the iterative processes is to look at software projects as multiple units of work and apply SDLC to each of those.

This approach suddenly makes a lot of difference (as opposed to waterfall):

1. Individual iterations being small, the project visibility improves tremendously. The product can be shown to the client at the end of every iteration and the progress is visible.
2. The rigor of waterfall goes away. If you found a requirement after an iteration has started, there is always another iteration to cover it. The very rigorous requirements document is replaced by easier to read user stories.
3. There is more or less a continuous interaction between the software development team and the client.
4. There is a scope for parallelism. The development on next iteration can start when the testing or UAT on a previous iteration is going on.

Because of the attractiveness of the iterative approach, it is the basis of all the modern approaches. The first to appear in the books was the spiral model. Later Rational Unified Process (RUP) was derived from it. Various Agile methodologies (extreme programming, scrum etc) use iterative process of development.

The key challenge for all these methodologies is how to make up for the lost advantage that waterfall had –that of the possibility of an optimum design. Without that they could degenerate into the chaotic model producing messy, unstable and un-maintainable code. The answer devised by the Agile methodologies is refactoring. In layman's terms, it means segregating the commonalities as the developer encounters them. (In waterfall case, these commonalities are addressed at once in the design phase.)

Thus, iterative approaches can be seen as the middle path between the two extremes of the waterfall and the chaotic development, in that they try to reduce the rigor of waterfall (being client friendly) at the same time maintaining discipline in the code (being product-friendly /developer-friendly). It is possible for them to degenerate to chaotic processes if there is a lot of scope creep. It is therefore required that the clients use the flexibility they get judiciously. Just to clarify on this point: it is not wise to start off with the requirement of an ant, and try to create an elephant out of it in subsequent iterations. No amount of refactoring could help that. If you wanted to build an elephant, start off with the picture of an elephant, though a bit vague at places, and then add those missing pieces in subsequent iterations.