Software Development Life Cycle

The software development life cycle (SDLC) is the continuous work of discovering, building, releasing, operating, and improving software. The activities matter more than whether an organization labels its process Agile, DevOps, iterative, or something else.

The Core Feedback Loop

discover → define → design → implement → verify → release → operate
    ↑                                                        │
    └──────────────── learn and adjust ──────────────────────┘

These activities overlap. Small batches move through the loop faster, expose mistakes earlier, and reduce the amount at risk.

1. Discover the Problem

Understand users, outcomes, current behavior, constraints, risks, and alternatives—including doing nothing.

Useful evidence includes interviews, support cases, production data, prototypes, and observation of real workflows. Separate facts from assumptions and assign the riskiest assumptions an experiment.

Deliverable: a concise problem statement with target users, desired outcome, evidence, constraints, and success measure.

2. Define the Change

Turn the problem into testable behavior:

• primary and failure workflows;
• business rules and invariants;
• acceptance examples;
• data, privacy, security, and accessibility needs;
• operational and migration requirements;
• explicit exclusions.

Good requirements describe observable outcomes without prematurely fixing the implementation.

Given an authenticated account owner
When they revoke a session
Then that session can no longer access protected resources
And other active sessions remain valid

Trace important requirements to tests, monitoring, or another verification method. Avoid large specification documents that are not kept current.

3. Plan the Smallest Safe Increment

Split work vertically so each increment produces a user-visible or operationally verifiable outcome. Prioritize by value, risk, dependency, and learning—not by component convenience.

For each increment define:

• owner and reviewers;
• dependencies and rollout order;
• acceptance and release criteria;
• data migration and backward compatibility;
• observability and support changes;
• rollback or roll-forward plan.

Estimates express uncertainty, not promises. Re-plan when evidence changes.

4. Design

Choose the simplest design that meets current requirements. Record consequential, hard-to-reverse decisions and their trade-offs. Threat-model trust boundaries, model data ownership and retention, and trace normal, overload, failure, and recovery paths.

Validate expensive uncertainty with a focused prototype, benchmark, or compatibility test rather than building a speculative framework. See Software Architecture.

5. Implement

Keep changes small and reviewable. Use version control, automated formatting and static checks, tests at appropriate boundaries, and reproducible builds. Review for correctness, security, operability, maintainability, and whether the change should be smaller.

Integrate frequently. Long-lived branches delay feedback and make integration risk accumulate.

AI-assisted code remains ordinary code: its author owns understanding, provenance, security, testing, review, and maintenance. Never place secrets or restricted data into an unapproved tool.

6. Verify

Verification answers both:

• Did we build the specified behavior correctly?
• Does the behavior solve the user's problem safely?

Combine automated tests, review, exploratory testing, security checks, accessibility checks, performance experiments, and stakeholder validation according to risk. A passing suite is evidence, not proof.

See Software Testing and Authentication and Security.

7. Release

A release process should be repeatable and observable:

1. create one immutable artifact;
2. verify it and its provenance;
3. apply compatible configuration and migrations;
4. deploy progressively when risk warrants it;
5. observe technical and user outcomes;
6. continue, roll forward, or roll back by explicit criteria.

Separate deployment from feature exposure when independent control reduces risk. Feature flags need owners, expiry dates, safe defaults, and cleanup; otherwise they become permanent branches in production.

Database changes should support mixed application versions during rolling deployment. Prefer expand, migrate, then contract over a breaking one-step change.

8. Operate and Learn

Define service-level objectives for important user journeys, alert on actionable symptoms, and maintain runbooks for known failure modes. Test backups and restoration rather than assuming they work.

After incidents, focus on contributing conditions and system improvements instead of a single human “root cause.” Track actions to completion and verify that they reduce recurrence or impact.

Retire unused code, flags, data, infrastructure, and documentation. Decommissioning is part of delivery.

Choosing a Delivery Model

Process should match uncertainty, risk, and feedback cost.

Context	Useful emphasis	Risk to manage
Stable, regulated specification	Planned evidence and formal approvals	Late discovery of wrong assumptions
Uncertain product need	Short experiments and incremental delivery	Local optimization without product direction
Safety-critical system	Hazard analysis, traceability, independent verification	Ceremony replacing engineering judgment
Legacy replacement	Strangler increments and compatibility	Permanent dual systems
Platform or infrastructure	Consumer feedback and self-service paths	Building features nobody adopts

Waterfall describes mostly sequential phases; iterative and incremental methods revisit them in small batches. The V-model pairs development artifacts with corresponding verification. Spiral development organizes work around repeated risk reduction. These are planning shapes, not substitutes for feedback and engineering discipline.

Quality and Security Throughout

Do not defer all quality work to a final gate. Examples:

• discovery: privacy impact and misuse cases;
• requirements: security, accessibility, and recovery acceptance criteria;
• design: threat modeling and failure analysis;
• implementation: review, static checks, and dependency control;
• verification: risk-based functional and non-functional tests;
• release: artifact integrity and least-privilege deployment;
• operations: monitoring, patching, incident response, and recovery exercises.

Independent review remains valuable for high-risk changes even when checks move earlier.

Measuring the System of Work

Use metrics to find constraints and evaluate improvements, not rank individuals.

Measure a balanced set:

• user outcome and adoption;
• work-item lead time and age;
• deployment throughput and stability;
• escaped defects and incident impact;
• reliability against service objectives;
• security and dependency remediation time;
• developer friction and repeated manual work.

DORA's current delivery metrics are a useful system-level reference and evolve with its research. Compare one service over time in context; cross-team league tables invite gaming.

Definition of Done

A lightweight definition of done might require:

• acceptance behavior verified;
• code reviewed and automated checks passing;
• security, privacy, and accessibility risks addressed;
• compatibility and migrations tested;
• telemetry and alerts updated;
• deployment and recovery path ready;
• documentation and support material updated;
• temporary flags or follow-ups owned and dated.

Adjust rigor to risk. A copy change and a payment-ledger migration should not share identical ceremony.

Common Failure Modes

• output measured instead of user outcome;
• large batches and long-lived branches;
• requirements handed off without feedback;
• testing or security left until the end;
• environments that differ materially from production;
• manual deployment steps known by one person;
• metrics used as individual targets;
• retrospectives without owned actions;
• permanent prototypes, flags, and compatibility paths;
• process added after every incident but never removed.

Review Checklist

• Is the user problem supported by evidence?
• What assumption could invalidate the work?
• Is this the smallest independently valuable increment?
• Are acceptance and operational outcomes observable?
• Can mixed versions coexist during release?
• Are security, privacy, accessibility, and recovery addressed by risk?
• Is rollback or roll-forward safe and rehearsed where necessary?
• Will production feedback change the next decision?
• What temporary mechanism must later be removed?

An effective lifecycle shortens the time between an idea, trustworthy evidence, and a safe correction.