Software development methodologies: agile and waterfall
Computer Science · GCSE · The School
Waterfall: one stage completed before the next begins
WATERFALL moves through fixed stages in order: requirements, design, implementation, testing, deployment, maintenance. Each stage is completed fully before the next begins. Like water flowing downhill, it does not flow backward. Once a stage is signed off, going back to change it is difficult and costly.
Why waterfall suits some projects well
Waterfall works well when requirements are clear and unlikely to change. Software for a well-understood, regulated process is a good example. Thorough upfront planning and documentation make progress easy to track against a plan. It also suits large teams working on clearly separated parts of a big system.
Agile: build a small piece, get feedback, repeat
AGILE breaks a project into short cycles, often called SPRINTS. Each one produces a small working piece of the product that a client or user can see and react to. Requirements can change between sprints, in response to that feedback, rather than being fixed at the very start of the whole project. That feedback loop is the whole point of working this way.
Why agile suits some projects well
Agile works well when requirements are unclear at the start. It also suits projects where requirements are genuinely likely to change, as the client sees early working versions and reconsiders what they actually want. Regular working versions let problems surface early, instead of only at the very end of one long cycle.
A worked comparison: two different projects
Software controlling a medical device has fixed, safety-critical requirements, set by regulation. Waterfall suits it: thorough testing at each fixed stage matters more than speed here, and the requirements are not going to change midway through. A start-up building a new app, still working out what users actually want, suits agile instead. Early working versions and fast feedback matter more than a rigid upfront plan for a product nobody has used yet.
Neither methodology is simply "better"
Waterfall's strength is a clear, trackable plan. That becomes a weakness once requirements turn out to be wrong partway through, since changing course by then is expensive. Agile's strength is flexibility. Without firm discipline, that can become a weakness too, since a project can drift without ever reaching a clear finish. Name the specific project feature that makes ONE methodology suit it, not just a general preference for whichever sounds more modern.