The Phases of the System Development Life Cycle, Explained

Search for the phases of the SDLC and you will find a lot of diagrams with arrows, and very little explanation of why any of it matters to the business paying for the work.

The system development life cycle is the sequence of stages a system passes through, from the first conversation about whether to build it at all, to the day it is switched off.

This guide explains each phase in plain terms, what you should have in your hands when a phase ends, and how the phases shift depending on whether your team works in waterfall, agile, or something in between.

What is the system development life cycle?

The SDLC is a framework for describing and controlling everything that happens to a system across its life. It covers planning, building, running, and eventually retiring it.

The abbreviation is used for both “system development life cycle” and “software development life cycle”. NIST notes that both uses are widespread and treats them interchangeably in its own guidance (NIST SP 800-218). In practice, “system” tends to include the hardware, integrations, and people around the software.

The international standard for this is ISO/IEC/IEEE 12207:2017, which sets out software life cycle processes and groups them into four categories: agreement, organisational project-enabling, technical management, and technical processes. One detail in the standard is worth knowing before you look at any phase diagram. Its processes are not tied to a fixed stage. Planning, performance, and evaluation are meant to be considered at every stage, not ticked off once and forgotten.

That is also why the number of phases varies between sources. Some describe five, some six, some seven. The activities are the same. Only the boundaries move.

A running example

To keep this concrete, picture a plumbing firm with 40 engineers who still fill in paper job sheets. They want an app so engineers can log jobs, parts, and photos on site. That project appears at each phase below.

The 7 phases of the SDLC

1. Planning and feasibility

This phase answers one question: should this be built at all?

The work involves defining the problem, estimating cost and timescale, identifying constraints, and deciding whether the return justifies the spend. It is also where you decide whether to build, buy, or configure something off the shelf.

For the plumbing firm, feasibility might reveal that three field service products already do 90% of what they need for £12 per user per month. That is a good outcome.

The UK government’s Service Manual calls this stage discovery and suggests four to eight weeks is typical for a service of reasonable size (GOV.UK Service Manual).

What you should have at the end: a clear problem statement, a rough budget, known constraints, and a documented decision to proceed or stop.

2. Requirements analysis

Here you turn “we need an app” into something a developer can actually build.

Requirements split into two types. Functional requirements describe what the system does, such as “an engineer can attach photos to a job”. Non-functional requirements describe how well it does it, covering performance, availability, accessibility, and security.

Non-functional requirements are the ones people forget, and they are usually the expensive ones to retrofit. “The app must work with no signal in a basement” changes your entire architecture. Finding that out during user research costs a conversation. Finding it out after launch costs a rebuild.

What you should have at the end: agreed, testable requirements. If a requirement cannot be tested, it is a preference, not a requirement.

3. System and software design

Design translates requirements into a technical plan: architecture, data model, integrations, interfaces, and the technology choices behind them.

This is also the point where security and data protection stop being optional extras. Article 25 of the UK GDPR requires data protection by design and by default, which means considering privacy at the point you decide how processing will work, not after the fact (ICO guidance). The ICO updated this guidance in 2026 to reflect the Data Use and Access Act, including a new duty covering services likely to be accessed by children.

For the plumbing firm, design decisions include where job photos are stored, how long they are kept, and whether engineers’ location data is collected at all. Collecting less is usually cheaper and always easier to justify.

What you should have at the end: an architecture your team can build from and a data protection position you can defend.

4. Development

This is the phase everyone pictures when they think about software, and it is rarely the longest one.

Developers write and review code against the design. Good practice here is well documented.

Version control, code review, and small regular commits belong here. So does dependency management. If you do not know which open source components are in your product, you cannot patch them when the next serious vulnerability lands.

What you should have at the end: working software in a repository, reviewed by someone other than its author.

5. Testing and quality assurance

Testing checks that the system does what the requirements said, and that it does not do anything alarming besides.

A full test approach usually covers unit tests, integration tests, user acceptance testing, performance testing, and security testing. Automated tests carry the routine checks. Humans handle the judgement calls.

Reviews matter as much as test execution. In his survey of software engineering research, Robert Glass reported that rigorous inspections can remove up to 90% of errors before the first test case runs (Facts and Fallacies of Software Engineering, 2002). The study is old, but the principle has held up.

The cost of getting this wrong is measurable at national scale. The Consortium for Information and Software Quality estimated the cost of poor software quality in the US at a minimum of $2.41 trillion in 2022, with roughly $1.52 trillion of that being accumulated technical debt (CISQ, 2022).

What you should have at the end: evidence, not assurances. Test results, a known list of open defects, and a documented decision to accept them.

6. Deployment

Deployment moves the system into the hands of real users.

Approaches vary from a single release to phased rollouts, pilot groups, and blue-green deployments where two identical environments swap over. Phased release is the safer default, because it limits how many people are affected if something breaks.

