wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Iterative or Waterfall ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Iterative or Waterfall ?" Watch "Iterative or Waterfall ?" New topic
Author

Iterative or Waterfall ?

Kodo Tan
Ranch Hand

Joined: Aug 14, 2001
Posts: 105
Hi all
I have been pondering this for quite some time and maybe you guys can help me on this:
(1) We all know that for MOST modern project management, we should avoid waterfall methodology as it is restrictive, not adaptable to use changes, and other classic bad points about waterfall model easily found in any software project management books.
(2) For OO/J2EE projects, we are advised that one good approach is OOAD or iterative model and blah blah blah.
(3) Now here is my concern: In most projects teams I'm in, if I examine the schedule and resources planning carefully, I think it's more towards waterfall approach than anything else. For instance, for most project schedules, it is quite common to find the following:
(a) Project Initialisation Jan - Feb
(b) Users requirements Feb - Mar
(c) Functional specifications Mar - Apr
(d) Detailed Design Spec Apr - Jun
(e) Code Development Jun - Oct
(f) SIT Oct - Nov
(g) UAT Nov - Dec
(h) Prod Dec

Aren't the above a waterfall approach? If it's an iterative model, then where is
the schedule for iteration? :-)
Isn't it strange if the PLs of the teams use
such "waterfall" approach to schedule and plan resources their stands are supposed to be iterative ? Are they confused :-) or they have
some good project management reasons (that I'm unaware) to do so ?
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Hi,
From what you have mentioned above,it looks like it's an waterfall model.
But to make projects more effective and robust,it's recommened to use the iterative method.
It's all depends on the experience of the PL what experience they r having.If some one like waterfall,that PL will follow waterfall and if some one like iterative,that PL will follow iterative.but it's always recommend to use to iterative.We can use waterfall depending on the scenario.OOAD recommends iterative...


Regards,
James
Kodo Tan
Ranch Hand

Joined: Aug 14, 2001
Posts: 105
Hi James,
Thanks for the reply.
First, I want to say that I'm not against the waterfall or iterative methodology. What I feel that if the approach identified for the project is waterfall, then a waterfall approach is used for scheduling and resources planning. Similarly, if the iterative approach is identifed for the project, then it must be reflected in the schedule and resources planning.
What I don't really understand is that among almost all the Project Leaders I came across or worked with, they way of handling projects is in question. As I explained in my earlier posting, an apparent waterfall schedule/resources planning method is used for projects that they identified as "iterative".
These people can always tell you all sorts of bad things of waterfall - almost all the points you can lift from the software management books. But when they are assigned to lead teams, the results are diastrous and in most cases, developers are always blame for the project failure or delay.
james edwin
Ranch Hand

Joined: Nov 22, 2001
Posts: 393
Hi,
Quote
"Similarly, if the iterative approach is identifed for the project, then it must be reflected in the schedule and resources planning."
UNQUOTE
Ya i argee..it should be reflected in schedule and resources planning.Do u know any good site where we can find the sample from the start till end of the softwares life cycle with explanation and UML diagrams.(I mean Real life case study ..for study purpose)
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
Changes in development approaches don't happen overnight. Managers would have to be nuts to buy into processes that are different that what has worked in the past, or for which reliable excuses have been become institutionalized in the past, at least until they have evidence that the new processs is worth the new risks. Even if they new way is better, learning how to apply it takes time and entails unfamiliar risks.
What you may be able to do from the grass roots is to handle a very small project or two using a short-cycle iterative appoach. You'll learn how to use these approaches, and how to adapt them to your work environment. And you'll give others a chance to see that these approaches can work well, and that you are leaning how to use them. (Or not.) Then everybody will have a better basis for deciding whether and how to use them in larger and more important projects, and know more about how make them work when you do so.
And believe me, there is lots to learn from doing it. Books provide a lot to draw on, but when it comes down to it, experience is the teacher, at least for me.
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
I wonder if the people who frequent the Process forum might be able to help you with this question.
Kodo Tan
Ranch Hand

Joined: Aug 14, 2001
Posts: 105
<quote>
Changes in development approaches don't happen overnight. Managers would have to be nuts to buy into processes that are different that what has worked in the past, or for which reliable excuses have been become institutionalized in the past, at least until they have evidence that the new processs is worth the new risks. Even if they new way is better, learning how to apply it takes time and entails unfamiliar risks
</quote>
Yes, I agreed with this and that's why I'm not against waterfall approach. What I don't really understand is that there are some many Project Leaders who tell you how they want to handle the projects iteratively and how bad the waterfall model is if applied to the project but when comes to scheduling and resources planning, it's the "waterfall" approach.
End of the day, the developers are confused and you do not know whether your lead know their stuff
Pho Tek
Ranch Hand

Joined: Nov 05, 2000
Posts: 761

Conceptually it's not that difficult to
retrofit an iterative development process
into the existing project plan.
Here's my idea:
* Project Initialisation => Inception phase
* User req. + func spec => Elaboration phase
where you produce
user stories/cases
and requirements docs.
* Then you insert the construction phase with
multiple iterations. Each iteration works
on several use cases. "Works on" here means:
(optional: re-analyze), design, code, test, integration, test..
* Transition Phase - lump all the rest here.
Pho


Regards,

Pho
Gerry Giese
Ranch Hand

Joined: Aug 02, 2001
Posts: 247
Pho, you can only really call the Elaboration phase the first iteration through cases/requirement, because the iterative model implies that those functions happen during each iteration. The cases/requirements take less and less time each iteration, but it's quite possible that they will need to be iterated over all the way to the last iteration that produces the released software. Is your 'Transition' phase the same thing as deployment? Or is it maintenance?
Early Iterations
  • Lots of analysis, requirements, design
  • Some coding (usually prototype)
  • Little or no testing

  • Middle Iterations
  • Decreasing analysis, requirements, design
  • Increasing coding
  • Increasing testing

  • Last Iterations
  • Little or no analysis, requirements, design
  • Decreasing coding
  • Lots of testing

  • [ February 07, 2002: Message edited by: Gerry Giese ]
    [ February 07, 2002: Message edited by: Gerry Giese ]

    CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
    Author of Posts in the Saloon
     
    Don't get me started about those stupid light bulbs.
     
    subject: Iterative or Waterfall ?