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?