The Seven Stages of the SDLC: What Each Produces and Where It Goes Wrong

By Sergey Nosov

16 October 2026

In August 1970, Winston Royce of TRW presented a paper with a diagram of seven steps, running from system requirements down to operations. The diagram would later be called the waterfall. Directly below it, Royce wrote: “I believe in this concept, but the implementation described above is risky and invites failure.” Most of the rest of the paper explains how to reduce that risk.

The stages of the software development life cycle (SDLC) have been renamed and rearranged many times since. Most software projects still pass through them, whether or not anyone says “SDLC” out loud. Naming them gives a team a shared vocabulary, so it can talk precisely about where a problem lives instead of who it lives with.

Each stage produces an artifact; if there is no artifact, the stage probably did not happen. Most production failures I have seen trace back to a stage that was skipped, rushed, or both. Knowing the map is how you notice you are off it.

This article walks through the seven stages: what happens in each, what it produces, and where it most often goes wrong. Along the way, it checks two pieces of life-cycle folklore against their sources: what Royce actually recommended, and whether a late fix really costs ten times more per stage.

Seven Stages, One Map

One common list has seven stages:

  1. Planning: why build it, and with what.
  2. Requirements analysis: what it must do, and how well.
  3. Design: a buildable shape that meets those requirements.
  4. Implementation: the code, written against the design.
  5. Testing: evidence that the code does what was asked.
  6. Deployment: turning the code into a running service.
  7. Maintenance: everything after that, until retirement.

The number is a convention. Royce’s diagram also had seven steps, but not these seven: system requirements, software requirements, analysis, program design, coding, testing, and operations. NIST’s Secure Software Development Framework (SSDF) defines an SDLC loosely enough to cover them all: “a formal or informal methodology for designing, creating, and maintaining software.”

The order is conceptual, not strict. In a strict waterfall, the stages run once, from top to bottom. In iterative and agile methods, a team revisits earlier stages every sprint, sometimes every day. The cadence changes; the activities do not.

The strict version is not what Royce proposed. One of his captions hoped that iteration would stay between neighboring steps; the next conceded that “for the process illustrated, the design iterations are never confined to the successive steps.” In that process, testing comes at the end of development, and it is the first time that timing and storage are experienced rather than analyzed. When they fall short, he warned, a major redesign follows, and “one can expect up to a 100-percent overrun in schedule and/or costs.”

He added five steps: do a preliminary program design before the analysis; document the design; “do it twice”; plan, control, and monitor the testing; and involve the customer formally before delivery. Step 3 comes closest to iteration: a pilot, “the entire process done in miniature.” The version delivered is then “actually the second version insofar as critical design/operations areas are concerned.”

The paper never uses the word “waterfall.” In 1976, T. E. Bell and T. A. Thayer, also of TRW, credited Royce with introducing “the concept of the ‘waterfall’ of development activities.” In a 2003 history of iterative development, Craig Larman and Victor Basili write that many “incorrectly” view Royce’s paper “as the paragon of single-pass waterfall.” They find “hints of iterative development” in the paper.

The single pass took hold anyway. By the late 1980s, Larman and Basili write, the US Department of Defense was “experiencing significant failure in acquiring software.” Its standard, DoD-Std-2167, required the “strict, document-driven, single-pass waterfall model.” The standard’s principal creator later “expressed regret for creating the strict waterfall-based standard.”

None of this makes the stages wrong; Royce called the approach “fundamentally sound.” What fails is a single pass that tests its assumptions only at the end. How much analysis to do up front depends on the problem, and my article on complicated versus complex problems covers how to tell which kind you face.

Stage 1: Planning

Planning gives the project its shape. It covers the idea and the business case, an honest look at feasibility, the scope, and the high-level objectives. It estimates the resources (people, time, budget, and tooling) and takes a first pass at the risks and at aligning the stakeholders.

What it produces: a project charter, a feasibility report, and a rough schedule.

Where it goes wrong:

Stage 2: Requirements Analysis

This is where the team works out what the system actually has to do. It interviews stakeholders and studies users. It writes down functional requirements, which say what the system does, and non-functional requirements, which say how well it must do it: its performance, availability, security, and compliance. It ends with acceptance criteria and the metrics that will show whether the result is right.

What it produces: a requirements specification, user stories, and acceptance criteria.

Where it goes wrong:

