What Is the Software Development Life Cycle (SDLC)? Phases Explained

Every piece of software, from a 1-page booking form to a banking platform, goes through the same basic journey: someone decides it’s needed, people work out what it should do, engineers design and build it, it’s tested, released and then maintained for as long as it’s used. The software development life cycle, or SDLC, is the name for that journey.

Understanding the SDLC helps business owners ask better questions of their developers, helps project managers plan realistic timelines, and helps new engineers see where their work fits. This guide walks through each phase, the deliverables it produces and how modern teams compress the whole cycle into days or even hours.

What the SDLC is

The SDLC is a framework that breaks software work into distinct phases, each with clear goals and outputs. It gives teams a shared vocabulary and makes sure important steps, such as security reviews or testing, aren’t skipped under deadline pressure.

There’s an international standard for it: ISO/IEC/IEEE 12207, “Systems and software engineering — Software life cycle processes.” Its 2017 edition groups processes into agreement, organizational, technical management and technical categories. Most teams never read the standard, but the phases below reflect the same core ideas.

Different sources split the SDLC into 5, 6 or 7 phases. The names vary; the work doesn’t.

The 7 phases at a glance

Key takeaway: The SDLC isn’t about paperwork. Each phase exists to catch a specific kind of mistake before it becomes expensive: building the wrong thing, building it badly or releasing something broken.

The 7 phases in detail

Phase 1: planning

Planning decides whether the project is worth doing and sets its boundaries. Teams define the problem, the goals, rough scope, budget, timeline, staffing and major risks. They also decide whether to build, buy or adapt existing software.

Deliverables: business case, project charter, high-level scope, budget estimate, risk register.

What goes wrong when skipped: projects start without agreed goals, so success can’t be measured and scope keeps growing.

Phase 2: requirements

This phase turns the idea into specific, testable statements of what the software must do (functional requirements) and how well it must do it (non-functional requirements such as performance, security and accessibility). Analysts and product managers interview stakeholders, observe current processes and document needs.

Deliverables: requirements specification or product backlog, user stories, acceptance criteria. Our guide on how to write a software requirements document walks through each section.

What goes wrong when skipped: the team builds what it assumed the client wanted, not what the client needed.

Phase 3: design

Design decides how the system will meet the requirements. Architects and senior engineers choose the overall structure, technology stack, data model, integrations and hosting. Designers create user flows and interface mockups. Security design happens here too, through threat modeling and choosing protections.

Deliverables: architecture diagrams, data models, API specifications, UI prototypes, security design.

What goes wrong when skipped: systems that work at first but don’t scale, are hard to change and accumulate technical debt fast.

Phase 4: development

Developers write the code, usually in small pieces, with version control, automated unit tests and peer code review. Coding standards and secure coding practices keep quality consistent. AI coding assistants now help with much of this work, but reviewers still need to understand and check what’s generated, as covered in how AI coding assistants are changing software teams.

Deliverables: source code, unit tests, reviewed pull requests, build artifacts.

Phase 5: testing

Testing confirms the software meets requirements and doesn’t break what already works. Common levels include:

• Unit tests: individual functions or components
• Integration tests: components working together
• System and end-to-end tests: complete user journeys
• User acceptance testing: real users or the client confirm it meets their needs
• Non-functional tests: performance, security, accessibility

Deliverables: test plans, automated test suites, test reports, defect lists, sign-off.

Phase 6: deployment

Deployment moves software into production where users can access it. Mature teams automate this with continuous integration and delivery pipelines so releases are repeatable and low-risk. Techniques such as staged rollouts, feature flags and blue-green deployments let teams release to a small group first and roll back quickly. See what CI/CD is and how to build a CI/CD pipeline for details.

Deliverables: production release, release notes, deployment runbook, rollback plan.

Phase 7: maintenance

Most of a software product’s life is spent here. Teams fix bugs, patch security vulnerabilities, update dependencies, improve performance and add features. Monitoring and observability show how the system behaves in the real world; our guide to observability vs monitoring explains the difference.

Deliverables: patches, updates, incident reports, monitoring dashboards, enhancement requests that feed back into planning.

SDLC models: same phases, different shapes

The phases stay the same. What changes is how they’re arranged.

For a deeper comparison of the 2 most common approaches, see agile vs waterfall, and for agile frameworks, Scrum vs Kanban.

How modern teams compress the cycle

In a traditional waterfall project, 1 pass through the SDLC might take a year. Many modern teams go through every phase for a small change in a day or less. Here’s how:

• Small batches. Instead of 1 huge release, teams ship small changes. Each goes through all 7 phases quickly, and problems are easier to find.
• Automation. Continuous integration builds and tests every change automatically. Continuous delivery makes deployment a routine, push-button step.
• Shift left on testing and security. Testing and security checks happen while code is written, not at the end. This is the core idea behind DevSecOps.
• Infrastructure as code. Servers and environments are defined in code, so they can be created and changed reliably.
• Fast feedback from production. Monitoring, feature flags and staged rollouts turn maintenance into a continuous source of learning that feeds planning.
• Cross-functional teams. Developers, testers, operations and security work together instead of handing work over a wall. That’s the heart of DevOps.

To see whether compression is working, many teams track the delivery metrics from Google Cloud’s DORA research program: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Faster throughput with stable or falling failure rates is the goal.

Security across the life cycle

Security can’t be a single phase at the end. The NIST Secure Software Development Framework (SP 800-218) describes practices to build into any SDLC model, such as defining security requirements, protecting code, producing well-secured software and responding to vulnerabilities. CISA’s Secure by Design initiative goes further, urging software makers to take ownership of customer security outcomes rather than leaving protection to buyers.

In practice, that means threat modeling in design, secure coding and dependency scanning in development, security testing before release and fast patching in maintenance.

Where to start: applying the SDLC to your project

1. Pick a model that fits. Stable, fixed-scope work can follow waterfall; most product work fits agile or DevOps.
2. Define what “done” means for each phase. For example, no code is merged without tests and review.
3. Write requirements before building, even if they’re a short brief and a backlog.
4. Automate what repeats. Start with automated tests and builds, then automate deployments.
5. Build security into every phase, not just a final audit.
6. Plan for maintenance from day 1. Budget time and money for updates, patches and monitoring.
7. Review and improve. After each release or quarter, ask which phase caused the most delays or defects and fix that first.

Conclusion

The software development life cycle is the backbone of every successful software project: plan, define requirements, design, build, test, deploy and maintain. The phases don’t change much between methods. What changes is their size and speed. Waterfall runs them once; agile and DevOps run them in small, automated loops. Whichever model you choose, respect what each phase is for, build security and testing in throughout, and plan for the long maintenance tail that every real product has.

Sources

• ISO/IEC/IEEE 12207:2017, Software life cycle processes — international standard for software life cycle processes
• NIST SP 800-218: Secure Software Development Framework — secure development practices across the SDLC
• DORA: Software delivery performance metrics — the 5 delivery metrics for measuring throughput and instability
• CISA: Secure by Design — principles for software makers to own customer security outcomes