SDLC Phases Explained (and Where They Break Down)

A successful software project requires more than technical expertise. It demands a structured approach that balances risk, cost, and long-term value.

The Software Development Life Cycle (SDLC) provides a proven framework that helps organizations systematically plan, build, test, deploy, and maintain software solutions.

IBM argues that a defined SDLC leads to fewer project failures. Most of what goes wrong happens when a requirement moves from a business analyst to an architect, or when a build gets handed from an internal team to an outsourced one. The SDLC doesn’t fail because a team gets the number of SDLC phases wrong. It fails at the hand-offs between them.

This piece covers the SDLC phases, resolves why some sources count five phases and others count seven, and covers where hand-offs between phases actually break, plus what that means for choosing a model or a delivery partner.

What is the SDLC, and why does the phase count keep changing?

The software development life cycle (SDLC) is the process teams use to plan, design, build, test, deploy, and maintain software. It exists so that a team agrees on goals, risks, and quality bar before the expensive work starts.

A defined SDLC brings a few concrete benefits:

• Clearer collaboration between developers, testers, and product managers.
• Faster delivery, through earlier identification of slowdowns.
• Lower cost, through better risk management.
• More informative progress reporting for stakeholders.

The ISO/IEC/IEEE 12207 standard formalizes the reference standard for software life cycle processes, built specifically to bring structure to complex development environments and keep cross-functional teams aligned.

Most teams have their own versions of SDLC phases, ranging from five to seven. However, the work itself doesn’t change. Some teams merge requirements into design. Others fold maintenance back into deployment instead of treating it as its own final step. This article uses the seven-phase version, since it’s the most detailed and the most common one.

“SDLC” is sometimes used for “systems development life cycle,” a broader term covering hardware, people, and process alongside software. Throughout this piece, SDLC refers to the software-specific version only.

The 7 SDLC phases, one at a time

1. Planning

Planning names the problem the software needs to solve, sets goals, and checks whether the project is realistic given budget, time, and tech limits. Risks get named here before anyone spends real engineering time.

2. Requirements analysis

Requirements analysis turns planning-stage goals into specific, testable requirements. The team talks to stakeholders, writes down what the software needs to do, and produces the Software Requirements Specification (SRS). Every later phase gets measured against this document.

3. Design

Design turns the SRS into a technical blueprint: system architecture, database layout, and how the software fits with existing systems. This phase produces the Design Document Specification (DDS), which developers use as their main reference once coding starts.

4. Coding and implementation

Coding is where the DDS becomes working software. Developers write, review, and track code against the design. This is usually the longest phase in the SDLC and the one most often handed to an internal or outsourced team.

5. Testing and quality assurance

Testing checks whether the software does what the SRS said it should and whether it’s free of bugs. Teams typically run unit, integration, system, and user acceptance tests (UAT) before sign-off.

6. Deployment

Deployment moves tested software into production, where real users can reach it. Depending on the system, this can be one release or a slower, staged rollout with database changes along the way.

7. Maintenance

Maintenance is the open-ended phase: bug fixes, security patches, speed tuning, and folding user feedback into the next release. Unlike the other six phases, maintenance has no fixed end point. It runs until the software is retired or replaced.

Where SDLC phases actually break down

Most SDLC failures don’t happen inside a phase. They happen at the hand-off between two phases, usually because ownership of a decision isn’t clear.

A few hand-offs cause the most damage in practice:

• Requirements to Design. A requirement gets marked “signed off,” but the person signing off wasn’t in the room when the architecture decisions were made. Design starts against an assumption nobody actually validated.
• Design to Coding. A DDS is finalized, then a developer hits a real constraint, such as a legacy API limitation or a library version conflict, that wasn’t visible on paper. If nobody updates the DDS, the design document and the actual system quietly drift apart.
• Coding to Testing. Testing starts against a moving target because “code complete” doesn’t mean “requirements frozen,” especially when coding and testing phases overlap under time pressure.
• Internal team to outsourced team. This is the hand-off with the highest cost when it goes wrong. If the SRS and DDS were written for a team that sat in the planning room, they’re missing exactly the context a new team needs. That missing context gets rediscovered the expensive way, mid-build, instead of the cheap way, on paper.

None of this makes the phase list wrong. It makes the phase list necessary but not sufficient. The documents each phase produces have to be written well enough that someone who wasn’t in the room can pick up the work without re-deriving half the context.

Choosing an SDLC model: Waterfall, Agile, or a Hybrid

Waterfall

Waterfall runs the seven phases in order, one at a time. It gives clean documentation and predictable milestones, which is why it still shows up in regulated or fixed-scope projects. The trade-off is rigidity. Once a phase is “done,” going back to fix it costs real time and money.

Agile

Agile breaks the same phases into short, repeated cycles instead of one long sequential pass. Teams plan, design, build, and test in sprints, adjusting based on feedback after each cycle. It trades some upfront predictability for the ability to change direction without derailing the whole schedule.

V-Model

The V-Model pairs every development phase with a matching test phase, planned side by side from the start. It catches bugs earlier than Waterfall but keeps Waterfall’s rigidity, which makes it a fit for software with stable requirements and heavy testing needs.

Spiral

The Spiral model repeats the plan-design-build-test cycle in widening loops, putting risk analysis first at each pass. It suits large, uncertain projects where the cost of a late mistake justifies the extra process.

Most engineering organizations don’t run a textbook version of any single model. In practice, teams tend to front-load Waterfall-style rigor on Requirements and Design, the phases with the highest hand-off risk. Then, run Agile sprints through Coding and Testing, where iteration speed matters more than upfront certainty.

Security can’t be a phase. It has to run through all of them.

Treating security as a step that happens after Design or right before Deployment is the same hand-off gap described above, just with higher stakes. A DevSecOps approach folds security work into every phase instead of isolating it. Threat modeling starts at Design, not after the code is “done.”

Security bolted on late has two likely outcomes. Either a vulnerability ships, or deployment gets delayed while the team retrofits a fix that should have been designed in from the start. Either way, it’s a hand-off failure with a security label on it.

When to keep SDLC phases in-house vs. bring in a delivery partner

The phases safest to hand to an outside delivery partner are the ones with the clearest written deliverables. Coding against a locked DDS and running structured tests against a documented SRS are both self-verifying, since a partner team can check its own work against the document.

Requirements and Design are the riskiest phases to outsource, because so much of the real decision-making context lives in conversations, not documents. If a project plans to hand off Requirements or Design work, the SRS and DDS need to be written for a reader who wasn’t in the planning room. That’s a materially higher documentation bar than most internal teams default to.

Maintenance is a separate decision from hand-off risk entirely. It’s less about which phase to outsource and more about who owns the software for the years after launch.

Getting this decision right usually comes down to whether the documentation is actually good enough to hand off, not just whether the team trusts the partner. Eastgate’s product engineering practice picks up delivery starting at whichever phase the documentation can support, and helps tighten the SRS or DDS first when it can’t.

Final thoughts

The seven SDLC phases aren’t in dispute. Planning, requirements, design, coding, testing, deployment, and maintenance show up in some form in every real breakdown of the software development life cycle. What separates a smooth build from an expensive one is discipline at the hand-offs between those phases, not which model or phase count a team follows on paper.

Before the next project starts, the better question isn’t “which SDLC phases will we follow.” It’s “who owns each hand-off, and would a new person understand it from the documents alone?” The phase list can’t answer that. Only the team can.