WhatsAppWhat the SDLC is
The software development life cycle (SDLC) is the structured process teams follow to plan, design, build, test, release and maintain software. Whatever the methodology, the same core activities appear in every successful project. What differs is how they are sequenced: all at once in long phases, or repeatedly in short cycles.
The seven phases
-
1. Planning
Goals, scope, budget, risks and feasibility.
-
2. Requirements
User needs, features, constraints and acceptance criteria.
-
3. Design
Architecture, data models, UX flows and interface design.
-
4. Development
Writing code, code reviews and continuous integration.
-
5. Testing
Unit, integration, end-to-end, performance and security testing.
-
6. Deployment
Releasing to production with monitoring and rollback plans.
-
7. Maintenance
Fixes, updates, improvements and eventual retirement.
Popular SDLC models
| Model | How it works | Best for |
|---|---|---|
| Waterfall | Each phase completed before the next begins | Fixed, well-understood requirements; regulated documentation |
| Agile / Scrum | Short sprints delivering working software | Most products where requirements evolve |
| Kanban | Continuous flow with work-in-progress limits | Support, maintenance and ops teams |
| Iterative / incremental | Product built in increments with feedback | Large systems delivered in stages |
| DevOps | Development and operations integrated with automation | Teams releasing frequently |
Why most teams use Agile
Agile methods accept that requirements change as teams and customers learn. Working software every one or two weeks lets stakeholders give feedback early, reduces the risk of building the wrong thing and makes progress visible. Agile still includes planning, design and testing — they simply happen continuously in smaller pieces rather than once in long phases.
Security and quality across the life cycle
- Security requirements and threat modelling during planning and design
- Code review, static analysis and automated tests during development
- Performance, accessibility and security testing before release
- Monitoring, patching and incident response during maintenance
What each phase produces
| Phase | Typical deliverables |
|---|---|
| Planning | Project goals, high-level scope, budget range, risk list |
| Requirements | User stories, acceptance criteria, non-functional requirements |
| Design | Architecture diagram, data model, wireframes and UI designs |
| Development | Working code, code reviews, automated tests, technical documentation |
| Testing | Test plans, test results, defect reports, performance and security findings |
| Deployment | Release notes, deployment pipeline, rollback plan, monitoring |
| Maintenance | Incident reports, patches, improvement backlog |
Walk-through: one feature through an Agile cycle
Take a feature such as “customers can download invoices as PDF”. In planning, the product owner adds it to the backlog with a business reason. During backlog refinement it becomes a user story with requirements and acceptance criteria: which invoices, which format, who can access them. A designer adds a download button to the existing screen and a developer sketches the design: generate PDFs on demand, cache them, check permissions.
In the sprint, development and testing happen together: unit tests for the PDF generator, an integration test for permissions and an end-to-end test for the download. After code review, the change merges and the CI pipeline deploys it to staging, then to production behind a feature flag. Monitoring confirms no errors, the flag is turned on for everyone and the feature enters maintenance. Every SDLC phase happened — in days rather than months.
Roles across the life cycle
| Role | Main contribution |
|---|---|
| Product owner | Sets priorities, defines value, accepts finished work |
| Business analyst | Clarifies requirements and processes |
| Designer | User research, flows and interface design |
| Developers | Design, build and test the software |
| QA engineer | Test strategy, automation and exploratory testing |
| DevOps engineer | Pipelines, infrastructure, monitoring and reliability |
| Project or delivery manager | Planning, coordination, risks and reporting |
On smaller teams, one person often covers several roles. What matters is that every responsibility has an owner.
Choosing a model for your project
- Requirements likely to change? Choose Agile.
- Strict regulatory documentation and fixed scope? Consider Waterfall or a hybrid with formal stage gates.
- Mostly support and small changes? Kanban keeps work flowing.
- Large system with a fixed launch date? Iterative delivery with a clearly prioritised first release.
- Releasing frequently? Add DevOps practices — automation, monitoring and small changes — to whichever model you choose.
SDLC artefacts checklist
Regardless of methodology, a healthy project leaves a trail that helps future teams understand and change the software:
- A prioritised backlog with clear acceptance criteria
- Architecture and data model documentation kept up to date
- Version control history with meaningful commit messages and reviews
- Automated test suites running on every change
- Release notes for each deployment
- Runbooks for deployment, monitoring and incident response
Common SDLC mistakes
- Skipping discovery and starting development with vague requirements
- Treating testing as a phase at the end instead of continuous work
- Calling it Agile but delivering nothing usable until the end
- Releasing without monitoring or a rollback plan
- Forgetting that maintenance is part of the life cycle and needs budget
Waterfall, Agile and hybrid compared in detail
| Aspect | Waterfall | Agile (Scrum) | Hybrid |
|---|---|---|---|
| Planning | Detailed plan up front | High-level roadmap; detailed planning each sprint | Fixed milestones; flexible detail inside them |
| Requirements | Signed off before design | Evolve through backlog refinement | Core scope fixed; details evolve |
| Delivery | One release at the end | Working software every 1–2 weeks | Incremental releases towards milestones |
| Change | Formal change control | Expected and welcomed | Allowed within milestone scope |
| Customer involvement | Heavy at start and end | Continuous | Regular reviews at milestones and sprints |
| Typical fit | Regulated, well-understood, fixed scope | Products with evolving requirements | Fixed-budget projects that still need feedback |
DevSecOps: building security into every phase
Traditional life cycles treated security as a test at the end. Modern teams build it in throughout, an approach often called “shifting left”. Finding a design flaw in a review takes a conversation; finding it in production can take an incident response.
| Phase | Security activity |
|---|---|
| Planning | Identify sensitive data, compliance requirements and security goals |
| Design | Threat modelling: what could go wrong and how the design prevents it |
| Development | Secure coding standards, peer review and secrets management |
| Build | Automated dependency scanning and static analysis in the CI pipeline |
| Testing | Dynamic scanning, and penetration testing for high-risk systems |
| Release | Infrastructure hardening, least-privilege access, audit logging |
| Operations | Patching, monitoring, alerting and incident response drills |
See application security for how we apply these practices.
Measuring how well your life cycle works
A life cycle is only useful if it delivers working software reliably. Four delivery metrics, popularised by DevOps research, give a balanced view of speed and stability:
- Deployment frequency: how often changes reach production.
- Lead time for changes: how long it takes from code committed to code running in production.
- Change failure rate: the share of deployments that cause a problem needing a fix.
- Time to restore: how quickly service recovers after a failure.
Track trends rather than chasing targets. A team that releases more often with fewer failures over time has a healthy process, whichever methodology it uses.
Glossary of SDLC terms
| Term | Meaning |
|---|---|
| Backlog | Prioritised list of work still to be done |
| Sprint | A fixed period, often two weeks, in which a team delivers a set of work |
| User story | A requirement written from the user’s point of view |
| Acceptance criteria | Conditions a feature must meet to be considered done |
| Definition of done | The quality checklist every piece of work must pass |
| CI/CD | Continuous integration and delivery: automated building, testing and deployment |
| UAT | User acceptance testing by the business before release |
| Technical debt | Shortcuts that make future changes slower or riskier |
Questions to ask about a vendor’s process
- How long are your iterations, and what do we see at the end of each one?
- How are requirements captured, prioritised and changed?
- What does your definition of done include? Tests, review, documentation?
- How do code changes reach production, and how are they rolled back?
- When do we take part in testing and acceptance?
- What happens after launch, and who handles maintenance?
Adapting the life cycle to project size
The same phases apply to a two-week feature and a two-year platform, but the ceremony around them should scale with risk and team size.
| Project size | What the life cycle looks like |
|---|---|
| Small change or feature | A ticket with acceptance criteria, code review, automated tests and a normal deployment |
| New product or MVP | A discovery phase, design prototypes, two-week sprints, a staging environment and a planned launch |
| Large platform or replacement | Architecture decision records, phased releases, formal UAT, a data migration plan and cut-over rehearsals |
| Regulated system | All of the above plus traceability from requirement to test and documented change approval |
How long each phase takes in practice
Durations vary widely, but as a rule of thumb for a typical business application built by a small team: discovery and requirements take two to four weeks, design overlaps with the first sprints, development runs in two-week sprints for several months, and a release-hardening period of one to two weeks precedes launch. Maintenance then continues for the life of the system and usually costs more in total than the initial build.
Where the life cycle usually breaks down
Most problems in delivery come from the handoffs between phases rather than the phases themselves: requirements that designers interpret differently, designs that developers cannot build as drawn, features that pass tests but fail user acceptance, and releases that operations teams were not prepared for. Short feedback loops are the cure. Involve developers in design reviews, testers in requirement discussions and operations in release planning, so each handoff becomes a conversation rather than a surprise.
Documentation by phase: how much is enough?
Documentation is often either neglected or produced for its own sake. A practical rule of thumb is to write what the next person needs to make a good decision — no more.
| Phase | Lightweight project | Regulated or large project |
|---|---|---|
| Planning | One-page brief and success measures | Business case, risk register, approvals |
| Requirements | User stories with acceptance criteria | Traceable requirements specification |
| Design | Architecture sketch and key decisions | Architecture document, threat model, data flows |
| Testing | Automated test suite and release checklist | Test plans, evidence and sign-offs |
| Maintenance | Runbook and README | Operations manual, change records, audit trail |
Rules of thumb; adapt to your organisation and regulator.
How the life cycle changes for AI features
Products that include machine learning or large language models follow the same phases with a few additions. Requirements must define acceptable error rates and what happens when the model is unsure. Design includes choices about data, models and prompts. Testing adds evaluation sets that measure answer quality, plus checks for bias and unsafe output. Maintenance includes monitoring for drift and re-evaluating whenever a model or prompt changes.
- Evaluation dataset agreed before building
- Human review path for low-confidence results
- Versioning for prompts, models and datasets
- Monitoring of quality and cost in production
Life cycle checklist for project sponsors
- Do we know what success looks like and how it will be measured?
- Has someone reviewed security and privacy before build starts?
- Are we seeing working software at least every two weeks?
- Is testing automated for the most important workflows?
- Do we have a plan and budget for maintenance after launch?
How we apply the SDLC
Our projects start with a short discovery and design phase, followed by two-week development sprints with continuous testing, automated deployment and ongoing maintenance. Read more on our software development process page.
Browse more practical guides in Software Development Guides & Resources.