Software Development Life Cycle (SDLC): Phases, Models, Methods and Security Explained

Updated September 2026 · Written and maintained by the Progression Agency strategy team

The software development life cycle is the sequence of phases a piece of software goes through from idea to retirement: planning, requirements, design, development, testing, deployment and maintenance. This guide explains each phase, compares the main SDLC models and methods, and covers the security and tooling that modern teams add to the cycle. The software development life cycle stages are the same seven whichever model you use; each phase of the SDLC has its own output, and the process of SDLC is the repeating cycle that links them.

What is the software development life cycle?

The development life cycle (SDLC) is the structured process teams follow to plan, build, test, release and maintain software. It exists so that requirements are understood before code is written, quality is checked before release, and the software keeps working after launch. Explaining the SDLC to a business audience is simple: it is the route from a problem statement to working, supported software, with checkpoints along the way.

The phases of the life cycle

Each phase answers a question. Skipping one does not save time; it moves the cost to a later phase where it is more expensive. PDLC vs SDLC is a question of scope: a product development life cycle also covers market, pricing and support, not only the software. The system development life cycle is the older name for the same idea in information systems. At the newer end, an agentic SDLC lets AI agents draft code and tests while people still review every phase.

1. Planning phase in the development life cycle

The planning phase defines the business goal, the users, the scope of a first release, the budget and timeline, the team and the main risks. Its output is a project charter or a written first-release scope. This is also where build-versus-buy is decided; see software consulting. The planning phase in the software development life cycle also records how success will be measured, which gives testing and acceptance a target later.

2. Requirements analysis

Requirements describe what the software must do (functional) and how well it must do it (non-functional: performance, security, accessibility, compliance). In agile methods they are captured as user stories and refined continuously rather than frozen up front.

3. Design

Design covers architecture (systems, data model, integrations, hosting), interface design (flows and screens; see UI/UX design) and technical decisions such as frameworks and security controls.

4. Development

Engineers implement the design in code, with version control, code review and automated tests written alongside features. In agile models development happens in sprints that each end with working software.

5. Testing

Unit, integration, end-to-end, performance, security and user acceptance testing verify that the software meets requirements. Modern teams automate most of this and run it on every change.

6. Deployment

The software is released to users: through app stores, web hosting or enterprise distribution, usually via a CI/CD pipeline with staged rollouts and the ability to roll back.

7. Maintenance

Bugs are fixed, dependencies and platforms updated, performance monitored and new features added. Maintenance is the longest phase and where most of the total cost of ownership sits.

Development life cycle models

An SDLC model is the arrangement of the phases. The models below are the ones you will meet in practice; the right one depends on how well the requirements are known and how costly change is.

Waterfall

Phases run once, in order, each completed before the next starts. It suits well-understood, regulated or contract-fixed projects and fails when requirements change mid-build.

V-model

A waterfall variant that pairs each development phase with a corresponding test phase (requirements with acceptance tests, design with integration tests), common in safety-critical software.

Iterative and incremental

The software is built in repeated cycles, each adding capability. Feedback from one cycle shapes the next, which suits products whose requirements become clear with use.

Spiral

Cycles driven by explicit risk analysis: each loop plans, analyzes risk, builds and evaluates. Used for large, high-risk systems. Spiral methodology in software development puts a risk review before each loop of building, so a team can stop or change direction when a risk costs more than the feature is worth.

Agile (Scrum, Kanban)

All phases run inside short sprints or a continuous flow, delivering working software every few weeks with continuous customer feedback. See agile software development for the manifesto, Scrum roles and events.

DevOps and continuous delivery

Agile extended into operations: automated pipelines integrate, test and deploy every change, with monitoring feeding back into the backlog. Most modern web and mobile teams run an agile-plus-DevOps model.

How a software development model changes the contract

The model decides how money is committed, which matters more to the buyer than to the engineers. A fixed-price contract needs a fixed scope, so it fits sequential work where requirements are settled and every change goes through a formal request. Agile work is usually bought as a team for a period: you control what gets built next, and the supplier does not promise the final feature list.

