SDLC Phases and Examples - One Project Through Every Phase

SDLC stands for software development life cycle. It's the sequence of phases a piece of software goes through, from the first conversation about building it to the day someone switches it off.

Some people expand the S as system. The system development life cycle is the wider frame, taking in the hardware and the people around the code. The software development life cycle is the part that produces the code. The phases are the same, and this post treats the two as one.

The project that runs through every phase below is an invoicing tool for a plumbing firm with a dozen staff, whose office manager builds invoices from a Word template and chases late payment by phone. It's made up. The deliverables are ones I've watched real teams produce.

The seven SDLC phases

The seven SDLC phases are planning, requirements, design, development, testing, deployment and maintenance, and each one produces a deliverable the next phase depends on.

In waterfall each phase happens once, in order. In agile the middle five repeat every sprint.

1. Planning phase

The SDLC planning phase decides whether the project is worth doing and what done looks like, before anyone writes a requirement.

As a Product Manager, this is probably the most important phase for you.

This is where you do your market research, conduct customer interviews, research your competition and conduct surveys.

The feedback that you gather helps you analyze your product market fit.

The invoicing tool at this phase

The PM hands over a one-page brief. It says why (payment takes too long), what is in scope (create, send and track invoices), what is out (payroll and accounting), a rough budget and one success measure: days from job complete to payment received.

The owner signs it or kills it.

What AI changes in this phase

Drafting got cheap.

Anthropic lists first drafts and briefs from meeting notes among Claude's uses. It also says Claude can write things that look correct and are wrong, so don't rely on it as a single source of truth.

Notion's own example prompt has its Agent draft quarterly OKRs from a goals page and Jira epics. Depending on the model you pick, the Agent may look only at the web and not at your workspace.

2. Requirements phase

In the SDLC requirements phase, the project brief becomes a written, agreed list of what the software must do.

Deciding the scope of your product feature list is not an easy task.

Defining what is in scope is as important as defining what is not in scope.

A business requirements document is the long form. A healthy product backlog of user stories with acceptance criteria is the form most teams actually work from.

The invoicing tool at this phase

The PM's output is a short requirements document and a ranked backlog. The top story reads "As the office manager I can turn a completed job into an invoice without retyping the customer's details", with acceptance criteria that the invoice carries the right tax rate and goes out as a PDF by email.

Engineers estimate the top stories. Anything nobody can estimate goes back for another conversation.

What AI changes in this phase

Atlassian's Jira docs say Rovo can generate a work item's description, with suggested prompts for user stories and acceptance criteria, and that the accuracy of AI output may vary. Turn off auto-applied changes so you review each suggestion before it lands.

I'd let a model draft the stories. The acceptance criteria still come from a conversation with the office manager, because a model has never watched her chase an invoice.

3. Design phase

The SDLC design phase settles how the software will be built, from the screens a user will see down to the data model and the services underneath.

The screens and flows are the Product Manager's responsibility, and you may work in tandem with UI/UX designers.

The data model and the architecture belong to the engineering lead.

In the design phase in SDLC, you need to be as visual as possible about your vision.

Use the design phase to really communicate your plan for the product to all your developers.

Remember, if you are following the waterfall model, then you get only one shot at the design phase.

The invoicing tool at this phase

The designer produces wireframes for the job list, the invoice editor and a payment status view, plus a clickable prototype the office manager has tried. The engineering lead writes a design document with a data model (customers, jobs, invoices, payments), an architecture sketch (web app, database, email service, payment provider) and the API contract.

What AI changes in this phase

Figma's First Draft turns a text prompt into editable wireframes in a couple of minutes. The help center says it can go awry outside common website and mobile patterns. It's now a legacy entry point on paid plans.

Figma Make builds a working prototype from a prompt or an existing design. Layers you copy out of a Make preview into Figma Design aren't automatically tied to your design system.

The engineering lead can start the architecture sketch from a text prompt in Lucidchart. Lucid says its AI is available to all users for now but may move behind a paid subscription.

None of these makes the data model decision. They make the first drawing cheap enough that you'll draw three.

4. Development phase

Development is where the design becomes working code, merged into the main line only after a pull request review.

You must constantly talk to your developers and clear roadblocks, if any.

The invoicing tool at this phase

Engineers merge reviewed code one story at a time, with unit tests written alongside and a working demo at the end of each sprint. The invoice editor ships behind a feature flag before the payment link does. The PM's deliverable is decisions made the same day and a backlog that stays ranked.

