Software development life cycle

By Allen Jay Bercero

The software development life cycle (SDLC) is the structured sequence of stages a software product moves through, from the first idea, through building and releasing it, to maintaining and eventually retiring it.

Think of the SDLC as the map of what has to happen, in roughly what order, to turn a need into working software that stays working. It does not tell you how to move through those stages, how fast, or how much to do at once. That’s the job of a Software development process (the methodology). This is the single most useful distinction to get straight early, so it has its own callout below.

Don't confuse with

SDLC (the stages) vs Software development process / methodology (the approach). The SDLC is the list of stages: requirements, design, build, test, release, maintain. A methodology like Waterfall or Scrum is a strategy for moving through those stages. Waterfall does them once, in order; Scrum does a little of each, repeatedly. Same stages, different approach.

Also known as

SDLC · software development lifecycle · systems development life cycle · application development life cycle · (loosely, and imprecisely) “the development process”

The stages

There’s no single official list (you’ll see anywhere from 5 to 8 stages depending on the source) but this seven-stage version is the most complete and widely taught. Every shorter list is just some of these merged.

  1. Planning: Decide whether and why to build. Scope, budget, timeline, feasibility, high-level goals. Often includes a Feasibility study, a go/no-go assessment of whether the project is even worth doing (and not the same thing as a business plan).
  2. Requirements analysis: Decide what to build. Gather and document what the software must do (functional requirements) and the qualities it must have: speed, security, uptime (non-functional requirements). Output: a requirements document, or in agile, a Product backlog of user stories.
  3. Design: Decide how to build it. Architecture, data models, interfaces, and UI/UX artifacts along the fidelity spectrum: wireframesmockupsprototypes. Output: design specs and diagrams.
  4. Implementation: Actually write the code. Also called development, coding, or “build.”
  5. Testing: Verify the software does what it should and find defects: unit, integration, system, and user-acceptance testing (UAT). In modern practice this overlaps heavily with implementation rather than following it. The process view (verification vs validation, QA vs QC) is Verification and validation.
  6. Deployment: Release the software to users. Also called release, rollout, or “go-live.”
  7. Maintenance: Keep it running and improve it: bug fixes, security patches, and new features, until the product is finally retired (decommissioned).

In plain English

Figure out if you should build it → figure out what it should do → figure out how → build it → check it works → ship it → keep it alive. That loop, forever.

Why the stages aren’t as tidy as the list

The numbered list makes it look like a one-way conveyor belt. In reality:

  • Waterfall treats it almost literally as a one-way sequence (see Waterfall model).
  • Iterative and agile approaches run through all the stages in miniature, over and over: a Scrum team does requirements, design, build, and test inside every two-week Sprint. The stages still exist; they’re just interleaved instead of sequential.

So the SDLC is best understood as a checklist of concerns that always apply, not a rigid timeline.

Where it came from

The idea of formal life-cycle stages dates to the 1960s–70s as software projects grew too large to manage ad hoc. Early formalizations (including Winston Royce’s 1970 paper) were later crystallized into the Waterfall model. The stages themselves have outlived that model. Agile kept the stages and threw out the strict ordering.

See also

References