A requirement is precise enough when a test could fail it. Here is a vague requirement and a testable rewrite; the numbers are only an example:

Vague:
  Search must be fast.

Testable:
  95 percent of searches
  return within 2 seconds
  while 200 users search
  at the same time.

Ambiguity, contradiction, and the silent gap survive a casual read-through of a requirements document. Finding them is the subject of my book Finding What Requirements Hide.

Stage 3: Design

Design turns requirements into a buildable shape: the system and component architecture, the data model, the interfaces, and the contracts between services. Security design belongs here too: authentication, authorization, threat modeling, and data classification. So do the user-experience flows and the boundaries where the system meets other systems. My article on threat modeling with STRIDE works through the security part of this stage on one small API.

What it produces: architecture diagrams, schemas, API contracts, and design documents that someone other than the author can actually read.

Where it goes wrong:

Stage 4: Implementation

This is the stage most engineers think of as the work: writing code against the design. It includes source control, a branching strategy, code review, continuous integration, build automation, and the developer-level tests written as the code is written, not after. My article on the anatomy of a good code review covers the review.

What it produces: source code, builds, packaged artifacts, and unit tests.

Where it goes wrong:

Stage 5: Testing

Testing checks that what was built matches what was asked for. It spans unit, integration, system, and acceptance tests; performance, load, and resilience tests; and security tests. Those include static analysis of the source code (SAST), dynamic testing of the running application (DAST), scans of dependencies for known vulnerabilities, and, where the risk justifies them, penetration tests.

Underneath all of it sits validation against the requirements from stage 2. A test that cannot be traced back to a requirement is worth a question, and so is a requirement that no test checks. My article on unit, integration, and end-to-end tests covers where each kind of test belongs.

What it produces: test reports, defect logs, coverage data, and sign-off.

Where it goes wrong:

Stage 6: Deployment

Deployment turns code into a running service. It covers release planning and change management, provisioning and configuring the environments, and automating the rollout. Blue-green deployment switches traffic between two production environments. A canary release gives the new version to a small share of users or servers first. A rolling update replaces instances a few at a time. The Execution and Delivery volume of my Software Development Principles series covers all three strategies. Every rollout needs verification, such as smoke tests, and a rollback plan.

What it produces: the deployed application, release notes, and the runbooks that the on-call engineer will actually need at two in the morning.

Where it goes wrong:

A rollback is a deployment too, and it can fail like one. In 2012, a deployment that missed one of eight servers helped cost Knight Capital $460 million. Rolling back made things worse, because the old version still carried the code that was doing the damage. My article on deleting dead code tells the story.

Blue-green deployment makes rollback look like a switch; in Martin Fowler’s description, “if anything goes wrong you switch the router back to your blue environment.” He notes a catch: “the issue of dealing with missed transactions while the green environment was live,” meaning work that blue never saw.

Schema changes need care too: Fowler advises deploying them first, in a form that supports both versions of the application, “so you have a rollback point.” Parallel change, a pattern Danilo Sato describes, does this in three phases: “expand, migrate, and contract.” The old schema keeps working until all the code that uses it has moved to the new one.

Not everyone accepts the Friday rule. In 2019, Charity Majors countered with a claim she called “hyperbolic and indefensible”: put all developer time into CI/CD and observability until Friday deploys stop being scary. She also called it “probably a terrible idea” and asked for “some real engineering hours” on the deploy pipeline. Yet she drew her own line: “Don’t ship before you walk out the door on any day. Don’t ship big, gnarly features right before the weekend, if you aren’t going to be around to watch them.”

Stage 7: Maintenance

Maintenance runs the longest and gets the least attention. It covers monitoring, alerting, and on-call response; bug fixes, security patches, and dependency updates; performance tuning and capacity planning; and enhancements, deprecations, and eventually retirement.

Most of that work is not repair. The IEEE Computer Society’s SWEBOK Guide summarizes the software engineering body of knowledge. According to the guide, studies and surveys over the years indicate that more than 80 percent of maintenance goes to enhancing and adapting software. Version 4.0, approved in 2024, lists five standardized categories:

What it produces: patched releases, postmortems, updated runbooks, and retirement plans.

Where it goes wrong:

