Professional Scrum Master I (PSM I) Certification Study
The Waterfall Model
How sequential software development works, why it became influential, where it still fits, and why late feedback creates expensive risk
Estimated reading time: 25 minutes
By João Ricardo Dutra••Complete article
Chapter objective
Understand as a , sequential approach to software development; examine its historical roots and traditional phases; recognize the contexts in which it can be useful; and understand why changing requirements, , and create the conditions that iterative and empirical approaches were designed to address.
Introduction: Why Still Matters to a Student
is easiest to understand when you ask not only how work flows, but what must be believed about the future for that flow to remain reliable.
is one of the most recognizable ideas in the history of software project management. Even people who have never formally studied software engineering have seen the familiar descending sequence: requirements, analysis, design, implementation, testing, deployment, and maintenance. Each phase appears to flow into the next, suggesting order, control, and a reassuring promise: if we understand the problem first, design the solution carefully, and execute the plan with discipline, we should be able to deliver the expected result at the expected time and cost.
That promise is powerful because it reflects a very human desire to transform uncertainty into a plan. In many areas of engineering, that instinct is sensible. Before constructing a bridge, engineers calculate loads, define materials, approve drawings, and coordinate work that would be extraordinarily expensive to redo after construction. When early software projects grew in size during the 1950s, 1960s, and 1970s, organizations naturally looked for structured engineering processes that could make programming more predictable, auditable, and manageable. Sequential lifecycle models emerged in that environment.
For a candidate, matters for a deeper reason than history. did not appear in an intellectual vacuum. Its emphasis on , frequent inspection, adaptation, short feedback cycles, , and usable increments becomes much easier to understand when contrasted with the risks of long, phase-based delivery. If is reduced to a cartoon in which foolish people refused to talk to customers until the end, the learner misses the real lesson. solved genuine coordination problems. Its weakness appears when a predictive model of work is applied to a domain in which the problem, solution, market, technology, and user expectations continue to evolve while the work is being performed.
This chapter therefore treats neither as a villain nor as a universal best practice. It is a model with assumptions. When those assumptions are reasonably true, a sequential approach can provide clarity and discipline. When those assumptions are false, the apparent certainty of the plan can conceal growing risk. Understanding those assumptions is more valuable than memorizing a diagram, because it teaches you to recognize why modern and approaches organize learning differently.
What Is the ?
The is a approach in which a project is organized primarily by stages of activity. A broad version of the flow begins by discovering and documenting what must be built, continues through analysis and technical design, moves into implementation, then proceeds to verification and validation, deployment, and ongoing maintenance. The image of water flowing downward is useful because it communicates the central idea: work progresses through a sequence of increasingly concrete stages.
In a strict interpretation, each phase is substantially completed and approved before the next phase begins. Requirements become an input to analysis; analysis becomes an input to design; design becomes an input to implementation; implementation becomes an input to testing. Progress is often represented by completed documents, approved baselines, milestone reviews, phase gates, and percentage-complete reporting. Change is possible, but after a phase has been baselined, change normally requires explicit control because it can affect work already derived from the previous assumptions.
The crucial characteristic is not merely that activities happen in an order. Every development approach has some logical dependencies: you cannot test code that does not exist, and you cannot design a useful solution without some understanding of the problem. What distinguishes thinking is the tendency to organize a large body of scope by activity across the whole project. Analysts analyze most or all of the scope, designers design most or all of it, programmers implement most or all of it, and testers verify most or all of it later. turns this decomposition sideways: a smaller slice of functionality moves through analysis, design, coding, testing, and feedback, then the team repeats the cycle for additional functionality.
is also closely associated with . A predictive plan tries to determine a significant portion of scope, schedule, dependencies, resources, and cost in advance. The plan becomes a baseline against which execution is measured. This does not mean no learning occurs. It means the management system is designed around the assumption that variance from the original plan is primarily something to control, rather than a normal consequence of learning in a complex environment.
Historical Origin and the Royce Nuance
The modern story of is commonly traced to Winston W. Royce's 1970 paper, "Managing the Development of Large Software Systems." The paper included a well-known diagram in which major development activities appeared in a descending sequence. That diagram later became strongly associated with the . Yet an important historical detail is often lost: Royce did not use the term "" in the paper, and he did not simply recommend a naive one-pass sequence as the ideal way to build large software.
Royce was describing the difficulties of large software development and explicitly recognized that a purely sequential interpretation created serious risk. His discussion included feedback between stages and recommendations intended to reduce the danger of discovering design and integration problems too late. In other words, the document commonly remembered as the source of also contains an early warning about the weaknesses of treating software development as a clean, one-directional cascade.
Why, then, did phase-based processes become so influential? The answer lies partly in the technological and organizational environment. Computing resources were expensive. Build and test cycles could be slow. Large projects often involved government, defense, aerospace, telecommunications, finance, or other institutions that required documentation, budgets, contracts, auditability, and formal approvals. Teams were organized by specialty, and communication across organizational boundaries was expensive. A process that defined what each specialist group should produce for the next group offered administrative clarity.
Sequential models also fit conventional project-management logic. A manager could construct a work breakdown structure, estimate phase durations, allocate specialists, create milestone dates, and track planned versus actual progress. This produced useful artifacts for procurement, governance, and executive reporting. The difficulty was that the management representation could look orderly even while the underlying product assumptions remained untested. A requirements document could be 100 percent complete without proving that users would value the resulting software. A design could be formally approved without proving that the integrated system would perform adequately. 's history is therefore also a history of the tension between administrative visibility and product reality.
The Traditional Phases
Different organizations use different labels, and real projects often contain overlap or feedback between phases. Still, the following seven-stage sequence is a useful model for understanding classic software development. The value of studying the phases is not to memorize a rigid recipe, but to understand what knowledge each phase is expected to produce and what happens when that knowledge is treated as more certain than it really is.
1. Requirements
The requirements phase defines the needs, constraints, expected capabilities, business rules, interfaces, and acceptance conditions of the system. In a traditional project, this stage may produce a Software Requirements Specification, contractual requirements, traceability matrices, use cases, interface requirements, regulatory constraints, and formal approvals.
The underlying assumption is that a sufficiently complete statement of need can be created before substantial implementation begins. If the problem domain is stable and stakeholders know what they need, this can be a reasonable goal. But in innovative product development, users often discover what they truly need only after interacting with . The document can capture what people believe today while giving the organization the impression that tomorrow has already been decided.
2. Analysis
Analysis transforms raw needs into a more structured understanding of the problem. Teams examine processes, data, dependencies, business rules, risks, constraints, and system behavior. Analysts may model workflows, decompose functions, identify edge cases, and resolve ambiguities before technical design is authorized to proceed.
This work is valuable in every development approach. The risk appears when analysis is treated as a phase that can finish the problem rather than as an activity that must continue as evidence arrives. A domain can be modeled carefully and still surprise the team when real users, real data, and real integrations enter the picture.
3. Design
During design, the team decides how the system should satisfy the analyzed requirements. This may include architecture, database structures, modules, interfaces, security mechanisms, infrastructure, user-interface specifications, integration protocols, capacity assumptions, and detailed component designs.
Design-first discipline can prevent expensive improvisation. Architectural thinking, threat modeling, data modeling, and interface definition are often essential. The risk is not design itself; the risk is excessive commitment to untested design decisions. The farther implementation moves from the moment a design assumption was made, the more expensive it may become to reverse that assumption after reality disproves it.
4. Implementation
Implementation is the construction phase: translate approved designs into source code, configuration, database objects, scripts, integrations, and other executable components. In a strongly sequential project, implementation can begin after large portions of analysis and design are considered complete.
At this point, the project starts converting documents into running behavior. This is an important epistemic shift: a design can claim that components will integrate, while running software demonstrates whether they actually do. If months have passed since the original requirements were written, implementation may also reveal ambiguities that force questions back toward analysts and stakeholders. Every such question is evidence that knowledge did not flow only downward.
5. Testing
Testing verifies whether the implemented system behaves as expected and validates whether it satisfies intended needs. Depending on the process, this may include unit testing, integration testing, , performance testing, security testing, regression testing, and user acceptance testing.
In traditional , a major portion of formal testing happens after implementation. This creates one of the model's most important economic risks. The test team may be the first group to exercise the fully integrated system. Defects discovered here can originate in code, design, architecture, misunderstood requirements, incompatible interfaces, or unrealistic assumptions. Fixing the symptom may require reopening work that management already considered complete.
6. Deployment
Deployment moves the validated system into its operational environment. Activities can include packaging, environment configuration, data migration, training, operational readiness checks, cutover planning, production release, and handover to support teams.
When deployment occurs only after the full planned scope is complete, it becomes another late moment of truth. Production data volumes, network conditions, user behavior, operational procedures, security controls, and downstream integrations can expose issues that earlier environments did not reproduce. A large batch release also increases the number of simultaneous variables, making failures harder to isolate.
7. Maintenance
After release, the system enters maintenance. Teams correct defects, adapt the software to environmental changes, support users, improve performance, close security vulnerabilities, and add or modify capabilities. Traditional lifecycle diagrams sometimes make maintenance look like an afterthought, but in real systems it can represent the majority of the product's useful life and cost.
Maintenance also reveals a contradiction in the idea of finality. The moment real users adopt a system, they generate new information. Markets change, regulations evolve, integrations move, threats emerge, and users ask for improvements. Software is therefore rarely "finished" in the same sense as a physical object leaving an assembly line. Release begins a new learning cycle, whether the project model acknowledges that fact or not.
Why Can Be Valuable in the Right Context
Criticizing without discussing its strengths produces poor engineering judgment. can be effective when uncertainty is genuinely low, requirements are stable, changes are rare or tightly controlled, the cost of late modification is understood, and compliance or contractual obligations require extensive documentation and formal approval gates. In those environments, the discipline of defining interfaces, documenting decisions, reviewing hazards, and establishing traceability can be highly valuable.
can also be attractive when the work contains hard external dependencies that cannot be changed incrementally. Hardware manufacturing, certification programs, infrastructure procurement, embedded systems tied to physical components, or regulated deployments may contain moments where a decision becomes expensive or impossible to reverse. A lifecycle can help synchronize those commitments. Even then, however, the software portions of the work can often benefit from prototypes, simulations, early integration, automated tests, and incremental validation inside the broader governance structure.
Another advantage is communicative simplicity. Phase models give executives, vendors, and auditors a clear vocabulary for deliverables and decision points. A requirements baseline, architecture review, test readiness review, and production approval can make accountability visible. For fixed-price procurement, formal phase outputs can also support contract management. The danger is assuming that governance evidence and product evidence are the same thing. A signed specification proves that people agreed on a document. It does not prove that users will find the software useful.
Finally, can reduce coordination cost when specialist work is truly separable and stable. If a team can confidently finish one kind of work and hand an unambiguous result to the next specialty, specialization can be efficient. The problem is that software frequently violates this assumption: implementation teaches designers, testing teaches implementers, and user feedback teaches everyone. When those learning channels are slow, specialization becomes a queue of delayed discoveries.
The Central Limitation: Change Arrives After Commitment
becomes fragile when requirements, user expectations, technical knowledge, or business conditions change materially during the project. The reason is structural. Early phases create commitments that later phases depend on. A changed requirement may therefore invalidate analysis, design, implementation, test cases, documentation, training materials, contracts, and deployment plans. The cost of change is not merely the cost of editing a sentence; it includes the cost of propagating new knowledge through every downstream decision derived from the old assumption.
This phenomenon can be described as change amplification. Imagine that a team misinterprets a payment rule during requirements analysis. If the misunderstanding is corrected during a workshop the same day, the cost may be minutes. If it survives into architecture, database design, API contracts, implementation, automated test data, user manuals, and regulatory documentation, the same conceptual error can require changes across many artifacts and teams. The defect has not become more intellectually difficult; the organization has built more commitments on top of it.
governance can make this worse when change is framed primarily as a failure of discipline. Teams may discourage stakeholder changes because they threaten the baseline, even when the new information makes the original plan valuable. This creates a dangerous incentive: protecting the plan can become more important than protecting the product outcome. The project may become excellent at delivering what was requested months ago while the business has moved on.
None of this means scope should change chaotically. approaches do not eliminate planning or commitment. They shorten the horizon over which detailed commitments are made and create regular opportunities to reorder work based on evidence. The contrast is therefore not planning versus no planning. It is long-horizon versus that is repeatedly revised as learning occurs.
Why Late Error Discovery Is So Expensive
The phrase "cost of discovering errors late" refers to more than defect-fixing effort. Late discovery consumes schedule contingency, forces coordination across specialties, creates rework, disrupts other planned activities, and can reduce the team's freedom to choose a clean solution. When a problem is found near a major release date, the organization may accept , reduce test coverage, defer improvements, or implement a workaround simply because there is no longer enough time for a better correction.
Late integration is especially risky because individually correct components can fail when combined. Data formats can differ. Performance assumptions can collapse under realistic load. Authentication flows can conflict. Error handling can be inconsistent. Two teams can each satisfy their local specification while still producing an unusable end-to-end experience. If integration is scheduled near the end, the project learns about these system-level truths when the remaining schedule is shortest.
creates a similar problem. Testing is not just a quality-control step that inspects finished output; it is a source of information about the product and the development system. A failing test can expose a requirement ambiguity, a design flaw, a risky dependency, or a misunderstanding of user behavior. Delaying tests delays knowledge. The same principle applies to security reviews, performance experiments, usability studies, and production-like deployments.
This is why modern engineering practices emphasize shifting feedback left and making it continuous where possible. Automated tests, , feature flags, observability, prototypes, user research, and incremental release strategies all reduce the distance between an action and the evidence that tells us whether the action was useful. The economic objective is not simply "go faster." It is to avoid investing large amounts of work before discovering that an assumption was wrong.
The Problem of : Building the Wrong Thing Correctly
Verification and validation answer different questions. Verification asks whether the system was built according to its specified requirements and design. Validation asks whether the resulting system actually addresses the user's or customer's real need. A project can pass verification and still fail validation. Every requirement in the document can be implemented correctly while the product remains confusing, inconvenient, obsolete, or commercially irrelevant.
is therefore one of the deepest risks in a sequential project. If users see realistic only near the end, their first high-quality feedback arrives after most of the budget has been spent. At that point, "we misunderstood the problem" is far more expensive than a conventional coding defect. It may imply that the feature set, workflow, architecture, or entire product proposition needs to change.
Documents and mockups can reduce this risk but cannot remove it completely. People reason differently when they use a working system. Real software exposes response time, navigation friction, error messages, edge cases, interactions between features, and consequences that are difficult to imagine from specifications alone. In complex domains, use is part of discovery.
attacks this risk by creating usable slices earlier. Each slice is an opportunity to compare assumptions with evidence. That is why short feedback cycles are not merely a productivity technique. They are a risk-management mechanism. A team that learns every two weeks can correct direction before a team that learns every six months even knows it is wrong.
Predictability, Uncertainty, and Why Software Is Not an Assembly Line
is most comfortable when the work is predictable: the desired output is known, the method is understood, variation is limited, and execution is the main challenge. Manufacturing often contains processes with these characteristics. Once a product and production system have been engineered, the organization can repeat a known transformation with statistical control, standardized work, and carefully optimized variation.
Software product development is often different because the team is not repeatedly manufacturing an identical known object. It is discovering and encoding new behavior. Requirements contain assumptions about users and markets. Architecture contains assumptions about scale and change. Estimates contain assumptions about hidden work. Integrations contain assumptions about external systems. Even a familiar technology stack can produce novel interactions when combined with a new business context.
The cost structure is also different. Producing another copy of deployed software is usually extremely cheap compared with producing another physical unit, while designing and evolving the software is knowledge-intensive. This means the central economic challenge is often not repetition but discovery: what should we build, what design will survive change, what risks are hidden, and what evidence tells us that the product is valuable?
This distinction explains why industrial metaphors can mislead. A programmer is not equivalent to a factory worker assembling a predefined unit from a complete blueprint. When code, they make design decisions, discover constraints, expose inconsistencies, and create new knowledge. Testing is not simply an inspection station at the end of a production line; it can influence design and requirements. Users are not merely consumers of a finished specification; their interaction can redefine the problem itself.
's empirical foundation makes sense in this context. assumes that knowledge comes from experience and that decisions should be based on what is observed. Transparency makes the relevant state visible, inspection evaluates it, and adaptation changes direction when the evidence demands it. That cycle is particularly suited to complex work where complete predictability is unrealistic.
vs.
The clearest way to compare and is to examine how they create feedback. In a sequential plan, a broad scope moves through one type of activity at a time. In an iterative approach, a narrower slice moves through many activities and becomes usable earlier. Both approaches analyze, design, implement, and test. The difference is the size of the batch and the timing of learning.
A large batch can appear efficient because specialists focus on one activity and hand off a comprehensive result. But large batches increase the amount of work whose assumptions remain unvalidated. If the project discovers a wrong assumption at the end, a large amount of downstream work may depend on it. A exposes the assumption sooner and limits the amount of work that must be reconsidered.
Iterative does not automatically mean . A team can divide a fixed annual plan into ten iterations and still refuse to change scope or priorities when evidence changes. adds an adaptive mindset: plans are useful, but they are revised as the team learns what creates value. operationalizes this through short Sprints, a , a , inspection events, and an ordered that can evolve.
and at a Glance
Dimension
Sequential / tendency
Iterative tendency
Primary decomposition
Large scope divided by activity or phase
Scope divided into smaller functional slices
Planning style
Detailed early
Progressive and
Feedback timing
Often concentrated at phase transitions and
Frequent feedback from integrated
Change handling
Change managed against established baselines
Change expected and incorporated between iterations
Practical Example: A Digital Banking Onboarding Project
Imagine a bank wants to replace its customer onboarding journey. The original business request is straightforward: allow a new customer to open an account digitally, upload identification, pass compliance checks, create credentials, and receive confirmation. Management approves a nine-month budget and wants a firm launch date.
In a strongly sequential approach, analysts may spend two months documenting hundreds of requirements. Architects and designers then spend another two months defining the target process, data model, APIs, security controls, and user interface. spend three months implementing the complete journey. Integration and begin in month eight. Formal user acceptance and production preparation happen near the end.
Suppose the first realistic end-to-end test reveals three surprises. The identity provider behaves differently under peak load; customers abandon the process because document capture is confusing; and a new compliance interpretation requires additional consent before a particular data exchange. None of these discoveries is merely a coding bug. One affects architecture and capacity assumptions, one affects the product workflow, and one affects requirements and audit evidence. Because the discoveries arrive after most phases were declared complete, each problem propagates backward through many artifacts and teams.
Now consider an iterative strategy. The team still performs serious analysis, architecture, security, and compliance work, but it deliberately builds a thin end-to-end path early. In the first iterations, a limited internal or pilot flow can create an account using representative identity verification and production-like integrations. Subsequent iterations improve document capture, error handling, compliance rules, and edge cases. Stakeholders inspect usable behavior every few weeks rather than reading only intermediate documents.
The iterative team may still encounter the same three problems. The difference is timing. Load behavior can be measured before the architecture is deeply committed. Usability problems can be observed before every screen is built. Compliance changes can be incorporated while the backlog and design are still evolving. The objective is not to eliminate uncertainty; it is to make uncertainty visible while the cost of adaptation is still manageable.
For preparation, this scenario reveals the connection to . A creates a short horizon. The works toward a and creates a that meets the . The enables inspection of the outcome and discussion of what to do next. The can adapt as the environment changes. does not promise that the initial plan will be correct. It creates a structure in which being wrong can become useful information quickly.
Exam lens
When a scenario presents uncertainty, changing needs, or newly discovered information, avoid assuming that protecting an old plan is automatically the professional response. uses : make the current state transparent, inspect evidence, and adapt while preserving the relevant and accountabilities.
Essential Vocabulary
Phase gate
A formal decision point that determines whether work can move to the next lifecycle phase.
Baseline
An approved version of scope, requirements, schedule, design, or another artifact used as a reference for controlling change.
Planning that attempts to determine a substantial portion of future scope and execution details in advance.
Planning that is revised frequently as new evidence and learning become available.
Verification
Checking whether the system conforms to specified requirements or design expectations.
Validation
Checking whether the system actually solves the intended user or business problem.
A cycle in which the results of an action are observed and used to influence subsequent decisions.
The amount of work moved through a process before feedback or completion; smaller batches generally reduce the amount of unvalidated work.
Conclusion: Is a Model of Assumptions
organizes software development as a sequence of phases: requirements, analysis, design, implementation, testing, deployment, and maintenance. Its historical influence came from a legitimate need to make large technical projects more structured, documentable, governable, and predictable. The model can still offer value when requirements are stable, external constraints are strong, formal traceability matters, and major decisions truly can be made with high confidence before implementation.
Its limitations emerge when the project contains significant uncertainty. Requirements change, users learn, technologies behave unexpectedly, integrations reveal hidden constraints, and markets evolve. In a large sequential batch, this knowledge often arrives after many downstream decisions have already been made. The later an important misconception is discovered, the more work it can invalidate. creates an even more dangerous failure: the organization can build the specified system correctly and only then discover that it solved the wrong problem.
The strongest lesson is not that planning is bad. Good software development requires planning. The lesson is that the appropriate planning horizon depends on uncertainty. When the environment is predictable, detailed plans can be highly useful. When the work is complex, plans must coexist with frequent empirical feedback. shortens the distance between assumption and evidence; approaches make adaptation a normal part of management rather than an exception to the plan.
For a future , this distinction is foundational. is not valuable because meetings happen every two weeks. It is valuable because the framework creates repeated opportunities to expose reality before too much work depends on an untested belief. Once you understand through that lens, the purpose of Sprints, Increments, inspection, adaptation, and becomes much more intuitive.
Key Takeaways
is a sequential, way of organizing work by lifecycle activity.
The model is commonly associated with Winston Royce's 1970 paper, but the historical reality is more nuanced than the popular one-way diagram.
The seven common phases are requirements, analysis, design, implementation, testing, deployment, and maintenance.
can be effective when requirements and constraints are stable, traceability is important, and major decisions can be made with high confidence.
Changing requirements become costly when many downstream artifacts and decisions depend on an early baseline.
and integration delay technical feedback; delays learning about whether the product is actually valuable.
Software development often involves discovery and uncertainty, which makes it different from repeatable industrial production.
reduces and creates earlier feedback; adds in response to that feedback.
addresses complex work through rather than by assuming the original plan can fully predict the future.
Schwaber, K. and Sutherland, J. - The Scrum Guide (November 2020). - Official definition of and its empirical foundation of transparency, inspection, and adaptation.
Study note: terminology and exact lifecycle phases vary across organizations and sources. For , the important connection is conceptual: is designed for complex work where frequent inspection and adaptation are more reliable than assuming a complete predictive plan will remain valid.
