Software Development Life Cycle (SDLC)

TL;DR

The Software Development Life Cycle (SDLC) is a structured way to take software from an idea to operation and, eventually, retirement. It helps a team decide what to build, design the solution, create and test it, release it safely, and improve it using real-world feedback. The phases describe what work must happen. Methods such as Waterfall, Scrum, and Kanban describe how a team organizes that work.

Most software begins with a problem, not with code. A hospital may need a safer way to schedule appointments. A bank may need to detect suspicious payments. A small business may want customers to order online.

Writing code is one part of solving such a problem. The team also has to understand the users, agree on requirements, choose a design, verify that the software behaves correctly, release it, support it, and handle future changes. The Software Development Life Cycle, usually shortened to SDLC, gives that work a visible structure.

What is the SDLC?

The SDLC is the collection of activities used to design, create, deliver, operate, and maintain software. The NIST glossary describes it as a formal or informal methodology for designing, creating, and maintaining software.

The word life cycle matters. Software continues to require attention after its first release. Users find problems, business rules change, security vulnerabilities are discovered, and the technology underneath the product ages. Eventually, the software may be replaced and retired.

The SDLC provides a shared map for this work. It helps a team answer:

• What problem are we solving, and for whom?
• What must the software do?
• How should it be designed?
• How will we build and verify it?
• How will it reach users safely?
• Who will operate and support it?
• How will feedback and change enter the next cycle?

Software or system development life cycle?

SDLC is also expanded as System Development Life Cycle, especially in government and enterprise material. That broader term can cover people, processes, data, hardware, and software as parts of one information system. This guide focuses on the software development life cycle, but the basic lifecycle idea is the same.

There is no universal list of SDLC phases

Organizations divide and name the work differently. One process may combine planning and requirements, while another may separate deployment, operations, and maintenance. The labels matter less than making sure the necessary work has an owner and a clear outcome.

Why use an SDLC?

An SDLC creates shared expectations around work that would otherwise remain hidden until it causes trouble.

• Alignment: Stakeholders and the delivery team can agree on the problem, scope, and measures of success before committing to a solution.
• Visibility: Deliverables and decision points make progress, uncertainty, and unresolved risk easier to see.
• Earlier feedback: Reviews, prototypes, and tests expose weak assumptions while they are still relatively inexpensive to change.
• Traceability: The team can follow a requirement into its design, code, tests, and release. Traceability means preserving these links so that a later change can be assessed.
• Operational readiness: Deployment, monitoring, support, recovery, and retirement receive deliberate attention.
• Repeatability: A known process makes planning and estimation more consistent, while results from one cycle can improve the next.

Structure cannot guarantee that a product will succeed. It gives the people involved better information for deciding what to build, when it is ready, and which risks remain.

Phases and methods are different

Two ideas are often mixed together:

• SDLC phases describe the kinds of work involved, such as requirements, design, development, and testing.
• An SDLC model or development method describes how the team moves through that work.

A Waterfall project may complete each phase mostly once and in sequence. An Agile team may revisit the same phases for every small product increment. Both still perform planning, design, development, testing, and release activities.

An increment is a usable addition to the product. For example, account registration could be one increment of an online booking system, followed by appointment search and then payment.

The SDLC at a glance

flowchart LR
    IDEA["Problem or opportunity"] --> PLAN["1. Discovery and planning"]
    PLAN --> REQ["2. Requirements"]
    REQ --> DESIGN["3. Design"]
    DESIGN --> BUILD["4. Development"]
    BUILD --> TEST["5. Verification and testing"]
    TEST --> RELEASE["6. Deployment and release"]
    RELEASE --> OPERATE["7. Operations and maintenance"]
    OPERATE --> RETIRE["8. Retirement"]

    TEST -. "defects and learning" .-> BUILD
    OPERATE -. "user and production feedback" .-> PLAN

The arrows show the main flow, not a rule that every project must move in a straight line. Teams often return to earlier work when they learn something new.

The outputs in the last column are examples of deliverables. A deliverable is a result that another person can review or use. It may be a document, a decision, a design, a piece of working software, or test evidence.

1. Discovery and planning

Discovery starts by understanding the problem, the people affected by it, and the result the organization wants. A person or group affected by the software is called a stakeholder. Users are stakeholders, but so are sponsors, support teams, regulators, business owners, and teams that depend on the system.

