SDLC Models: Waterfall vs Agile

SDLC models are common in HR-technical and project rounds — "Waterfall vs Agile" and "which model would you choose?" test whether you understand software process, not just code. Knowing the phases and trade-offs is enough to answer well.

The SDLC phases

The Software Development Life Cycle structures development into phases: Requirements → Design → Implementation → Testing → Deployment → Maintenance. Different models arrange these differently.

Waterfall

A linear, sequential model — each phase completes before the next begins, with heavy upfront planning and documentation. Great when requirements are fixed, but inflexible: late changes are costly, and working software appears only near the end.

Agile

An iterative, incremental model — work is delivered in short sprints, with continuous feedback and adaptive requirements. Values working software and customer collaboration over exhaustive docs. Frameworks: Scrum (sprints, roles) and Kanban (continuous flow).

	Waterfall	Agile
Flow	sequential	iterative
Requirements	fixed upfront	evolving
Feedback	late	continuous
Best for	stable, regulated	changing needs

Exam Tricks & Tips

• 🎯 Waterfall = sequential & rigid (fixed requirements); Agile = iterative & flexible (changing requirements) — the headline contrast.
• 🎯 Agile delivers working software early and often in sprints; Waterfall delivers only at the end.
• 🎯 Scrum and Kanban are Agile frameworks — Scrum uses fixed sprints; Kanban uses continuous flow/WIP limits.
• 🎯 Choose Waterfall for stable, regulated projects; Agile for evolving ones. The V-model pairs each Waterfall phase with a testing phase.
• 🎯 The Agile Manifesto favours individuals & interactions, working software, customer collaboration, and responding to change.
• ❌ Common mistake: calling Agile "no planning/documentation" — it deprioritises exhaustive docs, but still plans per iteration.

Expected pattern

"Waterfall vs Agile", "phases of SDLC", "what is Scrum/a sprint?", "when would you pick Waterfall over Agile?", and "what is the V-model?".

Quick recap

SDLC phases: requirements→design→implementation→testing→deployment→maintenance. Waterfall = linear, rigid, upfront docs, best for fixed requirements. Agile = iterative sprints, adaptive, working software over docs (Scrum/Kanban). Pick by requirement stability. V-model pairs each phase with testing.

Cover the answer, recall, then check. 11 cards on SDLC models.

Q1. What are the main phases of the SDLC?
A1. Requirements, Design, Implementation, Testing, Deployment, and Maintenance.

Q2. What is the Waterfall model?
A2. A linear, sequential model where each phase must complete before the next begins, with heavy upfront planning.

Q3. What is the Agile model?
A3. An iterative, incremental approach delivering working software in short sprints with continuous feedback and adaptation.

Q4. Key difference between Waterfall and Agile?
A4. Waterfall is sequential and rigid with fixed requirements; Agile is iterative and flexible, embracing changing requirements.

Q5. When is Waterfall a good choice?
A5. For projects with stable, well-defined requirements, or regulated domains needing thorough documentation.

Q6. Name two Agile frameworks.
A6. Scrum (fixed-length sprints, defined roles) and Kanban (continuous flow with WIP limits).

Q7. What is a sprint in Scrum?
A7. A short, fixed time-box (often 1-4 weeks) in which a potentially shippable increment of software is produced.

Q8. When does each model deliver working software?
A8. Agile delivers increments early and continuously; Waterfall delivers only near the end.

Q9. What is the V-model?
A9. An extension of Waterfall that pairs each development phase with a corresponding testing phase (verification & validation).

Q10. What does the Agile Manifesto value?
A10. Individuals and interactions, working software, customer collaboration, and responding to change over rigid processes/plans.

Q11. Does Agile mean no documentation or planning?
A11. No — it deprioritizes exhaustive upfront documentation but still plans and documents iteratively per sprint.

Software isn't just written — it's managed through a lifecycle from idea to maintenance. The SDLC structures that journey, and the great debate — Waterfall vs Agile — is a staple of software-engineering interviews and exams.

Core idea: the Software Development Life Cycle (SDLC) is the structured process of building software through phases: requirements → design → implementation → testing → deployment → maintenance. Waterfall runs these phases sequentially (each fully done before the next); Agile runs them iteratively in short cycles that deliver working software repeatedly.

How it works

Beginner — the SDLC phases

1. Requirements — gather and document what's needed.
2. Design — architecture and detailed design.
3. Implementation — write the code.
4. Testing — verify it works and meets requirements.
5. Deployment — release to users.
6. Maintenance — fix bugs, add enhancements.
   Every model organises these same phases differently.

