What is the difference between waterfall model with iterations and evolutionary software development model?

Question

Does anyone know the difference between those two?

They are both created by iterative approach - giving successive revision after each iteration. They both have the initial idea->analysis->(outline)design phases.

Answer 1

Definitions will vary so I doubt you will get a conclusive answer to this question.

Having said that, the most obvious potential difference I see is how the iterations relate to your high level design / architecture:

• In an iterative waterfall model, you might use the iterations more for refinement/elaboration of elements of the overall design in multiple phases of [detailed design / build / test]. In theory, you could plan most of the iterations in advance.
• In a true evolutionary model you would not have an overall design - you'd just be adding to whatever you have already built based on some notion of what is most valuable to do next, typically gained through intensive user feedback. You wouldn't have a fixed plan for future iterations (although you might keep a prioritised backlog or something similar).

Answer 2

"Evolutionary design" is a general term, covering all design methods that use some sort of mutation/selection mechanism (that is, change - test - reject / accept cycles); "Waterfall with iterations" specifically describes a development process that applies the Waterfall model iteratively.

An informal single-developer process where all development happens on one machine, changes are made ad-hoc as needed, and deployed whenever they are considered 'ready', is certainly an evolutionary design model, but it hardly fits the Waterfall definition, not even in its most relaxed interpretation.

Answer 3

From what I have experienced, people mostly use "waterfall with iterations' as a derisive term for poor or half-hearted agile implementations and not as a practical methodology.

Anyway I came across this article which has a decent explanation of the term "Iterative Waterfall".

Answer 4

Iterative Waterfall could also mean to simple break down a large projects in milestones and call each milestone an "iteration".

To do this of course is sin since it removes all possibility of review or feedback from previous iterations into the next. Yet I have seen it applied after which their protractors proclaimed high and loud they were now Agile for doing so !!

Another definition of iterative waterfall is to have successive waterfalls where the next feeds from the previous. Again no feedback during the cycle itself from design to delivery but only between delivery and design is feedback allowed. This definition seems to match the link provided by DPD.

My personal definition of "Waterfall" style and "Agile" style processes lies in how the project is viewed and broken down. Both pretty much cover the same phases and though processes but tackle them in a much different way. If you view the production of a software as a stack with Inception at the top and deployment and support at the bottom.

Waterfall will break down the software creation process horizontally and traverse each layer in sequence. For a waterfallist (if such thing can be said) proceeding to the next layer is impossible without having completely worked out the layer above, its just inconceivable. Typical argument would be that you never build the roof of a house before the foundation and will say things akin to "measure twice but cut once".

Agile on the other hand will break down the creation process vertically producing slices of functionality that get added to the product over time. with each slices however they do not proceed through the stack from top to bottom but tackle it all at once. They are able to do this because they have willingly reduced the scope of the target result. To them it is inconceivable to proceed without testing first to see if the idea makes sense. With each iterations they add slivers of functionality and test it against the idea and against the rest of the system.

Waterfall is rooted in engineering where the target is a tangible real life product and error is not admissible. They see software as rigid pieces of steel and concrete that must be assembled into a structure. Therefore they will tend to be over cautious planing everything minutely wasting resources on the altar of perfection. For Waterfall to work you need very strong experienced players and a complete trust in them, you need to be extra meticulous at every step of the way in foreseeing what could be and anticipating.

Agile is rooted in the scientific process where knowledge is gathered one bit at a time and tested continuously. They understand perfectly that software is a malleable and can be bent and shaped at will. They treat ideas as would a researcher treat a theory, that is it stands as long as it agrees with the tests. Therefore they will tend to continuously reshape their system wasting resources by recreating the same things over and over each time with a slight twist to fit the new variables. For agile to work you need to continuously evaluate your system as a whole and place it against the new reality. Measurements and automation are essential in order to gain the most accurate picture possible of the present such that the next step can be taken as a corrective measure towards the ideal path. Even the ideal path needs to be re-evaluated to make sure that it does indeed points towards the ideal target.

Waterfall Build software to last as-is, static, set in concrete.

Agile grow software, care and tend for it to an ever changing world.

True that software is malleable early on but as it gains size and age it also gains stiffness resisting changes more and more. In my opinion there is no silver bullet and there tends to be to much religious devotion at the detriment of rational reflection. That said of the two extremes Agile seems to be the one that takes into account the soft of software.