Software Development Life Cycle (SDLC): Phases, Models, and What Actually Happens on Real Projects

Most SDLC articles describe a clean, sequential process. Real projects rarely work that way. Requirements shift mid-sprint, compliance deadlines compress testing windows, and legacy integrations break assumptions made in the design phase. This article covers the SDLC phases and models as they function in practice – including the edge cases that textbooks skip.

What Is the Software Development Life Cycle?

The software development life cycle (SDLC) is a structured framework that guides a software project from initial concept through deployment and ongoing maintenance. It divides work into distinct, ordered phases – each with defined inputs, outputs, and responsible roles. The goal is predictability: delivering software that meets requirements, stays within budget, and passes quality standards.

The term has been in use since the 1960s, originating in mainframe-era system engineering. Today it applies equally to cloud-native microservices, mobile apps, and enterprise EHR systems. What changed is not the concept – it is how teams sequence and repeat the phases. That is where SDLC models come in, and where teams make consequential decisions early.

Understanding the SDLC is essential for anyone who works across the delivery chain – not just developers. Business analysts, QA engineers, project managers, and product owners all have defined roles in specific phases. Misunderstanding where you fit creates gaps in handoffs, and gaps in handoffs create defects downstream.

The 7 Phases of the Software Development Life Cycle

Different sources list five, six, or seven phases depending on how granularly they break down planning and requirements. The seven-phase model below is standard for mid-to-large enterprise projects. Smaller teams often collapse phases – but collapsing does not mean skipping the work.

1. Planning

Planning defines project scope, objectives, resource requirements, timeline, and initial risk assessment. It answers one question: is this worth building? Feasibility analysis – technical, financial, and operational – happens here. On regulated projects, this phase also identifies compliance obligations: HIPAA, SOX, PCI-DSS, or jurisdiction-specific mandates.

A poorly scoped planning phase is one of the most reliable predictors of project failure. As Karl Wiegers notes in Software Requirements, incomplete scope at the outset creates a cascade of rework costs – each phase compounds the original gap. Get the boundaries wrong here and you are negotiating scope change requests for the rest of the project.

2. Requirements Analysis

This is where business analysts do the heaviest lifting. Requirements are elicited from stakeholders, documented, prioritized, and validated. BABOK v3 distinguishes between business requirements (what the organization needs), stakeholder requirements (what specific groups need), and solution requirements (functional and non-functional specifications for the system).

For anyone looking at the business analyst role in detail, requirements analysis is the phase where BA impact is highest and most measurable. Ambiguous requirements at this stage are not just an inconvenience – they are the root cause of most budget overruns in enterprise software projects.

In healthcare IT, requirements must trace back to clinical workflows. A payer-provider integration project that maps HL7 FHIR R4 message specifications against existing Epic ADT feeds in this phase catches interface mismatches before a single line of code is written. That traceability also supports audit readiness.

3. System Design

Design translates requirements into architecture. High-level design addresses system components, technology stack, database schema, and integration points. Low-level design goes into module specifications, API contracts, and UI/UX wireframes. Both must be reviewed and signed off before development starts – at least in plan-driven models.

Security architecture belongs here, not in testing. Retrofitting access controls or encryption into a deployed system is expensive and often incomplete. DevSecOps teams embed security decisions into design as a standard discipline – not as a compliance checkbox added at the end.

4. Development (Implementation)

Developers write code against the approved design and requirements. This phase also includes code review, version control, and unit testing. In Agile delivery, development happens in iterations – typically two-week sprints under Scrum. In Waterfall, it follows design completion and precedes formal testing as a discrete phase.

One common edge case: development teams that begin coding before requirements are formally signed off. This happens under schedule pressure. The short-term gain of a few sprint days frequently produces months of rework when the business changes direction – which it will.

5. Testing and QA

Testing validates that the software meets requirements and does not introduce new defects. The Software Testing Life Cycle (STLC) runs parallel to and interleaved with the SDLC in modern delivery models. In traditional Waterfall, it is a distinct downstream phase. In Agile, QA is embedded in each sprint.

Testing types across this phase include functional, regression, integration, performance, security, and user acceptance testing (UAT). For a breakdown of where each fits, see the types of software testing guide. The role of QA in the development process extends beyond bug-finding – it is a quality gate that protects release confidence.

6. Deployment

Deployment moves the validated build into the production environment. This includes release planning, environment provisioning, migration scripts, rollback procedures, and go-live coordination. In CI/CD pipelines, deployment is automated and frequent. In regulated industries, it requires formal change management – a change advisory board (CAB) review, deployment window approval, and documented evidence for audit trails.

The edge case here is “big bang” deployments in enterprise EHR environments – where an entire hospital system cuts over to a new platform in a single weekend. These are high-risk, meticulously planned, and almost always run over the allotted window. Contingency planning is not optional.

7. Maintenance and Operations

Post-deployment, the system enters ongoing maintenance: bug fixes, performance monitoring, security patches, and feature enhancements. In healthcare IT, maintenance includes regulatory update cycles – ICD-10 annual code updates, HIPAA rule amendments, and CMS interoperability mandates. Systems that lack a structured maintenance process accumulate technical debt rapidly.

This phase also feeds back into planning. Production telemetry, user feedback, and support ticket patterns inform the next development cycle. In mature organizations, maintenance and the beginning of the next SDLC iteration overlap continuously.

SDLC Models Compared: Choosing the Right Framework

The phases above describe what happens in an SDLC. The model determines how and when those phases execute. Model selection is not a theoretical decision – it has direct consequences for team structure, release cadence, compliance posture, and failure modes.

No single model is universally superior. The Agile vs. Waterfall debate loses meaning when compliance requirements dictate documentation standards that pure Agile does not naturally produce. Most enterprise teams run hybrid approaches – Agile delivery cadence inside a Waterfall-adjacent governance structure. SAFe formalizes exactly that pattern for large programs.

Key Roles in the Software Development Life Cycle

SDLC phases do not execute themselves. Each phase has primary owners and supporting contributors. Confusion about role boundaries causes the most common project failure patterns – requirements that nobody owns, testing that starts too late, and deployments nobody signed off on.

In Agile delivery under SAFe, the Product Owner carries formal accountability for backlog content and sprint acceptance. In a traditional Waterfall project, that function is typically distributed across a BA, a project sponsor, and a steering committee. Neither structure is wrong – but the accountability gaps in each model are predictable and manageable if you map them explicitly at project initiation.

SDLC in Healthcare IT: A Practical Scenario

Consider a regional health plan implementing a payer-provider data exchange to meet the CMS Interoperability and Patient Access Rule. The project requires exposing FHIR R4 APIs to third-party app developers while maintaining HIPAA-compliant data access controls.

In the planning phase, the team identifies three hard constraints: the CMS compliance deadline, existing legacy claims data in a non-FHIR format, and a contractual restriction on sharing specific diagnosis codes with certain downstream apps. These constraints reshape the entire project scope before any design begins.

During requirements analysis, the BA works with clinical informatics, legal, and IT security to define data access rules, consent management flows, and API rate limits. The FHIR resource mapping must align with HL7 FHIR R4 specifications – not an approximation of them. Any deviation becomes a compliance gap that will surface in the CMS audit.

The team chooses a hybrid model: SAFe for program-level coordination across four development teams, with Waterfall-style gate reviews at the end of each Program Increment to satisfy the compliance documentation requirement. The architecture is designed in the first PI; the FHIR endpoint development and integration testing run across PIs two and three; UAT and security penetration testing fill PI four.

What the textbook version omits: the legacy claims system cannot export ICD-10 codes in a FHIR Condition resource format without a middleware translation layer that was not scoped in PI one. That gap surfaces in integration testing and costs three weeks of PI two. The lesson is not that SDLC failed – it is that the SDLC’s requirements phase did not go deep enough on the source system data model.

