Iterative vs Waterfall process models 3

[pivan]

For some time I have been debating and trying to understand these two process models..their similarities and differences and when and how to use them in the real world of managing software development projects.

I am of the opinion that academia has misrepresented and confused these models. Here is my take.

In projects where the problem space is understood and predictable (more or less ) the Waterfall is appropriate.

In projects where the problem space is uncertain, and unpredictable say in the case of new technology the Iterative model is usually used to identify and resolve problems that occur because they haven't been anticipated.

At the same time, in the Waterfall model we follow the steps until we run into a problem. When this happens the model requires that you go back to the beginning (Scope) and start all over, redefining the problem. You repeat this until you have no more problems and the project is complete. This sounds pretty iterative to me. SO...what is the difference...what am I missing ?

From my chair, they all sound the same.

I am consdering the use smaller project scopes and having several iterations. Each iteration contains additional features. Rather then having one huge deliverable of 110 features at the end of the year, I am breaking it up into iterations of about 20 features released at 3 month intervals. Is this then an iterative model...I would say not because it is independent of the problem space of the process model.

It seems to me that projects with that require longer then six months to complete have a higher probability of failing.

Would appreciate your insight.

Thank you,
pivan

In not now, when?
If not here, where?
If not us, who?

Just do it!!

 

[egray]

To me, "iteration" does NOT mean starting over with the problem statement. It means repeating certain steps--at any point in the development lifecycle, but especially in the design phase--until, in Steve McConnell's phrase, "users get excited". So it means giving them a prototype, incorporating feedback, giving them another prototype, incorporating feedback, etc. until they are happy. You may iterate a key document, say a project charter, until everybody is happy.

Your example of breaking a project into phases where features 1-50 are delivered, then features 51-65, etc., is not iteration, IMHO. Taking those first features, working with the users through successively detailed designs IS iteration.

Also, you mentioned a 6-month project...the rule of thumb I've heard is try and deliver features at least every 6 weeks.

Good luck,

Egray

 

[elizabeth]

I agree with the above. Here's my historical perspective. I heard of "waterfall" in the 80's as what had been done int he 70's. Back then, there was not as much stress on programmers interacting with the end users. The reason is that the programmer was hip-deep in any existing system, and knew it as well as the users, and knew their workflow, etc. So a lot of times the programmer acted as the SME (subject matter expert) and had the time and freedom to design what he (or she, but mostly he!) felt was the next step in automation. "Iterative" simply meant that you would go back to an earlier phase when you hit a bug or decided to add functionality. Very few people are brilliant enough to concieve a perfect design, so some problems found in later stages would cause you to go back to that step and flow the new requirement forward through the steps you completed on the rest of the design. This was referred to as "iterative".

Decades later, most people building apps are hired guns, and the underlying technology is so much more advanced that they don't have to know the workflow or the data to get the job done. So it's much more important to work witht the users, who are not necessarily skilled in expressing their requirements clearly and completely. So we have "prototyping", which is successive approximations of the entire app in a way the user can relate to, rather than just a conceptual design. Prototyping is planned as entirely iterative.

 

[pivan]

Thanks folks...

So...iterative development is basically incorporating a prototype and iterating the design phase (or any other phase) of a feature until users get excited...then we go into low level design and coding?

Right??

Were still in a waterfall model...IMHO.

Bigger question ...should I even spend this much time worring about it

To me it all seems to be using common sense and gearing a process model and project structure to the unique needs of the organization. In not now, when?
If not here, where?
If not us, who?

Just do it!!

 

[elizabeth]

I didn't think that "true" waterfall ever existed, as it did not allow for iteration at all. I thought it was a model that explained that you have to analyze before designing, design before building, build before testing, etc. My understanding was iteration was what allowed the waterfall model to be fitted to reality.

On prototyping, you might analyze, design, code, test -
show to client -
modify code, test -
show to clinet -
analyze additonal requirements, design, modify code, test -
etc.

In prototyping, your cycles are so brief, days or weeks vs. months or years, that it hardly makes sense to designate separate stages. In mainframe app development, you could be in the design stage for months, doing nothing except design. In the coding stage, you could be coding for a year and nothing else. Remember, the original programs weren't strictly modular, so testing a subroutine was sometimes more work (stubbing out the code, creating dummy input) than it was worth. Going back to analysis or design was something you strove to avoid because of its time-consuming nature. Remember, we didn't have even the basic drawing or text-editing tools (Visio, MS Project, Word) that we have now either. You might actually have a secretary retyping a design document, and a systems analyst using a plastic template to re-draw the flow. Now the tools make it pretty simple to build something, throw it at the wall, and see what sticks, so that's how a lot of people actually work.

 

[pivan]

elizabeth..thanks for taking the time to provide some great insight. I wanted to share my comments.

"My understanding was iteration was what allowed the waterfall model to be fitted to reality."
This makes a lot of sense, and, to me, FINALLY explains the relationship of the two models.

