SDLC, the software development life cycle, is the structured sequence of phases through which software is planned, specified, designed, built, tested, deployed and maintained until it is retired. In the software lifecycle, the SDLC is the process view: it defines what work happens, in what order, with which inputs, outputs and approval points.
An SDLC is not one fixed method. Waterfall, the V-model, iterative, spiral and agile models are all ways of organizing the same basic activities. They differ mainly in how often the phases repeat and how early working software reaches users.
The phases of the software development life cycle
Most SDLC descriptions contain six to eight phases. Names vary between organizations, but the purpose of each phase is stable: reduce uncertainty step by step and produce verifiable deliverables that the next phase depends on.
| Phase | Main question | Typical deliverables |
|---|---|---|
| Planning | Should we build it, and with what budget? | Business case, scope, schedule, risk list |
| Requirements analysis | What must the software do? | Requirements specification, user stories, acceptance criteria |
| Design | How will it be built? | Architecture, data model, interface specifications |
| Implementation | Build the software | Source code, unit tests, build scripts |
| Testing | Does it work as required? | Test plans, defect reports, test results |
| Deployment | How does it reach users? | Release package, release notes, rollout plan |
| Maintenance | How is it kept useful and safe? | Patches, hotfixes, maintenance releases |
Many models add a final retirement or decommissioning step, which covers data migration, archiving and the end of life announcement. Treating retirement as part of the cycle prevents abandoned systems that still run but no longer receive security updates.
SDLC models and how they differ
An SDLC model is a specific arrangement of the phases. Sequential models complete each phase once, while iterative models run short cycles that pass through all phases repeatedly. The choice depends on how stable the requirements are and how costly late changes would be.
| Model | Flow of phases | Best suited for |
|---|---|---|
| Waterfall | Strictly sequential, one pass | Stable, well-understood requirements |
| V-model | Sequential, each design level paired with a test level | Safety-critical and regulated systems |
| Iterative and incremental | Repeated cycles adding features | Large systems delivered in stages |
| Spiral | Risk-driven cycles with prototypes | High-risk, novel projects |
| Agile (Scrum, Kanban) | Short iterations of one to four weeks | Changing requirements, fast feedback |
| DevOps | Continuous flow with automated delivery | Online services with frequent releases |
The classic waterfall description is often misread as a recommendation for a single pass. Its early proponents already pointed out the risk of discovering problems only during testing, which is why later models introduced feedback loops, prototypes and incremental delivery.
SDLC compared with related lifecycle concepts
The SDLC is easily confused with neighboring concepts in the software lifecycle. The key distinction is that the SDLC describes how software is developed, while other lifecycles describe how versions are released and supported.
| Concept | Focus | Relation to the SDLC |
|---|---|---|
| Release cycle | Cadence of shipping versions | The deployment rhythm inside the SDLC |
| Product lifecycle | Market phases from launch to withdrawal | Business view around many SDLC iterations |
| Support lifecycle (LTS, end of life) | How long a version receives fixes | Defines the length of the maintenance phase |
| Agile software development | Values and practices for iterative work | One family of SDLC models |
| Version lifecycle (alpha, beta, release candidate, general availability) | Maturity stages of a release | Milestones within testing and deployment |
Standards and the secure SDLC
Formal SDLC practice is described in ISO/IEC/IEEE 12207, the international standard for software life cycle processes, and its systems counterpart ISO/IEC/IEEE 15288. These standards do not prescribe a model; they define processes such as requirements definition, verification and maintenance that any model must cover.
A secure SDLC integrates security activities into every phase instead of adding a penetration test at the end. Common frameworks include the NIST Secure Software Development Framework (SP 800-218) and vendor programs such as the Security Development Lifecycle. Typical activities are threat modeling during design, static code analysis during implementation and dependency scanning before release.
| Phase | Security activity | Purpose |
|---|---|---|
| Requirements | Security requirements | Define authentication, privacy and logging needs |
| Design | Threat modeling | Find design flaws before code exists |
| Implementation | Code review and static analysis | Catch injection and memory errors early |
| Testing | Dynamic testing and fuzzing | Detect runtime vulnerabilities |
| Maintenance | Vulnerability management | Patch issues found after release |
Choosing and tailoring an SDLC
No single model fits all projects, so organizations tailor the SDLC to project size, risk and regulation. A medical device team may combine a V-model for traceability with agile sprints for implementation, while a web startup may use continuous delivery with lightweight design reviews.
- Requirement stability: stable requirements tolerate sequential models; volatile ones need short iterations.
- Regulatory needs: audits require documented phase gates and traceability from requirement to test.
- Cost of failure: higher consequences justify more formal verification and review.
- Release frequency: frequent releases demand automated testing and deployment pipelines.
Common pitfalls in SDLC practice
Most SDLC failures come from skipping or compressing phases under schedule pressure. Weak requirements analysis leads to building the wrong product, and squeezed testing pushes defects into production, where they are far more expensive to fix than during design.
Another pitfall is process theater: producing every document the model lists without using them to make decisions. A healthy SDLC keeps only the artifacts that reduce real risk, and treats maintenance as a planned phase with budget rather than an afterthought.
Explained without jargon
The SDLC is the recipe for making software, from the first idea to the day it is switched off. It is similar to building a house: first deciding what is needed, then drawing plans, building, inspecting, handing over the keys and doing repairs for years afterward.
Some teams build the whole house in one go, while others build one room at a time and let the owner try it before adding the next. Both follow the same basic steps. The SDLC simply makes sure no important step is forgotten.
A typical use case
A hospital commissions software that schedules operating rooms. Because errors could delay surgeries, the vendor uses a tailored SDLC: a formal planning and requirements phase with surgeons and nurses, a reviewed architecture design, then implementation in two-week iterations with demonstrations to hospital staff.
Every requirement is linked to at least one test case, and threat modeling identifies risks around patient data. Before go-live, the system passes an acceptance test with real schedules in a training environment, and the rollout starts with one surgical department.
After deployment, the vendor runs a planned maintenance phase with monthly patches. The structured cycle gives the hospital traceable evidence for its auditors and a system that changes safely as procedures evolve.