notesonly.in

One notebook for every subject — open it anywhere.

Log in

SDLC Models: Waterfall, Spiral and Agile With easy examples.

SDLC stands for Software Development Life Cycle: the structured journey software takes from an idea to a working product and beyond. Its phases are planning, analysis, design, development, testing, deployment and maintenance. An SDLC model is a recipe for ordering and repeating those phases, and the three famous ones are Waterfall, Spiral and Agile.

Choosing the right model matters because it decides how risk, cost and changing requirements are handled. Pick Waterfall for a project whose requirements will never move, and you get clean predictability; pick it for a startup app whose users change their minds weekly, and you get an expensive disaster. Engineers choose models the way builders choose foundations — matched to the ground.

Key Concepts

  • Waterfall: phases run strictly in sequence — requirements, design, implementation, testing, deployment, maintenance. Each phase is completed and signed off before the next begins, like water falling down steps.
  • Spiral: the project loops through four quadrants repeatedly: determine objectives, identify and resolve risks, develop and test, then plan the next loop. Each loop produces a more complete prototype, and risk analysis is the heart of the model.
  • Agile (Scrum): work is sliced into short sprints of 1–4 weeks. A product backlog lists desired features as user stories, the team pulls stories into each sprint, holds brief daily standups, and demos working software at the sprint review.
  • Requirement stability: how likely the requirements are to change — the single biggest factor in choosing a model.
  • Velocity: in Agile, the amount of work (story points) a team reliably finishes per sprint, used to forecast delivery dates.

How It Works

  • Waterfall in action: a team building payroll software for a bank first freezes the tax rules as requirements, then designs the database, then codes every module, then tests the whole system, then deploys. Going backwards is expensive, so requirements must be rock solid.
  • Spiral in action: a team building a delivery drone first loops on the riskiest question — can it lift the payload? — with a cheap prototype, then loops again on navigation, then on battery life. Each loop kills the biggest remaining risk before more money is spent.
  • Agile in action: a startup building a food-delivery app ships a basic ordering flow in sprint 1, adds payments in sprint 2, and reshuffles the backlog whenever user feedback arrives. Working software exists from the very first sprint.

Worked Example

A college team has 12 weeks to build a canteen ordering app. Compare a Waterfall schedule with an Agile plan for the same project.

  1. Waterfall split: requirements 2 weeks + design 2 weeks + coding 5 weeks + testing 2 weeks + deployment 1 week = 12 weeks exactly.
  2. Risk: if the canteen staff change the menu-format requirement in week 9, the team must redo design and code — the most expensive kind of change.
  3. Agile split: six 2-week sprints. The team's measured velocity is 25 story points per sprint, so capacity = 6 × 25 = 150 points.
  4. The backlog totals 140 points, which fits inside 150 with a 10-point buffer for surprises.
  5. If feedback in sprint 3 demands a new feature worth 15 points, the team swaps out 15 points of lower-priority work — the plan absorbs change instead of breaking.

Common Misconceptions

  • "Agile means no planning or documentation." Agile plans constantly — every sprint is planned — it just plans in small horizons instead of one giant upfront plan, and it documents what is valuable rather than everything imaginable.
  • "Waterfall is always wrong and outdated." For fixed, well-understood requirements — tax software, medical devices, construction-adjacent systems — Waterfall's discipline and clear milestones are genuinely the right choice.
  • "Spiral is just Waterfall repeated." The repetition is not the point; explicit risk analysis in every loop is. A team can loop through phases without ever doing Spiral's signature risk evaluation.

Real-World Applications

  • Waterfall: government tenders, banking systems and safety-critical software where requirements are frozen by regulation.
  • Spiral: large defence, aerospace and research projects where each phase carries million-dollar technical risks.
  • Agile/Scrum: startups, mobile apps and web products where user feedback reshapes the product every few weeks.

Waterfall bets on stable requirements, Spiral bets on killing risks early, and Agile bets on adapting fast. There is no universally best model — only the model whose bet matches your project's reality — so learn to read requirement stability and risk before you pick.