What Is the SDLC? A Software System's Life from Idea to Retirement

Version note: This post is based on the 12207:2026 software life cycle standard published in April 2026 and on the 2024 SWEBOK (Software Engineering Body of Knowledge) Guide v4.0.

Guess First

The Bookstore team is asked to build an "order returns" feature: a customer can return a delivered order within 14 days. When the Product Owner explains it, she says "it's two sprints of work, we code it, test it and ship it." The team pictures the same thing: one endpoint, one Angular form, a few tests.

Now guess: three years after this feature reaches production, how much of the total effort spent on it will have been spent in those first two sprints? And if someone wants to remove the feature one day, who has that plan in their head today?

You will answer this with your own team's data at the end of the post. But the intuitive answer is almost always wrong: the first delivery is the shortest and most visible slice of a software system's life. What we call the SDLC (Software Development Life Cycle) is simply the name for looking at the whole of that life.

What Is the SDLC? The Difference Between a Phase and a Model

The SDLC is the full set of phases a software system goes through, from being born as an idea to being retired. Two concepts in this definition get mixed up all the time, and the rest of the series builds on telling them apart:

• Phase: a kind of work that has to be done. Understanding requirements, designing, coding, testing, deploying, operating, retiring.
• Model: the decision about the order in which these phases happen, how many times, and how much they overlap. Waterfall, the V-Model, Spiral, iterative models, Agile approaches such as Scrum and Kanban, and the DevOps loop are all models.

This distinction matters, because the sentence "we are Agile, we don't have a design phase" is a category error. A team doing Scrum designs too; it just does it in small pieces every sprint instead of once at the start of the project for six months. A team doing Waterfall tests too; it just puts testing at the end as one big block. Every model has the phases. What changes is their order, how often they repeat, and how long it takes for feedback to arrive.

Seven Phases and the Output of Each

Sources list the phases with different counts and names; some separate analysis from requirements, some fold deployment into operations. This series uses a seven-phase frame, because it matches the split a developer sees in daily work:

Every phase has a tangible output (an artifact), and a phase counts as "done" only when that output exists. The output of requirements is a set of user stories with acceptance criteria, or a requirements document. The output of design is ADRs (Architecture Decision Records), an API (Application Programming Interface) contract and a database schema. Implementation produces reviewed pull requests and unit tests. The test phase produces a test report and a list of defects found. Deployment produces a versioned release artifact and release notes. Operations accumulates runbooks, dashboards and incident records. Retirement ends with a data archive and a sunset notice to users.

These outputs exist not for bureaucracy but because they are the input of the next phase. A tester who doesn't know the acceptance criteria doesn't know what to verify; an on-call engineer without a runbook rediscovers the fix from scratch at two in the morning. Whatever model you pick, if you skip a link in this chain you pay for it in the next phase.

A Feature's Journey: Order Returns

Let's follow Bookstore's returns feature phase by phase. In requirements the team asks the first question: "Do the 14 days count from the order date or the delivery date?" The answer is the delivery date, which we learn from the delivery event sent by the shipping company. That one sentence creates a dependency on an event coming from Shipping during design. Writing user stories and acceptance criteria like this is the subject of the upcoming Requirements Analysis series.

Design produces two decisions: a return request will be stored as a separate ReturnRequest record, and the refund will be sent to the Payment service as an asynchronous message. The second decision goes into an ADR, because six months later someone will certainly ask "why didn't we call it synchronously?" The details of writing ADRs are in the Architecture Decisions series post "Writing ADRs".

Implementation and test are the parts the team knows best: the endpoint, the Angular form, unit and integration tests. Deployment brings the first surprise: the consumer that processes the refund message needs a new queue, and the team doesn't have the permission to create that queue in production. The work waits on a request to the platform team. Operations brings the second surprise: in the first month nobody can see what share of return requests turned into refunds, because nobody defined a metric for it.

What the two surprises have in common is that they fall outside the work imagined as "coding + testing". One was a deployment requirement, the other an operations requirement, and both could have been discussed at the very beginning.

Maintenance: The Longest Phase of the Life Cycle

