• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Iterative or Waterfall ?

 
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
Ranch Hand
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Kodo Tan
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 393
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
 
Ranch Hand
Posts: 399
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 399
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wonder if the people who frequent the Process forum might be able to help you with this question.
 
Kodo Tan
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<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
 
Ranch Hand
Posts: 782
Python Chrome Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic