The waterfall software development model is the traditional process used by developers to create software - I include web application development into the category of software. It’s been around as an accepted methodology since the 70’s. It basically consists of:
- Requirements Gathering
- Design Phase
- Implementation Phase
- Verification Phase
- Maintenance Phase
Presumably at each phase of the project, there are sign offs and reviews with the stakeholders, the end users of the software. Sometimes you’ll hear phase 3 referred to as the big bang phase. This is because after phase 1 & 2 are complete, the developer(s) goes off for a period of time, codes the application and bang, delivers it for phase 4. In fact, most the time, phase 3 is going to be the longest phase (not counting continued maintenance).
This is exactly why the waterfall method sucks. The developer - and other team members - better hope they ask a cubic ton of questions in phase 1 and can accurately convey the project in phase 2. They also better hope that the stakeholders know exactly what they want. Because if not, phase 4 is going to put developers in an agitated state. In my experience, most stakeholders only have a slight idea of what they want. They aren’t techies and can’t tell you with 100% confidence if they want their software to bake bread or make toast - subtle difference right?
So you’re team rolls into phase 4 and the stakeholders are like, “OMG! WTF?” And you’re like, “What?! It does what you wanted. Don’t you remember us going over it when we showed you those diagrams and schemas?” And they’re still like, “OMG! WTF?”
This is why the iterative approach - sometimes referred to as agile development - has become so popular. It allows developers to use rapid application development (RAD) to prototype software. So there is never a “surprise, here it is” moment. Instead the stakeholder moves down the process with you taking ownership into the final product. It’s some what similar to the creative design process, but for geeks.
Word of warning though, don’t expect developers to jump on this model though. They tend to prefer having a set of specs, sitting down and coding to those, and then moving on. They may see iterations and undocumented changes as something bad.
Anyway, not writing a book here. Let me know your experiences with software development. Do you prefer agile interative development or waterfall development?
3 responses so far ↓
1 TJ Crawford // Apr 4, 2008 at 1:34 am
I think the lines can blur and that Agile is really an approach (speaking from management not developer side). If you think about it an iterative approach, agile is just several small waterfall projects broken out. Some people take Agile to heart and are turning out nightly/daily builds that get rolled live on close to the same schedule. Maybe I’m off base but theoretically the lines can blur on a few different levels.
2 Josh Kenzer // Apr 4, 2008 at 11:01 am
TJ,
You are write that iterative is several small waterfall projects, and that’s the good thing. Rather then getting down the entire path, there is opportunity to revise, ebb and flow.
The length of time is dependant completely on the project and the project requirements. The book Head First Software Development says 20 working days is a good guideline, but you should always customize that to the project.
3 Labs » Agile Software Development // Jun 26, 2008 at 10:58 am
[...] Waterfall Model Sucks [...]
Leave a Comment