The 2017 breach at Equifax shows how ordinary the failures can be. The US Government Accountability Office recorded Equifax’s own account in a 2018 report. In March 2017, the US Computer Emergency Readiness Team issued a notice about a vulnerability in the Apache Struts web framework that let attackers run commands on affected systems. Equifax circulated the notice among its system administrators. But “the recipient list for the notice was out-of-date,” so it never reached the people responsible for patching the company’s online dispute portal.

A scan a week after the notice missed the vulnerability. Beginning on 13 May 2017, attackers used the portal to reach databases of personal information. They went undetected for about two and a half months, partly because a device that inspected network traffic for malicious activity had an expired digital certificate. The certificate “had expired about 10 months before the breach occurred,” so encrypted traffic went uninspected.

Equifax named other factors as well, among them unsegmented databases and unencrypted credentials; the attackers used the credentials to reach forty-eight more databases. In all, they accessed personal information of at least 145.5 million people. The stale recipient list, the missed patch, and the expired certificate were all maintenance left undone.

Does a Late Fix Cost Ten Times More?

A number travels with the life cycle: the cost of fixing a defect grows about tenfold for every stage it survives. The direction is right often enough to guide practice, but the sources do not support a fixed factor. A widely cited version of the claim is more careful than its retellings.

In 2001, Boehm and Basili put it first on their “Software Defect Reduction Top 10 List.” Item one reads: “Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.” They added the word “often” on purpose. For “small, noncritical software systems,” they wrote, the factor is “more like 5:1 than 100:1.” They also wrote that “good architectural practices can significantly reduce the cost-escalation factor even for large critical systems.”

In 2016, Tim Menzies, William Nichols, Forrest Shull, and Lucas Layman went looking for the evidence. They traced the familiar curve to Boehm’s 1981 book Software Engineering Economics and its data from large systems of the late 1970s at IBM, TRW, GTE, and Bell Labs. They also found that the data behind many such claims could no longer be examined.

So they tested the claim, which they call the delayed issue effect, on 171 projects run between 2006 and 2014. Their verdict: “We found no evidence for the delayed issue effect.” The effort to resolve an issue in a later phase “was not consistently or substantially greater than when issues were resolved soon after their introduction.”

Two limits apply. All the projects used one disciplined process, the Team Software Process, and most were small to medium; the median project lasted about two months. The authors do not claim their findings hold beyond that process. And the data do “not extend into post-delivery deployment,” so the study cannot test Boehm and Basili’s after-delivery figure. The authors answer that earlier studies saw the effect grow sharply even before delivery, and their own data show nothing like it.

They conclude that “a long-held truth in software engineering should not be considered a global truism.” Keep the advice to catch problems early, and drop the constant. A requirements ambiguity caught in a conversation costs a conversation. Found in production, the same ambiguity can cost an incident, a data repair, and the trust of the users who hit it. The size of that gap depends on the system, its architecture, and its process; no single multiplier holds everywhere.

For security, the SSDF gives the advice without a number. In its words, “in general, the earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security.” NIST calls this principle shifting left.

Security and Reliability in Every Stage

Security is not a stage. The SSDF, published as NIST SP 800-218, starts from that premise: whatever life-cycle model a team uses, secure development practices “should be integrated throughout it.” Several of its practices line up with the stages above:

As of October 2026, version 1.1 is still the current SSDF; NIST published a draft of version 1.2 in December 2025.

Reliability follows the same pattern. Availability targets are non-functional requirements. Resilience is a design decision. Load and resilience tests belong to testing, canary releases and rollbacks to deployment, and monitoring and capacity planning to maintenance. Neither security nor reliability belongs to testing alone.

A Checklist for Any Methodology

The SDLC is the same set of activities under any methodology, whether a team calls its process waterfall, agile, DevOps, or something else; only the cadence changes. Under any of those names, each stage leaves an artifact. Writing about design in 1970, Royce put it more strongly:

If the documentation does not yet exist there is as yet no design, only people thinking and talking about the design which is of some value, but not much.

Royce wanted “quite a lot” of documentation. The artifact need not be that long; the Agile Manifesto values “working software over comprehensive documentation.” A one-page charter, a list of acceptance criteria, a reviewed pull request, or a runbook with a rehearsed rollback can each serve. A stage that left nothing behind cannot.

Before calling a stage done, ask its questions:

Good engineers move fluidly between stages; great teams know which stage they are in and act like it. Knowing the stage you are in is half of working effectively. The other half is naming it out loud.

Further Reading