Planning turns the initial idea into a realistic piece of work. The team usually considers:

• the business goal and how success will be measured
• the intended users and their current difficulties
• scope, meaning what the project will and will not cover
• major risks, dependencies, cost, skills, and time
• legal, privacy, security, and operational constraints
• whether to build, buy, or adapt an existing solution

A dependency is something the work relies on, such as another team, an external service, or a decision that must happen first.

The team may also perform a feasibility assessment. Feasibility asks whether the idea is practical from several angles:

• Technical feasibility: Can the available technology and skills support it?
• Economic feasibility: Are the expected benefits reasonable compared with the full cost?
• Operational feasibility: Can the organization run and support it?
• Schedule feasibility: Can a useful result be delivered within the required time?

The outcome should be a reasoned decision to proceed, change direction, postpone the work, or stop. Ending a weak idea at this stage is a useful result because it avoids much more expensive rework later.

2. Requirements

A requirement is a condition or capability the solution must satisfy. Requirements connect the original problem to later design, development, and testing.

They are commonly divided into two groups:

• Functional requirements describe behaviour. “A patient can cancel an appointment” is a functional requirement.
• Non-functional requirements describe qualities or constraints. Response time, availability, accessibility, privacy, security, and the number of simultaneous users are examples.

“The page should be fast” is difficult to verify. “For 95% of requests, the appointment search page returns a result within two seconds under the expected daily load” gives the team something measurable.

Teams may express requirements as traditional specifications, diagrams, examples, or user stories. A user story is a short statement of a need from a user’s point of view. It is usually accompanied by acceptance criteria, which are specific conditions that must be true before the team accepts the work as complete.

Example:

As a patient, I want to cancel an appointment online so that I do not have to call the clinic.

Possible acceptance criteria:

• A signed-in patient can cancel their own future appointment.
• A patient cannot cancel another person’s appointment.
• The clinic and patient receive confirmation.
• The time becomes available for another booking.

Requirements will change as the team learns. The important practice is to record the change, assess its effect, and keep the relevant design and tests aligned with the current requirement.

3. Design

Design explains how the solution will satisfy its requirements before the team commits to all of the implementation details.

There are two closely related views:

• User-experience design (UX design) covers how people move through the product, what information they see, and how the interface behaves.
• Technical design covers the software’s structure, data, integrations, infrastructure, security controls, and operational behaviour.

The high-level technical structure is often called software architecture. It identifies the main components, their responsibilities, and how they communicate. A component is a part of the system with a defined job, such as appointment search or payment processing.

Design work may include:

• screen sketches and interactive prototypes
• data models that describe what information is stored and how it is related
• APIs, or application programming interfaces, that define how software components exchange requests and responses
• choices about databases, hosting, and third-party services
• failure handling, capacity, backup, and recovery plans
• a threat model, which examines how the system could be attacked and how those risks will be controlled

A prototype is an early version created to answer questions or gather feedback. It may be a simple screen mock-up or a small working experiment. Prototype code is not automatically suitable for production; exploratory code may lack the security, testing, performance, and maintainability expected of a live system.

Good design gives the team enough direction for the next decision. Producing every possible detail in advance can waste time when requirements are still changing.

4. Development

During development, the team turns the design into working software. Developers write source code, the human-readable instructions from which an application is built or executed.

Development usually involves more than typing code:

• Version control records changes to files so the team can collaborate, review history, and recover earlier versions.
• Code review allows another developer to examine a change for correctness, clarity, security, and maintainability.
• Unit tests check small pieces of behaviour, such as a calculation or validation rule, in isolation.
• A build converts source code and related files into a form that can be run or deployed.
• Technical documentation explains decisions that future maintainers need to understand.

Teams normally divide large requirements into smaller work items. Small changes are easier to review, test, and correct. They also expose misunderstandings earlier.

Detailed explanations of these techniques are collected under SDLC Development Practices.

5. Verification and testing

Verification checks the software against its specified requirements and design. Validation asks whether the resulting product solves the user’s real problem. The terms are sometimes used interchangeably in everyday project work, but the distinction is helpful: a team can build the specified feature correctly and still build the wrong feature.

Testing provides evidence about quality and risk. Different test levels answer different questions:

A defect, often called a bug, is a difference between expected and actual behaviour. Test results help the team find defects and help decision-makers understand the remaining risk.

Testing does not have to wait until all development is complete. Reviews, automated tests, and early user feedback can run throughout the cycle.

