Software Development Lifecycle (SDLC)

The software development lifecycle (SDLC) is the structured set of activities that transform stakeholder needs into running, maintained software. Whether your calendar says Waterfall or Scrum, the same kinds of work must occur: understand the problem, design a solution, build it, verify it, release it, and keep it healthy.

This page explains each phase in depth — why it exists, what artifacts it produces, what gates protect quality, and how feedback loops connect phases. Process model pages (Waterfall, Agile, Kanban, DevOps) show how teams sequence and overlap this work.

Informal "just build it" works until complexity, compliance, or team size make invisible work dangerous. An explicit lifecycle:

• Makes risk visible early (security, performance, integration) instead of at go-live.
• Creates shared artifacts so knowledge is not trapped in one developer's head.
• Defines gates — points where you decide proceed, iterate, or stop.
• Enables auditability when regulation demands traceability from requirement to release.
• Aligns architecture decisions with moments when evidence is available.

Purpose: decide what problem to solve, for whom, and what "done" means — before committing expensive design and code.

Activities include elicitation (interviews, observation, analytics), analysis (conflict resolution, MoSCoW), specification (user stories, use cases, FRD/PRD), and validation (walkthroughs, prototypes, acceptance criteria review).

Purpose: translate requirements into a structure that can be built, tested, operated, and evolved.

Design spans product UX, API contracts, data models, threat models, and software architecture. Architecture work here selects styles (monolith, hexagonal, services…), consistency models, and integration patterns — recorded in ADRs.

• High-level design: C4 Context/Container, major data stores, trust boundaries.
• Detailed design: module APIs, sequence flows for critical paths, schema drafts.
• Spikes: time-boxed experiments for unknown tech or performance risks.
• Reviews: architecture review board or lightweight peer ADR review.

Purpose: realize the design as working software in vertical slices that prove value and architecture together.

Prefer thin end-to-end slices over horizontal layer completion. Keep architecture fitness checks in CI so illegal dependencies fail the build. Pair implementation with contract tests when multiple teams share APIs.

• Coding standards, reviews, and trunk-based or short-lived branches.
• Feature flags for incomplete work on main.
• Continuous integration on every change.
• Documentation as code: OpenAPI, ADRs, runbooks updated in the same PR.

Purpose: reduce the risk that defects, regressions, or NFR breaches reach users.

Gates: critical path tests green; NFR tests for release-blocking attributes green; known defects triaged with severity. Shift-left means running cheap tests early and expensive ones when risk warrants.

Purpose: move verified software into production safely and reversibly.

• Automated pipelines: build → test → harden → deploy.
• Progressive delivery: canaries, blue/green, ring deployments.
• Feature flags and kill switches for rapid mitigation.
• Runbooks and change records where compliance requires them.
• Post-deploy verification: synthetic checks, SLO burn alerts.

Purpose: keep the system valuable: fix defects, adapt to change, improve NFRs, and evolve architecture with evidence.

Maintenance is not "lesser" engineering. It includes incident response, dependency upgrades, cost optimization, accessibility remediation, and planned extractions of modules into services when requirements demand it.

Linear diagrams lie. Real lifecycles are loops:

• Customer feedback → new/changed requirements.
• Test failures → design or implementation changes.
• Incidents → requirements for resilience and sometimes architecture changes.
• Metrics → prioritization (what to build next).

Gates are intentional pause points: requirements sign-off, design review, release readiness, go/no-go. Agile shortens gates; regulated Waterfall lengthens and formalizes them. Either way, gates without criteria become rubber stamps.

How to apply: map your team's current work onto these phases even if you use Scrum — ensure each kind of work has an owner and a quality bar. Why each phase exists: it is cheaper to discover error in that phase than in a later one. Requirements mistakes are cheapest to fix in requirements; architecture mistakes are cheapest to fix in design spikes; etc.

Next: Waterfall. Also Agile, DevOps, Requirements.