1.2 SDLC, Waterfall & Prototyping Models

Software Development Life Cycle (SDLC)

The SDLC is the structured sequence of phases that a software project passes through from inception to retirement. The phases are identical across every model — what changes is order, iteration, and overlap.

Exam tip: When a question asks "Explain SDLC" — draw the 7-phase diagram, then describe each phase in 2–3 sentences with its deliverable.

---

1. The Waterfall Model (Royce, 1970)

The classical Waterfall model (Winston Royce, 1970) is the original SDLC model. Phases execute strictly in order — each phase must complete and be signed off before the next begins. Like water flowing down a series of steps, you cannot flow back.

Characteristics

• Sequential and rigid
• Document-driven (each phase produces a deliverable)
• Phase ends with formal review and sign-off
• Phase outputs are baselined — frozen and put under change control

When to use

• Requirements are clearly defined and stable (e.g. government contracts, regulated systems)
• Technology is well understood
• Project is short (3–6 months)
• Team is inexperienced (the structure helps)

Advantages

Waterfall earns its place in the toolbox through four genuine strengths. It is simple to understand and manage — every phase, every deliverable, and every milestone is explicit and named, which is invaluable for new teams and for project-management offices that audit progress. It produces strong documentation at each gate (feasibility report, SRS, design document, test plan), turning the project's own deliverables into a working knowledge base that survives staff turnover. It enforces a disciplined approach through formal sign-offs that prevent half-done work from leaking into the next phase. And it is easy to track progress — a status of "we are in Design, 40% complete" is meaningful in Waterfall in a way it is not in Agile.

Disadvantages

The same rigidity that gives Waterfall its strengths produces five well-documented weaknesses. First, it cannot accommodate changing requirements — yet real users discover their real needs only while using the product, and stable upfront requirements are the exception, not the rule. Second, working software arrives only at the very end; customers wait months to see anything tangible, and by then the market may have moved. Third, the model is high-risk for novel projects — if the requirements turn out to be wrong, the entire downstream pipeline of design, code, and tests must be redone. Fourth, there is no parallelism: design cannot start until requirements are 100% complete, so the calendar lengthens. Fifth, testing comes last and bugs are therefore expensive — a requirements bug discovered in testing forces a cascade of rework through every intermediate phase.

Famous failure: The waterfall was the dominant model in the 1980s. Many large fixed-price government contracts (US DoD-STD-2167A) mandated waterfall. Most of these projects either failed or were silently restructured.

---

2. The Prototyping Model

The Prototyping model addresses the central failure of waterfall: requirements are usually unclear until users see and use something. The team rapidly builds a prototype — a small, working approximation — and iterates with the customer until requirements are firm.

Types of prototyping

Prototyping has four canonical flavours. In a throwaway (rapid) prototype the team builds a quick approximation purely to clarify requirements and is then discarded — the production product is engineered cleanly from scratch with the clarified requirements in hand. In an evolutionary prototype the team starts with a small working version and refines it iteratively until it becomes the final product; the same code base evolves rather than being thrown away. An incremental prototype treats the project as a sequence of independently delivered, working increments — each increment is a usable chunk of functionality shipped to users while the next is being built. Extreme prototyping is a web-specific style that proceeds in three explicit phases — first a static HTML mock-up to lock the UI, then simulated services to validate the data flow, and finally integrated production services — popular in the early-2000s "web application" era.

Process steps

1. Identify a subset of key requirements
2. Quick design (UI mock + skeletal logic)
3. Build the prototype using rapid tools (UI builders, scripting)
4. Customer evaluates and gives feedback
5. Refine; loop back to step 1
6. When customer signs off, engineer the production product (throwaway case) or refine the prototype (evolutionary case)

Advantages

• Customer sees a working version early — confidence rises
• Requirements ambiguities surface quickly
• Reduces the risk of building the wrong product
• Useful when the user does not know exactly what they want (most real projects)

Disadvantages

• Customer may expect the prototype is the final product (it isn't — performance, security, scale haven't been engineered)
• Developers cut corners — the throwaway prototype is messy
• Hard to plan/estimate — number of iterations is unknown
• Risk of "prototype creep" — the throwaway accidentally ships to production

Real example: Mock-ups in Figma or Balsamiq, paper prototypes for mobile apps, and "click-through" wireframes are all examples of throwaway prototyping. Most modern UX practice is essentially prototyping.

---

Comparison: Waterfall vs Prototyping

---

