The 7 Phases of SDLC Explained Clearly

Most guides list the SDLC phases as planning, requirements analysis, design, development, testing, deployment and maintenance. Each one finishes with a named deliverable. Planning gives you a project plan, requirements analysis gives you a software requirements specification, and deployment gives you a release build. The software development life cycle (SDLC) is simply the name for that ordered sequence.

Different people own different phases. Project managers run planning, business analysts handle requirements, and software architects do the design. Developers write the code, QA engineers test it, and DevOps engineers push it out. Whatever one phase produces becomes the input for the next.

Seven is a convention, though, not a standard. ISO/IEC/IEEE 12207:2026, published in April 2026, defines software life cycle processes and states that it does not require any specific life cycle model (ISO, 2026).

What Are the 7 Phases of SDLC?

In order, the phases run like this.

1. Planning decides whether the project is worth building, and with what budget and team.
2. Requirements analysis records what the software must do.
3. Design defines how it will be built, covering architecture, data and interface.
4. Development is where the code gets written.
5. Testing checks the build against the requirements.
6. Deployment releases it to users.
7. Maintenance covers fixes, patches and updates after release.

Seen from the wider software development process, every phase answers one question and passes its output along.

Real projects overlap these phases all the time. Design often starts before requirements fully close, and testing runs beside development instead of waiting for it to finish.

The exit criterion column matters most, because it is the gate between phases. Saylor Academy course material says every phase needs entry and exit criteria, since progress is hard to track without them.

Where the 5, 6, 7 and 8 Phase Counts Come From

Nobody sets the number. Teams merge, split or rename steps until the list fits their model.

The April 2026 edition of ISO/IEC/IEEE 12207 replaces the 2017 text (ISO, 2026). It covers processes, activities and tasks across the full software life cycle, and it states that it does not prescribe any specific life cycle model or methodology (ISO, 2026).

So seven phases is a habit more than a rule. Saylor Academy course material puts the range at five to nine phases, averaging seven or eight.

• Charter Global’s 2025 guide gets to five phases by merging planning and analysis and folding deployment into maintenance.
• Hong Kong’s Digital Policy Office (formerly the OGCIO) runs five development phases (project request, feasibility study, systems analysis and design, implementation and post-implementation review), then treats system maintenance as a sixth phase in its own cycle.
• McGraw-Hill’s systems development appendix uses the seven-phase grouping of planning, analysis, design, development, testing, implementation and maintenance.
• Saylor Academy lands on eight. It splits initiation and planning from feasibility, then adds analysis, design, coding, testing, implementation and maintenance.

The labels differ more than the work does. The same activities show up in every list, and most of the argument is about where one phase ends and the next begins.

What changes the outcome is how a lifecycle model orders and repeats those phases. The number of boxes in the diagram hardly matters.

This article sticks with seven. It is the most common grouping across current guides, and it keeps requirements analysis and design as separate deliverables.

Planning, Requirements Analysis and Design Phases in Detail

None of these phases produces code. They settle what gets built and how, and the later phases inherit every decision made here.

Planning phase

Planning produces a project plan, a budget and an agreed scope. The project manager leads it, and it closes when sponsors approve the plan and the budget.

Scope comes first, meaning what the release includes and what it leaves out. Estimates for cost and schedule follow (effort per feature, team size, milestones), and each technical, staffing or vendor risk gets a named owner.

A short feasibility study usually opens the phase. It tests whether the idea is technically and financially viable before anyone commits money.

Scope is where projects slip first. PMI’s 2018 Pulse of the Profession found that 52% of projects had scope creep or uncontrolled changes, up from 43% five years earlier.

Requirements analysis phase

Here the stakeholders’ needs get turned into a written specification that developers and testers can actually work from.

The business analyst runs interviews and workshops, then records the result in a software requirements specification (SRS). The phase closes when stakeholders sign off on that document.

ISO/IEC/IEEE 29148:2018, published in November 2018, is the requirements engineering standard behind most SRS templates. It defines the content of four documents, namely the business, stakeholder, system and software requirements specifications.

Requirements and later change requests usually live in Jira or a comparable tracker, so every change has an owner and a date.

Weak requirements are the expensive failure. PMI’s 2014 requirements management study put the waste at 5.1% of every project dollar, or US$51 million per US$1 billion spent.

The FBI’s Virtual Case File shows how this plays out. The project was terminated in 2005 after 3 years and $170 million, and the Justice Department’s inspector general listed poorly defined, slowly evolving design requirements among the causes.

Design phase

Design converts the SRS into a blueprint of how the system is structured, how data moves through it, and how users interact with it. The software architect owns the output, a design document, and a design review closes the phase.

The high-level part covers the system architecture and main components, technology choices and integrations, the data model and the deployment layout.

Low-level design gets more granular. Think module and class structure, the interfaces between modules, database schemas and the algorithms inside them.