6. Deployment and release

These two words describe different decisions:

• Deployment is the technical act of installing a software version in an environment.
• Release is making a feature available to its intended users.

An environment is a place where software runs for a particular purpose. Development environments support coding, test environments support verification, and the production environment serves real users and real business activity.

A team can deploy code to production while keeping a feature unavailable through a feature flag, which is a controlled switch that turns functionality on or off. This separation allows teams to test operational readiness before exposing the change to everyone.

Release preparation may include:

• automated build, test, and security checks
• configuration and data changes
• approvals required by risk or regulation
• user communication and support preparation
• a rollback plan for returning to a known safe version
• a staged rollout to a small group before wider release

A successful deployment means the change reached the target environment. A successful release means users can use it safely and it produces the expected result.

7. Operations and maintenance

Once software is live, the team has evidence that test environments cannot provide: real traffic, real data, unexpected user behaviour, and changing external conditions.

Operations covers the routine work required to keep the service available, secure, and useful. Maintenance includes:

• correcting defects
• applying security patches
• adapting to changed business rules or external systems
• improving performance and reliability
• adding or changing features
• updating documentation and support procedures

A patch is a software change intended to correct a problem, often a defect or security vulnerability.

Teams use monitoring to detect known unhealthy conditions, such as a high error rate. They also collect logs, metrics, and traces to investigate unfamiliar problems:

• Logs are timestamped records of events.
• Metrics are numerical measurements tracked over time, such as request count or response time.
• Traces show how one request travels through multiple components.

Together, this information supports observability, the ability to understand a system’s internal state from the evidence it produces.

An unplanned interruption or reduction in service quality is called an incident. Incident response restores service, communicates impact, and studies the cause so that the same class of failure becomes less likely.

Maintenance also addresses technical debt. Technical debt is the future cost created when a team chooses a limited or expedient solution today. Some debt is a deliberate trade-off; unmanaged debt gradually makes changes slower and riskier.

8. Retirement

Software reaches the end of its useful life when it is replaced, no longer provides enough value, becomes too risky to operate, or depends on unsupported technology.

Retirement requires planning because turning off an application may affect users, data, integrations, legal obligations, and other systems. Typical work includes:

• notifying users and dependent teams
• migrating active users and required data
• preserving records that must be retained
• deleting data that should no longer be kept
• removing access, credentials, infrastructure, and integrations
• confirming that billing, monitoring, and support have ended

Retirement is also called decommissioning. A controlled retirement reduces cost and removes systems that might otherwise remain forgotten and vulnerable.

Security and quality belong in every phase

Security work becomes expensive and disruptive when it appears only before release. A secure SDLC adds relevant security practices to the existing lifecycle:

• Planning identifies regulations, sensitive data, and acceptable risk.
• Requirements state authentication, authorization, privacy, and audit needs. Authentication confirms identity, authorization controls what an identity may do, and audit records preserve a trace of significant actions.
• Design includes threat modelling and secure architecture.
• Development uses secure coding, peer review, and checks of software dependencies, which are external packages or components the product relies on.
• Testing checks security controls and searches for vulnerabilities.
• Deployment protects credentials and production configuration.
• Operations monitors attacks, patches vulnerabilities, and learns from incidents.
• Retirement removes access and disposes of data safely.

This earlier attention is often called shift-left security. The name comes from lifecycle diagrams, where earlier phases appear on the left. It means moving useful security feedback closer to planning and development while keeping operational security in place after release.

NIST’s Secure Software Development Framework (SSDF) provides practices that can be integrated into any SDLC model. It groups them around preparing the organization, protecting software from tampering, producing well-secured releases, and responding to remaining vulnerabilities. OWASP also recommends building security actions into the lifecycle a team already uses.

Quality follows the same principle. Clear requirements, design reviews, automated tests, production monitoring, and user feedback create several opportunities to prevent or detect problems.

Common ways to organize the SDLC

No method removes the need for sound engineering judgment. A team may combine several approaches and adjust them to the product’s risk, size, and rate of change.

Iterative and incremental are related but different. Iteration improves or revises something. Incremental delivery adds another usable part. Many modern teams do both: they release a small capability, learn from it, and refine it in a later cycle.

Detailed notes are collected under SDLC Development Approaches.

Where Agile, Scrum, and Kanban fit