The pipeline that performs the deployment deserves the same scrutiny as the code. The NCSC recommends securing the build and deployment pipeline itself, since anyone who can alter your pipeline can alter what reaches production (NCSC).

Deployment also covers the unglamorous parts: data migration, training, documentation, and a tested rollback plan. The plumbing firm needs 40 engineers who know how to use the app on Monday morning, not just an app that works.

What you should have at the end: the system in production, users who can use it, and a way back if it goes wrong.

7. Operation, maintenance, and retirement

This is the longest phase and the one that gets budgeted last.

Maintenance covers bug fixes, security patching, performance monitoring, and enhancements. Glass put maintenance at 40% to 80% of total software costs, averaging around 60%, and argued it is probably the most important phase of the life cycle. Roughly 60% of that maintenance spend goes on enhancements rather than fixing faults, which tells you something useful: maintenance is mostly the system continuing to earn its keep, not the system falling apart.

Regulation is starting to reinforce this. Under the EU Cyber Resilience Act, manufacturers of products with digital elements sold on the EU market must report actively exploited vulnerabilities and severe incidents from 11 September 2026, with an early warning inside 24 hours and a fuller notification within 72 hours. The remaining obligations apply from 11 December 2027 (European Commission). UK companies selling software into the EU are in scope.

Retirement is the final act, and ISO/IEC/IEEE 12207 treats disposal as a process in its own right. It covers data export, archiving, secure deletion, and switching off the infrastructure. Systems that are quietly abandoned rather than properly retired become the unpatched server nobody remembers owning.

What you should have at the end: a supported system with a known owner, a patching routine, and an agreed plan for its eventual replacement.

SDLC models: how the phases are arranged

The phases are constant. The order and the overlap are not.

Waterfall

Each phase finishes before the next begins. It suits projects where requirements are genuinely fixed and change is expensive, such as regulated hardware or safety-critical systems.

The weakness is obvious in hindsight: you find out whether users like the system at the end, when changing it costs the most.

Iterative and agile

Agile approaches run the phases in short cycles, delivering working software repeatedly and adjusting as you learn. As the GOV.UK Service Manual puts it, gathering requirements, planning, designing, building, and testing all happen at the same time rather than in sequence (GOV.UK).

UK public sector delivery uses a recognisable version of this: discovery, alpha, beta, live, and retirement. Alpha tests prototypes and assumptions. Beta builds a working service for real users, first privately and then publicly. Live means the service is fully available and still being improved.

That vocabulary is worth borrowing even outside government, because it gives non-technical stakeholders an honest label for “this is a prototype” instead of “this is nearly finished”.

DevOps and continuous delivery

DevOps compresses the gap between development and operations so that build, test, and deployment run continuously and automatically. The phases still exist. They just happen many times a week rather than once a year.

Where security fits into the SDLC

Security is not a phase. It is a set of practices that run through all of them.

NIST’s Secure Software Development Framework organises those practices into four groups: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. Few SDLC models address security in any detail, so secure practices usually have to be added to whichever model you use.

That last point is worth repeating to anyone buying development services. Ask a prospective supplier which of these frameworks they work to. The answer, or the silence, is informative.

AI-assisted development has not replaced the SDLC

AI coding tools have changed how the development phase feels, but not what the surrounding phases are for.

Google’s DORA research surveyed nearly 5,000 technology professionals in 2025 and found AI adoption at 90%, up 14 points on the previous year, with more than 80% reporting a productivity increase. Around 30% reported little or no trust in AI-generated code (DORA, 2025).

The headline finding is the useful one for anyone planning a project. DORA describes AI as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. Faster code generation raises throughput, but it also increased delivery instability in the research, which puts more weight on the testing, review, and deployment phases rather than less.

Frequently asked questions

How many phases does the SDLC have?

Most models describe between five and seven. Seven is the common breakdown: planning, requirements, design, development, testing, deployment, and maintenance. No numbering is official, and ISO/IEC/IEEE 12207 deliberately avoids tying its processes to fixed stages.

What is the difference between the SDLC and agile?

The SDLC describes the activities. Agile is one way of sequencing them. An agile project still does planning, design, testing, and deployment. It just does them in short repeated cycles instead of one long pass.

Which SDLC phase costs the most?

Maintenance, by a wide margin, at an estimated 40% to 80% of total software cost. Projects that budget only for the build are budgeting for a fraction of the commitment.

Who is responsible for the SDLC?

Responsibility is shared. Business owners and product managers own the planning and requirements phases, developers and architects own design and build, QA owns testing, and operations owns the running system. The handovers between those groups are where most problems start.

What to do with this

If you are commissioning a system, the practical use of the SDLC is as a checklist for your supplier. Ask what happens in each phase, who signs it off, and what you will receive at the end of it.

If you already run software, the phase most likely to need attention is the last one. Find out what is deployed, who patches it, and what happens when the person who built it leaves. That audit is usually cheaper than the incident it prevents.

Are you looking for help with a project?