UML diagrams describe structure and behavior. Figma prototypes let stakeholders react to the interface before anyone writes code, which saves a lot of awkward conversations later.

A structural mistake caught here costs a diagram edit. Caught in development, it costs rework across many files.

Development and Testing Phases in Detail

Development turns the design into working code, and testing checks that code against the requirements. On most teams the two run in parallel, with defects cycling back to developers until the exit criteria are met.

Development phase

Developers write code to the design document and the team’s coding standards.

Git holds the history and branches keep work in progress isolated. Every change merges through a pull request, and SonarQube or a similar static analyzer flags quality and security issues in each build. The phase ends when reviewed code is merged and the build passes.

A code review process is standard here, but it filters fewer defects than most teams assume. Bacchelli and Bird (ICSE, 2013) observed, interviewed, and surveyed developers and managers at Microsoft. Finding defects was the stated goal, yet the outcomes leaned toward knowledge transfer, team awareness and alternative solutions.

Treat review as a design and learning check. Keep testing as the defect gate.

Testing phase

Testing verifies the build against the SRS and sends defects back to development until the exit criteria are met.

Unit tests cover one function or class in isolation. Integration tests check modules working together, and regression tests confirm old behavior still works after a change. User acceptance testing comes last, when business users confirm the software does what they asked for.

Developers usually write unit tests as they code, which is why testing overlaps with the development phase.

The QA engineer owns the test plan and the test report. Selenium WebDriver automates the browser-level regression checks, and version 4.45.0 reached Maven Central on 16 June 2026.

The phase closes when the suite passes, open defects are resolved or formally accepted, and the customer signs off.

The usual failure is a compressed test cycle. Defects missed here reach production, where every fix costs more.

What Happens in the Deployment and Maintenance Phases?

Deployment puts the tested build into the production environment. Maintenance then keeps that release fixed, patched and current for as long as people depend on it.

Deployment phase

The DevOps engineer owns this phase, and it closes when the release is signed off live.

Rollouts are usually staged, going from alpha to beta to full release so the audience widens one step at a time. The release candidate is the frozen build that gets final checks, with release notes attached. On the packaging side, Docker images built by Jenkins get scheduled onto Kubernetes clusters.

Every release needs a tested rollback procedure, because deployment is the phase where one missed step goes live.

Knight Capital shows the cost. During a 2012 code deployment one server did not receive the new code and no second technician reviewed the work. In the first 45 minutes after the market opened, the faulty order router sent more than 4 million orders to fill 212 customer orders, and the firm ultimately lost more than $460 million, according to the SEC’s 2013 order.

The SEC found that Knight lacked adequate controls and procedures for code deployment and testing.

Maintenance phase

Maintenance has no exit criterion. Each bug report or change request kicks off a small cycle through the earlier phases.

Most of the work isn’t bug fixing at all. The IEEE Computer Society’s SWEBOK Guide reports that over 80% of maintenance effort goes to noncorrective changes.

ISO/IEC/IEEE 14764 splits maintenance into corrective, preventive, adaptive and perfective work, and groups these as corrections and enhancements. Corrective work repairs faults found after release. Preventive work removes latent faults before users hit them. Adaptive work keeps the software running as its environment changes, and perfective work covers enhancements and performance improvements.

Prometheus metrics and alerts feed the backlog, and the team ranks it through formal change request handling.

A plan for post-deployment maintenance needs its own budget. Preventive work is the first line to get cut, and it comes back later as technical debt.

How SDLC Models Arrange the 7 Phases

Models change the order and repetition of the phases, and the list itself stays put. Waterfall runs each phase once and the V-model pairs build and test levels. The spiral repeats phases by risk, agile loops them in short cycles, and DevOps extends the loop into operations.

Comparing the models

The table puts the five side by side.

Winston Royce’s 1970 paper is the usual source cited for the waterfall methodology. It draws seven sequential steps from system requirements to operation, then calls that single-pass form risky for large systems and adds feedback between the steps (Royce, IEEE WESCON, 1970).

Barry Boehm’s spiral model (IEEE Computer, May 1988) makes risk the driver of each cycle, ahead of documents or code.

Choosing a model

It mostly comes down to how stable the requirements are, how risky the work is, and how often you want to release.

• If requirements are fixed and a contract or regulator demands paperwork, waterfall fits, or the V-model when verification has to be traceable.
• If feasibility or technical risk is unknown, go spiral so the risky work comes first.
• If requirements will change and users are reachable, agile works well, with Scrum for timeboxed sprints or Kanban for continuous flow.
• If deployment is the bottleneck, add DevOps practices to whichever model you already run.

Agile organizes the work and DevOps extends it into deployment and operations. The difference between agile and DevOps is one of scope, so the two combine rather than compete.

Waterfall still fits when change is expensive and requirements are signed. Forcing it onto a product with shifting requirements is exactly the pattern Royce warned about.

How Does Security Fit Into the SDLC Phases?

