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 ?
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...
Joined: Aug 14, 2001
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.
Joined: Nov 22, 2001
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)
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.
Joined: Feb 22, 2001
I wonder if the people who frequent the Process forum might be able to help you with this question.
Joined: Aug 14, 2001
<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
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
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
Decreasing analysis, requirements, design
Little or no analysis, requirements, design
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