Agile is a set of values and principles for developing software through collaboration, frequent delivery, feedback, and adaptation. It emerged as a response to heavyweight development processes, and its foundation is the 2001 Manifesto for Agile Software Development.

Agile does not define one mandatory lifecycle. Requirements, design, coding, and testing still happen, usually in smaller and overlapping cycles.

Scrum is a framework teams can use to apply an empirical approach, meaning decisions are based on observation and experience. Work happens in fixed-length cycles called Sprints, each lasting one month or less. A Product Backlog holds ordered work for the product, and each Sprint should create a usable Increment that meets the team’s agreed quality standard. The official Scrum Guide defines Scrum’s accountabilities, events, and artifacts.

Kanban is a strategy for improving the flow of work. A team visualizes its workflow, actively manages work items, and improves the workflow using evidence. Many Kanban systems limit work in progress (WIP), meaning the number of started but unfinished items, so that work finishes instead of accumulating. The Kanban Guide does not require Sprints; teams may combine Kanban practices with Scrum or another way of working.

Calling Scrum and Kanban “SDLC phases” creates confusion. They are ways to manage the flow of work through lifecycle activities.

Where DevOps and CI/CD fit

Traditional hand-offs often separated the people developing software from the people operating it. DevOps brings development and operations closer through shared responsibility, collaboration, and automation. It connects release and production feedback to everyday engineering work.

CI/CD refers to automation practices commonly used with DevOps:

• Continuous Integration (CI): Developers integrate small code changes frequently. An automated pipeline builds and tests each change to find integration problems early.
• Continuous Delivery: A verified change is kept ready for production. Releasing it may still require a business or human decision.
• Continuous Deployment: A change that passes the required checks is released to production automatically.

A pipeline is the automated sequence of steps that builds, tests, checks, packages, and deploys a change.

DevOps and CI/CD change the speed and coordination of the lifecycle. They do not remove the need to understand requirements, make design decisions, test risk, or maintain the software.

A small example: online appointment booking

Consider a clinic that currently books every appointment by phone.

The same lifecycle can be handled sequentially or in short cycles. An iterative team might first release appointment search to a small group, then add booking and cancellation after learning from real use.

Practical controls that keep the lifecycle useful

An SDLC becomes paperwork when its activities do not influence decisions. A lightweight process can still provide strong control:

1. Give each phase or activity a clear owner.
2. Define the evidence needed for important decisions.
3. Make requirements measurable enough to test.
4. Keep changes small enough to review and recover.
5. Automate repeatable checks where the result is trustworthy.
6. Record significant design, security, and risk decisions.
7. Collect production and user feedback.
8. Use that feedback to update plans, requirements, and priorities.
9. Adjust the process to the product’s risk instead of applying identical ceremony to every change.

Some organizations use gates, which are checkpoints before a major commitment such as funding, production release, or retirement. A gate should make risk visible and support a decision. It should not exist only to collect approvals.

Common mistakes

• Starting with a preferred technology: The team may build an impressive solution to the wrong problem.
• Treating requirements as fixed forever: Learning and external change make controlled requirement updates necessary.
• Leaving testing until the end: Late defects are harder to diagnose and may expose design problems when change is costly.
• Confusing deployment with success: Software in production has value only when it works for users and produces the intended outcome.
• Making security a final review: Security requirements and design choices need attention throughout the lifecycle.
• Ignoring operations: A product that cannot be monitored, supported, recovered, or patched is incomplete.
• Skipping retirement: Forgotten systems continue to cost money and may retain sensitive data or access.
• Following a method mechanically: Process should reduce uncertainty and risk. Extra ceremony without a useful decision or outcome is waste.

Key terms

Summary

• The SDLC covers software from the initial problem through retirement.
• Phase names vary, but the work usually includes planning, requirements, design, development, testing, release, operations, and retirement.
• Phases describe what work happens; Waterfall, Agile approaches, Scrum, Kanban, and other models describe how teams organize or move through it.
• Deployment and release are different: one installs a change, while the other makes it available to users.
• Security, quality, and feedback belong throughout the lifecycle.
• The process should be proportionate to risk and should produce evidence that helps people make better decisions.

Sources and further reading

• NIST Glossary: Software Development Life Cycle
• NIST SP 800-218: Secure Software Development Framework (SSDF)
• OWASP Developer Guide: Secure Development and Integration
• Manifesto for Agile Software Development
• The Scrum Guide
• The Kanban Guide