Security has no phase of its own. It attaches to each one. Requirements capture security needs, design models threats, and development scans code. Testing probes the build, deployment hardens configuration, and maintenance handles vulnerability reports.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1 published in February 2022, starts from a gap. Few SDLC models cover security in detail, so its practices are added to whichever model a team runs.

As of 30 October 2026, SP 800-218 Rev. 1 (SSDF 1.2) is still an initial public draft, released on 17 December 2025, with public comments closed on 30 January 2026. NIST’s SSDF project page, updated on 6 October 2026, still presents version 1.1 as the final text, and it remains the final text until NIST publishes the revision.

OWASP unveiled the 2025 edition of its Top 10 in November 2025 and finalized it in January 2026, adding Software Supply Chain Failures and Mishandling of Exceptional Conditions as new categories.

DevSecOps moves these checks into the delivery pipeline so they run on every change. Dependency and static scans belong in continuous integration, where a failed scan blocks the merge.

A pipeline scanner doesn’t replace threat modeling. Insecure Design needs a decision at the design phase, and no later test can stand in for it.

Where SDLC Phases Fail and What Late Defects Cost

The same problems keep turning up across projects. Scope creeps, defects get found late, testing gets skipped, and nobody funds maintenance. Each one starts earlier than the phase where it finally becomes visible.

Failure modes by phase

• Ambiguous or unsigned specifications in the requirements phase turn into rework once code exists.
• A shortened test cycle moves defect discovery to your users.
• Maintenance with no preventive budget lets technical debt compound with every release.

The dollar figures behind this are large.

• $59.5 billion is the estimated annual US cost of inadequate software testing infrastructure (NIST Planning Report 02-3, RTI, 2002).
• $22.2 billion of that is the part feasible testing improvements could remove (same report).
• Accumulated US technical debt sits at $1.52 trillion (CISQ, 2022).

Late fixes cost more in most accounts. How much more is where the sources split.

Making Software (O’Reilly, 2010) summarizes 1970s studies from IBM, GTE, TRW and Bell Labs that put a post-delivery change near 100 times the cost of a requirements-phase change on large systems. Laurent Bossavit, in The Leprechauns of Software Engineering, argues the evidence behind the cost curve falls short of research standards, and one study he traced showed a 2:1 ratio in the opposite direction (Techwell, 2013).

The defensible reading is to treat 100:1 as an upper bound for requirements defects found after delivery on large systems. It isn’t a rule for every bug.

When a 7-phase structure does not fit

• Small internal programs, where Royce’s 1970 paper says analysis and coding alone are enough.
• Throwaway prototypes, since the requirements are the thing being discovered.
• Teams that deploy many times a day, where the phases blur into one continuous loop.

For a small internal tool, skip the full document set and keep three gates: scope agreed, tests passing, rollback ready.

ISO/IEC/IEEE 12207 allows this kind of flexibility. It states that its processes can be applied concurrently, iteratively and recursively.

SDLC Phases FAQ

What is the difference between SDLC and STLC?

The software testing life cycle (STLC) only covers testing, while SDLC runs the whole way from planning to maintenance. STLC typically moves through requirement analysis, test planning, test case development, environment setup, execution and closure.

It sits inside the SDLC testing phase and starts earlier, when testers review requirements.

Is the 7-phase SDLC required in regulated industries?

No. Regulators such as the FDA for medical devices expect a documented, controlled development process with traceable records.

The phase names and their count are your choice. Auditors check that requirements, design, verification and change control leave evidence.

How long does each SDLC phase take?

There’s no fixed duration. Scope, team size, risk and the chosen model set the length of each phase.

A waterfall project may spend months in requirements analysis alone. An agile team runs every phase inside a single sprint.

Is a phase the same as a stage in the SDLC?

In most SDLC sources the two words are interchangeable.

Project frameworks are the exception. PRINCE2 uses stage for a management period closed by a go or no-go decision, so check the glossary of the framework your team follows.

Which SDLC Phase Pays Back First?

Requirements analysis pays back first. A defect introduced there costs least to correct before design starts and most to correct after release.

NIST’s 2002 estimates imply an avoidable share of about 37%, since improved testing infrastructure could remove $22.2 billion of the $59.5 billion annual cost of software errors.

If you have to pick where the first effort goes, this order works:

• A signed software requirements specification
• An automated regression suite in the pipeline
• A rehearsed rollback

The order follows distance from where defects enter. Later phases can only detect them, not prevent them.

The trade-off is calendar time, because a longer requirements phase delays the first commit by weeks. Reorder the list after one release cycle, using the team’s own record of which phase introduced each defect and which phase caught it (position verified 30 October 2026).

Teams deciding how to run these phases can compare software development methodologies next.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• Best AI Customer Service Software for 2027 - October 31, 2026
• How to Install Pandas in VS Code (pip, venv and Conda) - October 30, 2026
• Top 10 UX and Branding Strategies for SaaS Startups in 2026 - October 30, 2026