What AI changes in this phase

GitHub's Copilot cloud agent takes a task from an issue, works on a branch in its own GitHub Actions environment, and can open a pull request. GitHub's stated limits: one repository per run, one pull request per task, a hard 59-minute session and no pushes to your default branch.

Claude Code edits files and runs commands in your codebase, and Anthropic says you're responsible for reviewing what it proposes. Cursor's cloud agents and OpenAI's Codex run tasks in isolated environments and hand the result back.

A PM who can't read a pull request can't check any of it.

METR ran a randomized controlled trial of early-2025 AI tools with experienced open-source developers on their own repositories. With AI they took 19% longer, having expected to be 24% faster, and afterwards they still believed they had been 20% faster.

METR doesn't claim AI slows most developers, and it now marks those results as out of date. It believes AI tools probably sped developers up more in early 2026 than its early-2025 estimate showed, but calls its own data only very weak evidence for how much.

Measure it on your own team. A team that only asks how it felt has the vague success metric I describe in why AI projects fail.

5. Testing phase

Testing proves the software does what the requirements said, at unit, integration, end-to-end and user acceptance level.

The goal is bugs found before the customer finds them.

The invoicing tool at this phase

QA hands over a test plan, a passing automated suite, a defect list with severities and a sign-off. The suite is mostly unit tests on the tax and totals logic, some integration tests on the email and payment services, and a few end-to-end tests that run one job through to a paid invoice.

The office manager runs user acceptance testing on a week of real jobs and signs the sheet.

What AI changes in this phase

Copilot can write unit and integration tests, though GitHub warns they may not cover every scenario. Postman's Agent Mode writes post-response test scripts from plain language.

Playwright ships three test agents: a planner that writes a test plan, a generator that turns it into test files, and a healer that re-runs failing tests and repairs them until they pass or guardrails stop it. If the healer believes the feature is actually broken, it may output a skipped test.

I'd have someone read every test the healer skips before the release goes out.

6. Deployment phase

Deployment moves tested code into production and into users' hands, usually in stages, with a way back if something breaks.

The deployment phase in SDLC is something that is not heavy on the Product Manager.

Deploying frequently should not result in more bugs or defects.

The invoicing tool at this phase

Ops delivers a live system, release notes, a runbook for whoever is on call and a monitoring dashboard. The office manager goes first, behind a feature flag, then the rest of the firm, and the old Word template stays available for a fortnight.

What AI changes in this phase

Code review is the gate before deployment. GitHub's Copilot code review reads pull request code and offers fixes you can apply in a couple of clicks. It can miss problems or flag ones that don't exist, GitHub says, so it needs a human review alongside it.

DORA, a Google Cloud program, publishes five software delivery metrics for this phase: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.

Its finding is that speed and stability aren't tradeoffs. It also warns against setting the metrics as goals, because doing so makes teams more likely to game them.

7. Maintenance phase

Maintenance keeps the live system working after release and feeds what users ask for back into the next planning phase.

This is the longest phase and the one nobody budgets for. The invoicing tool will spend months in development and years in maintenance.

The invoicing tool at this phase

Ops sends out patches and a monthly report of errors and uptime. The PM writes the next backlog: recurring invoices and a reminder when an invoice goes overdue.

What AI changes in this phase

Sentry's Seer uses issue details, traces, logs and profiles to find a root cause, and its Autofix can propose a fix or open a pull request with it.

GitHub's Copilot Autofix layers a language model on code scanning alerts. Its docs warn it may suggest fabricated dependencies. Verify every dependency change before merging.

SDLC models with examples

An SDLC model is the order and rhythm in which a team runs the seven phases. Picking between agile, waterfall, iterative, big bang, spiral and the V-model mostly comes down to how expensive a late change is.

Agile Model

The SDLC Agile workflow is one of the most common SDLC models. In all of the various SDLC methodologies or SDLC types, agile occupies a special place.

The Agile Manifesto's principles welcome changing requirements, even late in development, and treat working software as the primary measure of progress.

Scrum, Kanban, SAFe and XP are all ways to run agile in practice.

DevOps is less a separate model than agile with the build, test and release steps automated, so the middle five phases repeat continuously.

Waterfall Model

The waterfall model is a linear series of steps.

