Phases

The classical SDLC phases are useful as a vocabulary, even when the methodology is iterative. In an iterative team, each iteration touches several phases; in a waterfall team, each phase happens once.

Discovery

Understand the problem before designing a solution. Most failed projects failed in discovery, building the wrong thing well. The deliverable is a written problem statement the team agrees on; the activities below are how teams get there.

• User research, interviews, surveys, observation.

• Stakeholder interviews, what the business wants and why.

• Competitive analysis, what already exists.

• Constraints, legal, technical, financial, time.

Output: a written problem statement that the team agrees on. Most failed projects failed in discovery, building the wrong thing well.

Requirements

Translate the understood problem into specific, testable requirements. The deliverable is something the team and stakeholders can both sign off on; the formats below are different tools for different audiences and project types.

• Functional, what the system does (user can log in with email + password).

• Non-functional, how it does it (99.9% uptime, p95 < 200 ms, GDPR compliant).

• Acceptance criteria, how to know each requirement is met.

Common formats.

• User stories, “As a <user>, I want <X> so that <Y>”.

• Use cases, actors, scenarios, alternative flows.

• Specifications, formal documents, common in regulated work.

• Design documents / RFCs, engineering-focused.

The deliverable is something the team and the stakeholders can both sign off on.

Design

Architecture, data models, interfaces, UI/UX. Decisions at this phase are the most expensive to revisit; write them down as ADRs or RFCs while they’re still cheap. The categories below cover the standard design surface.

• Architecture, Architecture covers this in depth: styles, communication, reliability, scalability.

• Data design, entities, relationships, constraints, evolution strategy.

• API design, REST / RPC / GraphQL contract; versioning strategy.

• UI / UX, wireframes, mockups, prototypes, accessibility plan.

• Threat modeling, Operations.

Decisions at this phase are the most expensive to revisit. Write them down as ADRs (Architecture Decision Records) or RFCs.

Implementation

Code, with all the engineering practices. The bulk of the calendar, and ironically often the easiest phase if discovery, requirements, and design were done well. The links below cover each practice in depth.

• Source control, Git.

• Code review, Practices.

• CI, CI / CD.

• Test-as-you-go, Testing.

• Style and lint enforcement, automated.

The bulk of the calendar; ironically often the easiest phase if the earlier phases were done well.

Testing

Distinct phase in waterfall; continuous and overlapping with implementation in modern flows. See Testing for the test pyramid and types. The activities below are the ones that happen at the phase boundary even in iterative teams, the final integration, end-to-end, UAT, performance, and accessibility checks before release.

• Integration testing, across services, with real or production-like dependencies.

• End-to-end testing, whole-system flows.

• User acceptance testing (UAT), the customer / stakeholder validates that the requirements are met.

• Performance testing, load, stress, soak, spike.

• Security testing, Operations.

• Accessibility testing, with assistive tech, not just linters.

Deployment

Get the change in front of users. The deployment story is more than a build artifact; it’s the strategy, the migration plan, the rollback, and the communication. See CI / CD for mechanics; the items below are the per-deployment checklist.

• Build artifact, container image, binary, package.

• Promotion through environments (dev → staging → prod).

• Strategy, recreate, rolling, blue/green, canary, feature-flag rollout.

• Migrations, forward-compatible; expand-and-contract.

• Rollback plan, clear, fast, exercised.

• Communication, changelog, release notes, customer-facing notice if needed.

See CI / CD for the mechanics.

Operation / Maintenance

Most of a system’s life is here. Operation and maintenance need the same investment as the building phases (often more) because every other engineering decision in the lifecycle ends up paid for during this phase, in incidents, cost, or rework.

• Monitoring, Observability.

• Incident response, incident-response (operational version is similar).

• Backups, restores, drills.

• Cost management.

• Patching and dependency updates.

• User support and feedback channels.

• Documentation upkeep, runbooks, on-call guides.

This phase needs the same investment as building, often more.

Decommissioning

Eventually, software retires. Treat decommissioning as a project: forgotten “still on” services are how breaches happen, because a service nobody actively maintains accumulates unpatched dependencies, expired credentials, and exposure nobody is monitoring.

• User communication with timeline.

• Data migration / export for affected users.

• Service shutdown in stages: feature freeze → read-only → off.

• Dependency cleanup, DNS, certificates, IAM, billing.

• Archival of source code, runbooks, postmortems.

• Account deletion, finalize per regulatory obligations.

Treat decommissioning as a project. Forgotten “still on” services are how breaches happen.

Across All Phases

Some activities span the whole lifecycle and don’t fit a single phase. They run continuously, get neglected easily, and pay back in lower coordination cost when something does go wrong. Treat them as background processes the team always invests in.

• Documentation, written as decisions are made; fresh.

• Risk management, known unknowns, mitigations.

• Stakeholder updates, regular cadence, written.

• Retrospectives, not just sprint retros; project / quarter / year.

• Knowledge transfer, nothing should require a single person to recover.