"In the coding stage, you could be coding for a year and nothing else."
When I have worked with projects of this duration, they have all failed in one way (schedule, cost, scope)or another. I advocate smaller projects, not to exceed six months. What is your experience on this?

"Remember, we didn't have even the basic drawing or text-editing tools (Visio, MS Project, Word) that we have now either"
Influence of recent design and modeling technology makes iterative model viable.

"Now the tools make it pretty simple to build something, throw it at the wall, and see what sticks, so that's how a lot of people actually work."
This is a lot like hacking, no control, careless, unorganized and lacking in discipline.

"You might actually have a secretary retyping a design document"
What is a secretary and why is he/she mucking around with data structures

thanks,
pivan
In not now, when?
If not here, where?
If not us, who?

Just do it!!

 

[elizabeth]

Pivan, you made me laugh with the secretary joke. A boss of mine once made that same joke to embarrass a director of another division. He was proud of having eliminated our secretary's salary in favor of purchasing PC's for each staff member, on which we created our own documentation. Unfortunately the last laugh was on him because we all had to pitch in that year to answer the phones, and that was a real production-killer!

Re: long coding times, that was in the "olden days". Not that I remember vaccuum tubes and all, but I worked with someone who did. At 15 years old she worked in her college's computer lab. She has seen a lot of change in this field! I agree things generally change too fast to have lengthy projects now. Your definition of a project and it's purpose might help determine appropriate length. Microsoft and NASA have multi-year projects. For myself, I have never worked on anything of that magnitude. But I have had projects longer than one year. Often a low-priority project gets stalled at the end of a phase due to lack of budget or resources won by a higher priority. The next phase might not happen until the following fiscal year.

Re: hacking, I agree in general. It still seems more professional to me to analyze and design before you begin building, etc. In my experience professional discipline is a strong indicator of success. But I won't rule out people who are so good at their work, through brilliance and/or experience, that they can simultaneously design and build. I've never met an IS person who sould do this on a major scale, but a number of people can do it for small enhancements. I have read that Wozniak and other hardware and software pioneers worked this way, continuously prototyping.

 

[ponderworks]

Ok, here is my two cents worth. First of all, The waterfall approach really does exist! Bear in mind that while most of us think in terms of IT projects, I think you will find it hard to iterate the process of building a road, bridge, etc. In other words, in the wider world of project management there is a broad spectrum of approaches ranging from one extreme to another. I would say that the PM must get to know the customer, the contract, the project P&L, and the team well enough to choose the best approach for all parties. There is no question in my mind that choosing an approach, gaining client and team approval, and sticking to it throughout the project is a great way to avoid the kind of craziness that leads to a lot of heartache.

I personally don't believe any one approach is "better" than another. I have worked on projects that were 3 months long and more than 2 years long. The only thing that matters from the PM point of view is to listen to your team, the client, and the other stakeholders. In the end, getting the job done and striking the kind of balance that satisfies the client, makes money, and delivers results is the only way to prevail. It certainly isn't easy but, hey, that's what a PM is for.

 

[elizabeth]

Good point, ponderworks. Because this is a web site for IS/IT professionals, and my area is software applications, I tend to forget about other areas.

 

[bartvangeel]

Take a look at the Rational Unified Process which among others consider iterative development to be a "best practice" (and I fully agree).

Iterative development means dividing the project is small (3 to 6 weeks, several months) "waterfall" projects. The result of each project should be something that can be delivered to the stakeholders of the project.
At first this will be a prototype (if your lucky) and a something that looks as a business model.
After a few iterations, after baselining the architecture and at least one architecture prototype, you start by implementing the core functionality of your system.
Gradually you extend (if you have the time) iteration per iteration more and more functionality.
I say "if you have the time" since "timeboxmanagement" is quite important. Even if not all requirements are implemented, you have to deliver and learn from the process.
This is what iteration is all about, learning from the past and formalizing that knowledge in the process.
So in fact an iterative process is based on one or more "waterfall" processes. The waterfall process is NOT bad, the iterative approach is simply something extra.
In a way the iterative approach is related with Component Based Development where you also start from "core" functionality and gradually move towards more specialized functionality.
If you want more information, please react, since there is a lot to say about this topic!

It all comes down to: Divide and rule!

(sorry if my English is not perfect, I am Flemish and living in Belgium!)

 

[pivan]

Darn bart...your English is better then mine

Thanks for the insight.

I think RUP and its advocates should take a look at this thread and use your post and elizabeths and the rest to explain interative and waterfall models. Since they both are entwined with each other.

Again, thanks.

In job search mode right now...but I'm planning to create a thread on Extreme Progamming. I have a bunch of questions there after having tried to implement it at my previous job.

TTFN
pivan If not now, when?
If not here, where?
If not us, who?

Just do it!!