SDLC and Agile: Not Mutually Exclusive

A persistent misconception is that Agile replaces the SDLC. It does not. Agile is a delivery model that operates within the SDLC. Planning still happens – it is continuous rather than front-loaded. Requirements are still gathered – through user stories, acceptance criteria, and sprint demos rather than a single BRD. Design still occurs – it is incremental and emerges across iterations.

The Scrum framework structures Agile delivery into time-boxed sprints with defined ceremonies: sprint planning, daily standups, sprint review, and retrospective. These ceremonies align to SDLC phases but compress and repeat them. A sprint is a mini-SDLC – planning, design, build, test, and deploy in two weeks rather than six months.

The practical tension arises in regulated environments where Agile’s “working software over comprehensive documentation” principle conflicts with audit requirements. An FDA submission or HIPAA risk analysis needs traceable documentation. Teams that skip this discipline in the name of Agile velocity create compliance exposure that is expensive and difficult to remediate after the fact.

STLC as a Parallel Framework

The Software Testing Life Cycle mirrors the SDLC structure but focuses specifically on testing activities. It defines its own phases – test planning, test case design, environment setup, execution, defect tracking, and closure. In Waterfall, STLC follows development. In Agile, it runs alongside each sprint. The relationship is not sequential – it is overlapping and iterative.

QA teams that understand the full SDLC context write better test plans. A tester who knows which requirements were deprioritized in sprint planning, or which architectural decisions were deferred, targets their testing effort more precisely. Coverage gaps in testing almost always trace back to information gaps between development and QA earlier in the cycle.

Where the SDLC Breaks Down – and Why

The SDLC is a framework, not a guarantee. Several failure patterns appear consistently across industries and project types.

Skipped feasibility analysis. Teams under pressure to start development skip the feasibility check. The resulting mid-project pivot – when the team discovers the proposed architecture cannot support the required transaction volume – costs more than the feasibility analysis would have.

Requirements that are not really requirements. A document called a BRD that contains vague process descriptions and aspirational goals is not a requirements specification. Wiegers’ requirement quality criteria – complete, consistent, feasible, necessary, unambiguous, verifiable – are a practical checklist for distinguishing real requirements from intent statements.

Testing as an afterthought. When testing is treated as the last sequential phase and compressed under schedule pressure, defects ship to production. The V-model exists specifically to prevent this by pairing each development artifact with a corresponding test artifact from the beginning.

Maintenance underfunded at project close. Budget allocations routinely underestimate post-deployment costs. In healthcare IT, mandatory regulatory update cycles – annual ICD-10 revisions, CMS rule changes, HL7 version updates – make maintenance a predictable and significant recurring cost. Projects that treat deployment as the finish line create systems that fall into technical debt within 18 months.

Selecting the Right SDLC Model for Your Project

Model selection depends on four primary variables: requirement stability, regulatory environment, team size and maturity, and tolerance for late-stage changes.

If requirements are well-defined and unlikely to change – a regulated medical device system or a fixed-scope government contract – Waterfall or V-model provides the documentation rigor and phase gates those environments require. If requirements will evolve through user feedback – a patient-facing mobile app or a new provider portal – Agile with strong product ownership produces better outcomes.

For large enterprise programs with multiple interdependent teams, neither pure Waterfall nor pure Scrum scales well without coordination overhead. SAFe addresses this through Program Increment planning – a structured quarterly cadence that aligns teams across a shared delivery roadmap while preserving sprint-level Agile execution at the team level.

The honest answer is that most projects of any complexity end up running a hybrid. The decision is not which model to follow perfectly – it is which model’s governance structure to anchor to, and where to intentionally deviate from it.

Authoritative External References

• IIBA BABOK v3 – Business Analysis Body of Knowledge – the standard reference for requirements elicitation, analysis, and management practices
• CMS Interoperability and Patient Access Rule – governing FHIR API requirements for payers and the compliance timeline referenced in the healthcare scenario above