Discussion on:
View:
Show:
What application development model does your organization generally follow? Is it a formal implementation or do things just happen to follow a particular model? Is there flexibility? What development model do you prefer?
I think the article gave an adequate portrayal of a waterfall methodolgy and accurately describe what proponents see as its advantages. I think, however, the article showed a misunderstanding of the criticisms of the waterfall approach. It is not so much a trade-off between the advantages of waterfall versus the advantages of other approaches as it is a fundamental questioning of whether the advantages of waterfall are actually realize.
First, I would disagree with the assertion that "every phase has a defined start and end point." While it is straight forward to track when effort was started and stopped for a particular phase, the level of completion of effort under the phase is highly subjective. Objective indications only begin to surface in the testing phase and become fully visible after deployment.
Second, I question the assertion that "it's much easier to catch and correct possible flaws at (an earlier) stage than at (a later) stage". It is extremely difficult to identify ommissions and how the system will affect workflow outside of actual usage. It is also no more difficult to enter new operation for a system in a code editor than in a word processor or a diagramming tool. The interactions and constraints are also much easier to analyze and evaluate in a working model than on paper.
Last, I challenge the assumption that the "customers don't really know what they want up-front". The users know how to do their jobs; in fact they are the experts. What is not being communicated is how the system will affect their abilities to do their jobs. The waterfall approach does not adequately communicate this.
The waterfall approach is based on near perfect execution of each phase, but does not provide a mechanism to measure the completeness of a phase. This sets up the classic cost versus quality conundrum. The cost of spending extra time and money on a phase is obvious, the benefit, however, can only be evaluated after completion of all phases. The constant pressure to do just a little bit more without a means to identify the resulting benefit leads to both slipping schedules and increased costs.
The true criticism of waterfall is that it fails to deliver on its advertised benefits. When waterfall was the only alternative to ad hoc chaos, its assumptions went unchallenged. Given the current state of software development, it is now time to review and validate the underlying assumptions of waterfall.
First, I would disagree with the assertion that "every phase has a defined start and end point." While it is straight forward to track when effort was started and stopped for a particular phase, the level of completion of effort under the phase is highly subjective. Objective indications only begin to surface in the testing phase and become fully visible after deployment.
Second, I question the assertion that "it's much easier to catch and correct possible flaws at (an earlier) stage than at (a later) stage". It is extremely difficult to identify ommissions and how the system will affect workflow outside of actual usage. It is also no more difficult to enter new operation for a system in a code editor than in a word processor or a diagramming tool. The interactions and constraints are also much easier to analyze and evaluate in a working model than on paper.
Last, I challenge the assumption that the "customers don't really know what they want up-front". The users know how to do their jobs; in fact they are the experts. What is not being communicated is how the system will affect their abilities to do their jobs. The waterfall approach does not adequately communicate this.
The waterfall approach is based on near perfect execution of each phase, but does not provide a mechanism to measure the completeness of a phase. This sets up the classic cost versus quality conundrum. The cost of spending extra time and money on a phase is obvious, the benefit, however, can only be evaluated after completion of all phases. The constant pressure to do just a little bit more without a means to identify the resulting benefit leads to both slipping schedules and increased costs.
The true criticism of waterfall is that it fails to deliver on its advertised benefits. When waterfall was the only alternative to ad hoc chaos, its assumptions went unchallenged. Given the current state of software development, it is now time to review and validate the underlying assumptions of waterfall.
How many software projects worth the name have you commenced where you knew what was required, how to do it, how long it would take, the right resources were avilable and the comfort of knowing nothing that would impact the final deliverables would occur until you'd banked the cheque.
My curent count is erm, none !
The question to ask Mark was , how many of you are still foolishly trying to make your projects fit your preferred lifecycle.
My curent count is erm, none !
The question to ask Mark was , how many of you are still foolishly trying to make your projects fit your preferred lifecycle.
I'm not a big fan of the Waterfall Method - real life is a chaotic stream were predictions of the future just get you in trouble.
Human nature, however, is a constant. What user's want changes over time -- it is inevitable.
Human nature, however, is a constant. What user's want changes over time -- it is inevitable.
I ever heard of it working was nuclear reactor safety or similar. Not something you make up as you go along that is it.
Do it with agile Now what's the priority the control rods or .....
LOL
Do it with agile Now what's the priority the control rods or .....
LOL
for the cowboy programmer, and people who like job security with 'oral' documentation.
(See 'Extreme Programming Refactored: The Case Against XP) by Matt Stephens and Doug Rosenberg) - their pair programming seems really stupid.
Tho maybe you don't mean XP by Agile? (Alistair Cockburn just had a webinar entitled 'Agile..')
Really, for more than trivial projects, perhaps the best is intermediate between these, such as RUP where core systems are created to have a working infrastructure, and use cases added on top.
And users can get rid of the major problems with stacks of boring 'requirements' by using modeling software such as iRise or Sofea's Prophesy to do this visually and step end user thru to verify.
(See 'Extreme Programming Refactored: The Case Against XP) by Matt Stephens and Doug Rosenberg) - their pair programming seems really stupid.
Tho maybe you don't mean XP by Agile? (Alistair Cockburn just had a webinar entitled 'Agile..')
Really, for more than trivial projects, perhaps the best is intermediate between these, such as RUP where core systems are created to have a working infrastructure, and use cases added on top.
And users can get rid of the major problems with stacks of boring 'requirements' by using modeling software such as iRise or Sofea's Prophesy to do this visually and step end user thru to verify.
This was a good high level overview of the Waterfall Methodology. The comments so far are interesting and all over the map. An important point to bring out is that all methods have the same goal, ?To provide the customer a functional application that meets all of their needs as defined in the final Statement of Work. No more and no less.
The choice of method is determined by many things and all of the ?Methods? have a place in the manager?s arsenal. Projects are different and therefore require different solutions.
In my experience, the Waterfall method is best when the requirements are well defined and stable; the process unfolds in an orderly sequence of tasks. The Waterfall method works worst when requirements are not well defined and stable. The other methods were grown out of the need to define requirements. Too often these other methods start out well and then begin skipping required tasks.
1. Requirements are never stabilized.
2. Documentation is not up to date.
3. Testing becomes minimized.
4. Tasks that need to be sequential are done in parallel.
5. Too much time is spent in Development for ?New Work? and ?Rework?.
6. etc.
Whatever method is the method of choice, learn to:
1. Say ?No? when that is the right answer
2. Be realistic not overly optimistic
3. Be ?Honest?
4. Manage ?Scope Creep?
5. Set and maintain ?Expectations?
6. Manage ?Risks?
7. Always keep the ?Big Picture?
8. If something is not working, don?t continue doing it, make a change
9. If you have time to do it over, why not do it right the first time.
Make a plan, follow the plan, manage the plan and finish the plan.
The choice of method is determined by many things and all of the ?Methods? have a place in the manager?s arsenal. Projects are different and therefore require different solutions.
In my experience, the Waterfall method is best when the requirements are well defined and stable; the process unfolds in an orderly sequence of tasks. The Waterfall method works worst when requirements are not well defined and stable. The other methods were grown out of the need to define requirements. Too often these other methods start out well and then begin skipping required tasks.
1. Requirements are never stabilized.
2. Documentation is not up to date.
3. Testing becomes minimized.
4. Tasks that need to be sequential are done in parallel.
5. Too much time is spent in Development for ?New Work? and ?Rework?.
6. etc.
Whatever method is the method of choice, learn to:
1. Say ?No? when that is the right answer
2. Be realistic not overly optimistic
3. Be ?Honest?
4. Manage ?Scope Creep?
5. Set and maintain ?Expectations?
6. Manage ?Risks?
7. Always keep the ?Big Picture?
8. If something is not working, don?t continue doing it, make a change
9. If you have time to do it over, why not do it right the first time.
Make a plan, follow the plan, manage the plan and finish the plan.
I agree on every thing ... the pros and cons and all but the fact is that the real projects in india we very rarely follow this deep documented pattern..
The Burst production technique we call it... No Analysis or Design phases .. just raw coding.. (works fine for lone coders
)the trick is implementing the feasible requirements one at a time and patching a proto from the build code.. Release the proto on that requirement to the customer on the testing of that requirement proceed on to another part of the project which is less dependent on the currently tested code..
I did it for an nice inventory management project.. and AI based vendor selection... i developed a proto for data entry and mantainance for the client and when the client is busy with that proto populating the database .. i turn to the neural network that is to be trained on the process.. logs are very use full as when that proto is taken away and then replaced,the log can restore and provide valuable info on incoming improved proto.. This is not Prototype aproach as there is no such thing as the design here... when we use some nice IDE like VS then the job of design is nearly an act of beautification.. and for buisness consultancy projects like vender selector.. Inventory and other such projects the Burst production method works beautifully.. try it for a large project like a look-alike-GNOME or UI for DOS then this is very easy to use... use all the tricks
Like Core Engine with Waterfall or Spiral and all the other with Burst Production..
The Burst production technique we call it... No Analysis or Design phases .. just raw coding.. (works fine for lone coders
)the trick is implementing the feasible requirements one at a time and patching a proto from the build code.. Release the proto on that requirement to the customer on the testing of that requirement proceed on to another part of the project which is less dependent on the currently tested code..I did it for an nice inventory management project.. and AI based vendor selection... i developed a proto for data entry and mantainance for the client and when the client is busy with that proto populating the database .. i turn to the neural network that is to be trained on the process.. logs are very use full as when that proto is taken away and then replaced,the log can restore and provide valuable info on incoming improved proto.. This is not Prototype aproach as there is no such thing as the design here... when we use some nice IDE like VS then the job of design is nearly an act of beautification.. and for buisness consultancy projects like vender selector.. Inventory and other such projects the Burst production method works beautifully.. try it for a large project like a look-alike-GNOME or UI for DOS then this is very easy to use... use all the tricks
Like Core Engine with Waterfall or Spiral and all the other with Burst Production..
i certainly get information and learned from it!
who wrote this article? who do i credit?
The reality is that you need to balance the overall client needs definition with their perception horizon. Agile can be used as a lazy approach to the needs definition because it allows adaption as you go. But if its not applied an controlled correctly it can easily lead to chaos. Waterfall on the other hand fixes the requirement at the beginning on the assumption that these are constants the reality is somewhere in between. The cycle or methodology has to match the client and the project not vice versa. The further out the delivery horizon is the more critical the method becomes as very few variables can remain constant over long periods of time. On the other hand using the customers indecision or requirement for flexibility as a reason can just as easily result in lack of context-poor business case definition-and a broad acceptance of implied results ie you develop what you think the customer wanted/asked for and then fight it out when its wrong( or accept defeat and re do). The method has to start with a plan not the other way round.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