The day the feature reaches production, the longest phase of the life cycle begins. The maintenance standard 14764 and SWEBOK basically split maintenance work into four types: corrective (fixing a defect that was found), adaptive (adapting to a changing environment: a new .NET version, the shipping company changing its API), perfective (improving performance and usability) and preventive (preventing problems that haven't failed yet but will, paying down technical debt).

The first year of maintenance for Bookstore's returns feature might look like this: the shipping company changes the format of its delivery event (adaptive), the return window is extended to 30 days for the New Year campaign (perfective), requests arriving in the last hours of day 14 are rejected because of a time zone bug (corrective), and the system moves to the next LTS (Long-Term Support) release of .NET (adaptive). None of this was in the plan for the first two sprints.

A frequently repeated estimate in the literature is that more than half of a system's lifetime cost is spent after its first delivery. The ratio varies a lot by system and by source; don't use any single percentage as hard fact. But the direction doesn't change: in a long-lived system the first delivery is a small part of the total effort. That is why the time spent on readable code, tests and documentation in the first delivery is not a luxury but a down payment on the maintenance phase.

Retirement: The Last Phase Nobody Plans

Every piece of software is eventually removed. Removing it is not as simple as "archive the repo". Imagine Bookstore wants to remove its old /api/v1/returns endpoint. First you need to know who calls it; a two-year-old version of the mobile app might still use it. Then you tell the callers: the Deprecation and Sunset HTTP (Hypertext Transfer Protocol) response headers (RFC (Request for Comments) 9745 and RFC 8594) offer a standardized way to do this. Then comes the data: return records may have to be kept for years because of tax and consumer law, but personal data must be deleted or anonymized once its retention period ends under KVKK (Kişisel Verilerin Korunması Kanunu, Turkey's personal data protection law).

The life cycle standard 12207 defines this phase as a separate technical process called "disposal". That is a sign it deserves to be taken seriously: retirement is the one phase most teams never plan but always live through.

What Does the Standard Say? The Structure of 12207:2026

The international standard for the software life cycle is ISO/IEC/IEEE 12207, published jointly by ISO (International Organization for Standardization), IEC (International Electrotechnical Commission) and IEEE (Institute of Electrical and Electronics Engineers). Its second edition came out in April 2026 and replaced the 2017 edition. The standard groups its processes into four groups:

The most important thing to know about the standard is this: 12207 does not impose a life cycle model. It says which processes should exist and what they are for; it leaves it to you whether they are carried out with Waterfall, Scrum or DevOps. So the sentence "the standard requires us to do Waterfall" is usually a decision of the organization applying the standard, not of the standard itself. The list of changes in the 2026 edition compared to 2017 is not published in free sources, so here we only covered the structure.

The SWEBOK Guide v4.0, on the other hand, is not a standard but a guide that maps the knowledge areas of software engineering. In the fourth version from 2024 the number of knowledge areas rose to 18; the new ones include Software Architecture, Software Security and Software Engineering Operations. Operations becoming its own knowledge area points in the same direction as this post's main claim: software engineering doesn't end at deployment.

Production Notes

The cheapest way to make the life cycle visible in a real team is to ask for every phase's output for every feature. To do that, the Bookstore team added three items to its Definition of Done: the new endpoint has an owner and a metric to watch, the alert threshold is written in the runbook, and if it is removed, which data is kept for how long is known. The Definition of Done itself is covered in detail in the Scrum series post "The Increment and the Definition of Done".

The second practice is to connect feedback from operations to requirements. If the "action" items in a postmortem written after an incident never make it into the backlog, the green arrow in the figure is broken: the loop turns into a chain, and the same incident happens again.

The third is to book cost to the right phase. If the team only counts new features, maintenance work becomes invisible and the question "why did we slow down?" never gets answered. Tagging maintenance work separately on the board, combined with the flow metrics described in the Kanban series, makes that invisible work measurable.

Common Pitfalls

The most common pitfall is thinking the SDLC is just "coding + testing". A feature planned with that view brings back deployment permissions, monitoring, data retention and removal as unplanned work. That work doesn't disappear; it just shows up at the most expensive moment.

The second pitfall is confusing phase and model. A team that says "we dropped Waterfall, we don't do design anymore" hasn't dropped design, it has only made it invisible. Decisions are still made, but buried in the code and undocumented.

The third is forgetting retirement. Unused endpoints stay open for years without being shut down; each one is maintenance cost and attack surface. Some of the vulnerabilities covered in the Web Security (OWASP Top 10) series live exactly on these forgotten surfaces.

The fourth is reading standards as a justification for a model. 12207 says which processes are needed, not their order.

A Small Experiment

★☆☆ Take the last feature your team finished and write down the output of each of the seven phases. Which phase had no output, or had one that existed only in someone's head?

★★☆ Export the last three months of closed work items from your board and label each one as either a "new feature" or one of the maintenance types (corrective, adaptive, perfective, preventive). That ratio is the answer to the question at the start of this post for your team.

★★★ Pick the least used endpoint in your system and write a retirement plan for it: who calls it, how they will be notified, which data is kept for how long, and on which date it will be shut down.

We separated phases from models. In the next post we go back to the paper that first lined these phases up in a single diagram, Winston Royce's 1970 text, and see that what we know as "Waterfall" is something Royce didn't actually recommend.