Key Terms — Lesson 1.2

The terms below cover the SDLC framework and the first two process models. Each appears in every Unit-I PYQ on lifecycle models.

Feasibility Study — The first phase of the SDLC, which asks "should we build this at all?" across four dimensions: technical feasibility (do we have the technology and skills?), economic feasibility (is the cost-benefit favourable?), operational feasibility (will users actually use it?), and legal feasibility (regulatory compliance, IP, contracts). The deliverable is the feasibility report and a go/no-go decision.

SDD (Software Design Document) — The output of the design phase. Typically split into a High-Level Design (HLD) describing major modules, interfaces, and data flow, and a Low-Level Design (LLD) describing each module's internal classes, methods, and algorithms. SDD is the bridge between SRS and code.

Baseline / Baselined Deliverable — A formally reviewed, signed-off, and frozen version of a deliverable (SRS, design document, test plan). Once baselined, changes require a controlled change-request process. Baselining prevents quiet drift of requirements or design.

Waterfall Model — The classical sequential SDLC model proposed by Winston Royce in 1970, where each phase must be completed and signed off before the next begins. Ironically, Royce's own paper criticised pure waterfall and advocated feedback loops; later misreadings of the paper canonised the rigid version that became the textbook target of criticism.

Phase Containment — The Waterfall principle that each phase produces a verifiable deliverable that is reviewed and signed off before the next phase begins. The goal is to keep defects contained inside the phase that introduced them rather than letting them propagate.

Prototyping Model — A process model that addresses Waterfall's central weakness by quickly building a working approximation of the system, letting users evaluate it, and iterating until requirements stabilise. The prototype itself may be discarded (throwaway) or evolved into the final product (evolutionary).

Throwaway / Rapid Prototype — A prototype built specifically to clarify requirements and then discarded. The final product is engineered fresh from the clarified requirements. Common implementations: Figma mock-ups, Balsamiq wireframes, paper prototypes, click-through HTML pages.

Evolutionary Prototype — A prototype that becomes the final product through successive refinement rather than being discarded. The same code base grows from skeleton to production. Risk: corners cut in the early prototype may persist as technical debt.

Incremental Prototype — A model where the system is delivered in a sequence of working increments, each adding functionality. Each increment is a usable product that real users can adopt while the next increment is being built.

Extreme Prototyping — A web-specific three-stage prototyping pattern: static HTML mock-up → simulated services → integrated production services. Popular in the early-2000s web era; still influential in modern frontend-first development.

Sign-off — A formal record that a stakeholder (customer, project manager, technical lead) has reviewed and accepted a phase deliverable. Sign-offs are gates: the next phase cannot begin without them. They also limit future scope creep — "this was approved on date X".

Royce's Original Paper (1970) — Winston Royce's "Managing the Development of Large Software Systems" (Proceedings of IEEE WESCON, 1970). The paper presents waterfall as a starting point and then immediately argues for feedback between adjacent phases. The "pure" waterfall criticised in textbooks is actually a misreading of Royce.

Prototype Creep — A common project failure mode where a throwaway prototype, intended to be discarded, is accidentally promoted to production because management or customers see it working and demand it be shipped. The result is a fragile product carrying every shortcut taken to build the prototype fast.

---

Study deep: process model trade-offs

1. No "best" model exists. The right model depends on (a) requirements clarity, (b) technology familiarity, (c) team experience, (d) customer availability, (e) risk profile. A government accounting system with a frozen scope of work is a Waterfall candidate; a startup MVP is a Prototype candidate.

1. Hybrid is the norm in practice. Most real projects use Waterfall for the requirements and architecture phases (to get stakeholder sign-off), then switch to iterative mode for implementation. This is sometimes called the "W-model" or "incremental waterfall."

1. The IPU paper expects you to recommend a model for a given scenario. Common patterns: bank cheque-clearing system → Waterfall; e-commerce startup → Prototype or Agile; pacemaker firmware → V-Model (we'll see in next lesson); large data-warehouse migration → Spiral.

1. Royce's 1970 paper actually criticised pure waterfall. The paper is titled "Managing the Development of Large Software Systems" and Royce advocates feedback loops between adjacent phases. The misreading of his paper led to the rigid waterfall that became the textbook target of criticism.

PYQ pattern (recurring): "Explain the Waterfall model with a diagram. State its advantages, disadvantages and when it should be used." — Use the diagram, 4 advantages, 5 disadvantages, 3 'when-to-use' cases.