So when to use waterfall model? Or what are the waterfall model advantages and disadvantages? A great waterfall model example is the manufacturing industry.

In the manufacturing of a physical product, requirements do not, and cannot, change every day.

The factory lines are defined for a preset process.

Change happens, but slower than in other models.

For example, take the manufacturing of a bicycle.

What model should be followed to manufacture a bicycle? Are requirements expected to change frequently on a weekly basis? The answer is clearly no. The requirements are not expected to change weekly for a bicycle.

Projects that use waterfall model are ones that are pretty stable and do not need frequent process changes.

In this model, the next step is dependent on the completion of the previous step. You cannot sneak in changes in between the processes.

You can only introduce changes after one full iteration has been completed, which is the main difference between Agile and Waterfall.

Barry Boehm credits the model to Winston Royce's 1970 paper. Royce never uses the word waterfall.

His diagram is captioned as implementation steps. Right under it he writes that he believes in the concept, but that this implementation is risky and invites failure. Problems found in testing can send the project back to the start, with up to a 100 percent overrun.

The one-pass version that now carries the waterfall name is the one he warned against.

Iterative Model

Of all the SDLC models, this one is the most distinctive.

It starts off with simpler builds, eventually taking on more complex builds.

You could say that this is a waterfall or an agile based model.

But, it is considered its own separate model.

The concept of building an MVP (minimum viable product) is the basis of this model.

What is the minimum viable product? What features need to go into the MVP? These questions are the first steps in this model.

People start off small and then progressively take on bigger and more complex features.

This model is great because it allows for a continuous feedback loop on the already developed features.

The team can account for that feedback before embarking on more complex features.

For the invoicing tool, iteration one creates and emails an invoice. Payment links come in iteration two, once the office manager has sent real invoices.

Big Bang Model

The big bang model is one that should probably never be used.

It is a "processless" process.

You put all your energy into building a product in one "big bang" approach.

Your final product may or may not be what the customer wants.

The Big Bang model is good for smaller projects that do not result in a significant impact.

As the name suggests, there is only one step in this process.

And that step is 'Bang'!

This approach is extremely risky and is almost never followed by bigger companies.

This approach is more common in startups or college projects.

In these projects, there is no budget, no planning and no research.

People think of an idea, and they just work on it and build the product.

College projects are a classic example.

Spiral Model

The spiral model is a combination of the waterfall and iterative model.

It gives the flexibility to the team to constantly adapt their processes as per their needs.

This model tells you to be flexible as a Product Manager.

Risk analysis is the key focus area during each stage of the Spiral model.

Boehm published the spiral model in 1986 and again in 1988. What sets it apart, he wrote, is that it's risk-driven rather than document-driven or code-driven.

The Spiral model consists of 4 stages -

• Development

• Evaluation

• Analysis

• Planning

The stages are tightly controlled as per the Waterfall model.

But, there are regular releases to take the benefits of smaller iterative cycles.

V-Model

The V-model is waterfall bent into a V, where each design phase on the way down has a matching test level on the way up, from requirements and acceptance tests at the top to detailed design and unit tests at the bottom.

The paired tests double as the audit trail.

Which model fits which project

I'd use waterfall or the V-model when the requirements are fixed by contract or regulation and a late change means a recall. Agile fits when the requirements will move and you can ship small pieces to real users. Iterative works once you can name a useful first version, and spiral when the risks deserve their own analysis each loop.

The invoicing tool is agile, with a first iteration that looks like a small waterfall because the brief, the requirements and the design all came before the first line of code.

SDLC tools by phase

SDLC tools are the software a team uses to run each phase. Most of the ones below ship an AI feature that drafts or fixes something for a human to review.

• Planning and requirements: Notion AI, ChatGPT or Claude for drafts, and Jira with Rovo for the backlog.

• Design: Figma and Lucidchart.

• Development: GitHub Copilot cloud agent, Claude Code, Cursor and Codex.

• Testing: Copilot test generation, Playwright test agents and Postman Agent Mode.

• Deployment: Copilot code review, with DORA's five metrics as the scorecard.

• Maintenance: Sentry Seer, PagerDuty AI and Copilot Autofix.

On price, treat the vendor's pricing page as the only source. GitHub's Copilot cloud agent uses Actions minutes and AI credits, and Cursor charges its cloud agents at API pricing for the model you pick, so budget for the metering as well as the seat.