Intermediate — Waterfall

Waterfall completes each phase fully before the next begins, like water flowing down steps — no going back easily.

• Strengths: simple, well-documented, clear milestones; good when requirements are fixed and well-understood (e.g. regulated/hardware projects).
• Weaknesses: rigid — a requirement change late in the cycle is expensive; working software appears only at the end, so mistakes are found late.

Advanced — Agile and the iterative model

Agile (Scrum, Kanban, XP) develops in short iterations/sprints (1–4 weeks), each producing a potentially shippable increment, with continuous customer feedback. It's founded on the Agile Manifesto's values: individuals and interactions over processes, working software over documentation, customer collaboration over contract negotiation, responding to change over following a plan.

Waterfall:  Req -> Design -> Code -> Test -> Deploy   (once, sequentially)
Agile:      [Req->Design->Code->Test->Deploy]  repeated every sprint, feedback each loop

• Strengths: adapts to changing requirements, delivers value early and often, tight feedback.
• Weaknesses: less predictable scope/cost up front, lighter documentation, needs engaged customers and disciplined teams.

Worked example — choosing a model

Two projects:

1. A pacemaker's firmware with strict regulatory requirements fixed in advance and heavy documentation/certification needs. → Waterfall: requirements won't change, and each phase must be signed off and documented before the next.
2. A consumer mobile app in a competitive market where user needs are uncertain and evolving. → Agile: ship a minimal version, learn from real usage, and iterate every sprint.
   The deciding factors: requirement stability (fixed → Waterfall, evolving → Agile), need for early feedback, and tolerance for changing scope. There's no universally "better" model — fit the process to the problem. Many real teams use hybrids (e.g. Agile delivery with some up-front architecture).

Interview & exam relevance

Common asks: "list the SDLC phases", "Waterfall vs Agile — pros, cons, and when to use each", "what are the Agile Manifesto values", "what is a sprint / iteration", and "what does the V-model / Spiral model add" (V-model pairs each phase with a testing level; Spiral adds risk analysis). The requirement-stability decision rule is the key insight.

Tricks & gotchas

• Waterfall = sequential, works for fixed requirements; Agile = iterative, works for evolving requirements.
• Agile still does all SDLC phases — just repeatedly per iteration, not once.
• Agile is a mindset/values (the Manifesto); Scrum and Kanban are specific frameworks implementing it.
• Mnemonic: "Waterfall flows once; Agile loops often."

Worked Example

Problem: A startup is building a consumer app whose exact features will evolve based on user feedback; a separate team is building avionics software with fixed, safety-certified requirements. Recommend Waterfall or Agile for each, and justify using how each model handles changing requirements, delivery, and risk.

Solution:
Waterfall is a linear, sequential model: Requirements → Design → Implementation → Testing → Deployment → Maintenance, each phase completed and signed off before the next begins. It assumes requirements are known and stable up front, produces heavy documentation, and delivers working software only near the end.

Agile is iterative and incremental: work proceeds in short cycles (sprints of 1–4 weeks), each producing a potentially shippable increment. Requirements are expected to evolve; the customer gives feedback every iteration, and the plan adapts.

Consumer app (evolving features, feedback-driven) → Agile. The requirements are uncertain and will change as users react, which is exactly Agile's strength: short sprints deliver a usable increment early, feedback steers the next sprint, and change is embraced rather than resisted. Waterfall would be risky here — locking requirements up front then discovering after months of development that users want something different is the classic Waterfall failure (a big, late, wrong deliverable).

Avionics software (fixed, safety-certified requirements) → Waterfall (or a V-model variant). Requirements are stable and must be fully specified, reviewed, and certified before implementation; each phase needs formal documentation and sign-off for audit/safety. Waterfall's rigorous, traceable, phase-gated structure fits regulated domains where change is rare and verification against a frozen spec is mandatory. Agile's frequent scope changes would undermine certification.

Trade-offs to note: Waterfall gives predictability and thorough documentation but discovers defects/mismatches late and handles change poorly (a change late in the cycle is expensive). Agile gives fast feedback, early value, and flexibility but has lighter documentation and less up-front predictability of the final scope/cost.

Answer: Use Agile for the consumer app — its requirements evolve, so iterative delivery with continuous user feedback minimises the risk of building the wrong thing. Use Waterfall for the avionics software — stable, safety-certified requirements need sequential, documented, phase-gated development with verification against a frozen spec. Model choice follows requirement stability and risk profile.