Neither is safer by default. Ask any vendor how a change is priced under the approach they propose, who approves it, and what you own if the project stops halfway.

Software development methods and processes

Methods are the practices used inside a model: how work is planned, reviewed and released. The most common methods of software development today are Scrum, Kanban, Extreme Programming practices such as test-driven development and pair programming, lean software development, and DevOps practices such as continuous integration and continuous delivery. Project management in the software development life cycle runs across all of them: someone has to hold the scope, budget and dates while the chosen method decides how the work gets planned and reviewed.

Software development life cycle models and methods compared

A software development life cycle model arranges the phases, and a method is how the work inside them gets done. Software development life cycle models such as waterfall, V-model, spiral, iterative and agile answer the question of order, while software development life cycle methods such as Scrum, Kanban and test-driven development answer the question of practice. The SDLC waterfall methodology runs each phase once, in sequence, and suits work whose requirements are fixed before development starts.

Pick the model first, then the methods that fit it. A team on a regulated, fixed-scope project may combine waterfall planning with strict documentation, while a product team that learns from users every few weeks will combine agile with continuous delivery.

Software development life cycle in agile

The same seven phases stay in place, but the software development life cycle in agile runs them in short loops. An agile software development life cycle repeats planning, design, build and test inside each sprint, so requirements, code and tests change together. The software development life cycle phases in agile are not separate stages handed from one team to another but activities that overlap in every iteration. Among software development life cycle models, agile is the one that favors working software every few weeks over a complete plan up front, and it fits products whose requirements will change with user feedback.

Security in the life cycle

A secure development life cycle adds security activities to every phase instead of a single audit before release: threat modeling in design, secure coding standards and dependency scanning in development, security testing before deployment and patching in maintenance. The NIST Secure Software Development Framework (SSDF) describes these practices, and the OWASP Top 10 lists the risks most worth designing out.

Secure software development life cycle

Security goes into every phase of a secure software development life cycle instead of being tested once at the end. Software development life cycle security starts with threat modeling during design, secure coding rules and dependency scanning during development, security testing before release and patching during maintenance.

NIST’s Secure Software Development Framework, SP 800-218, describes itself as a core set of high-level secure software development practices that can be integrated into each SDLC implementation, with the aim of reducing vulnerabilities in released software. SDLC cyber security is therefore a set of habits repeated in every phase, not a single review.

Software development lifecycle tools

Each phase has tools that make it repeatable. The list below reflects what most modern teams use; the choice matters less than using them consistently.

SDLC tools and documentation

SDLC tools are only useful when they leave a record. Documentation in SDLC work usually means a written first-release scope, requirement stories, an architecture note, test results, release notes and a runbook for operations, kept next to the code so that it changes with it. A software development life cycle policy ties these together by stating which phases are required, who approves each one and which records must exist before release. Keep it to a page so that people actually read it.

Which SDLC model should you choose?

Choose by how well you know the requirements and how expensive change is. Fixed-scope, regulated or contractual work suits waterfall or V-model. Products that will change with user feedback, which is most business software, suit agile with DevOps practices. Large systems with unknown risks suit spiral or iterative approaches. Whatever the model, keep the phases and add security to each one.

A model software development life cycle for a small team

Small projects do not need heavy paperwork, but each phase should leave something behind. Planning should leave a one-page scope that says what is left out. Requirements should leave stories a person in the business has signed. Design should leave a data model and clickable screens. Development and testing should leave automated checks that run on every change, and release should leave a rollback plan and a named owner for bugs.

If a phase leaves nothing a new team member could read, it was probably skipped.

How Progression Agency runs the development life cycle

We plan a written first release, refine requirements as user stories, design architecture and interface together, build in two-week sprints with automated tests and code review, release through CI/CD pipelines with staged rollouts, and support the software after launch. See custom software development and mobile app development.

Frequently asked questions