9 Software Development Life Cycle (SDLC) Models

Fixing a problem after delivery can run 100 times what the same fix costs during requirements and design. That’s Boehm and Basili in IEEE Computer, and it’s the number your software development model controls.

A software development model sets how your project moves through the SDLC phases: plan, analyse, design, build, test, deploy, maintain. A model answers one question: do you run those phases once, loop them, or overlap them?

In this guide, we explain nine software development models, compare them on the dimensions that change your decision, and give a decision tree, not a factor list. As a custom software development company, we also cover what nobody writes about: how your contract quietly picks the model for you.

What Are Software Development Models?

Software development models are structured patterns for sequencing the SDLC phases. Each one decides whether phases run once or repeat, whether they overlap, and how much you commit to upfront. The phases stay constant; the model changes their order and rhythm.

What changes between projects is the shape of that journey. Run each phase once and never look back, and you’re using Waterfall. Repeat the whole set every fortnight, and you’re running an Agile model. Build a rough version first to learn what people actually want, and that’s Prototyping.

That’s all a model is: the shape of the path through the phases. It sits above the individual types of software development work, and below the contract that funds it.

What’s the Difference Between a Software Development Model and a Methodology?

A model describes how the SDLC phases are sequenced: once, in loops, or overlapping. A methodology describes how a team organizes its work inside that sequence. Waterfall and Spiral are models. Scrum, Kanban, and Extreme Programming are methodologies that run inside an Agile model.

This distinction gets flattened almost everywhere, and it’s the reason so many “types of software development models” lists feel like a jumble.

Atlassian frames the relationship well: within each model there’s scope for using project management structures such as Scrum and Kanban. The model is the container. The methodology sits inside it.

What Are the 9 Software Development Models?

Waterfall, V-Model, Incremental, Iterative, Spiral, Prototype, RAD, Big Bang, and Agile are the nine software development models that cover almost every project.

These models differ on five things that matter: how the phases flow, how much change they tolerate, when you first see working software, how much documentation they generate, and what each one is genuinely best for.

#1: Waterfall

Waterfall runs every SDLC phase once, in strict sequence, with a sign-off gate between each one. Requirements finish before design starts, and design finishes before coding starts. Nothing moves backward without a formal, priced change request.

The oldest model, and the one everyone loves to dismiss. It still wins in specific conditions.

How the SDLC Phases Flow in Waterfall

requirements → design → development → testing → deployment → maintenance, each fully complete before the next begins. The output of one phase becomes the input to the next.

• Best for: fixed-scope contracts, regulated builds, government work, and projects where an auditor will later ask you to trace a requirement to a test result.
• Main weakness: you see nothing working until late. Every assumption made in month one stays unchallenged until month six, and by then it’s expensive to be wrong.
• The failure mode: requirements theater. Everyone signs a 200-page specification nobody read, then treats the signature as genuine agreement. You get all of Waterfall’s rigidity and none of its clarity.

#2: V-Model

The V-Model is Waterfall with verification built in. Every development phase on the left of the “V” has a matching test phase on the right, from requirements down to module design. Test planning starts alongside requirements, not after coding.

Also called the Verification and Validation model. Think of it as Waterfall for people who can’t afford a defect to escape.

How the SDLC Phases Flow in V-Model

You descend the left side: business requirements, system design, high-level design, module design, and reach coding at the base, then climb the right side: unit, integration, system, and acceptance testing. Each right-side phase validates the left-side phase it pairs with. Requirements pair with acceptance testing; module design pairs with unit testing.

• Best for: medical devices, avionics, automotive, and anything where a certification body wants documented evidence that every requirement was verified.
• Main weakness: as rigid as Waterfall, plus more paperwork. Test artifacts are produced early and must be maintained if anything changes.
• The failure mode: treating the test plans as documents rather than as a design review. The V-Model’s real value is that writing the acceptance test exposes a vague requirement while it’s still cheap to fix.

#3: Incremental Model

The Incremental model splits the product into modules and takes each one through all phases separately. Module one is designed, built, tested, and delivered as a working piece. Then module two. Each increment adds finished functionality to what’s already live.

The keyword is finished. Each increment is production-ready when it ships.

How the SDLC Phases Flow in Incremental Model

The full phase set repeats per module. Requirements for module one: design, build, test, release. Then repeat for module two, which stacks on top of what’s already delivered.

• Best for: products that can genuinely launch partially — a platform where login and profiles are useful before payments exist.
• Main weakness: it needs good architecture upfront. Adding increments to a system that wasn’t designed to grow modularly produces an expensive rewrite around increment four.
• The failure mode: slicing by technical layer instead of by user value. Building “the whole database” as increment one delivers nothing a user can touch.

#4: Iterative Model

The Iterative model schedules deliberate rework. You build a version, evaluate it, then revisit and improve the same parts in the next cycle.

This is the model most often confused with Incremental, so it’s worth being exact.

Alistair Cockburn drew the cleanest line between them:

Iterative is a rework strategy: time set aside to revise and improve parts of the system you’ve already built.

Incremental is a staging strategy: different parts get built at different times and integrated as they’re finished. One improves what exists; the other adds what doesn’t.

That’s why so many projects genuinely run both, and why “iterative and incremental” appears as a single phrase so often.

How the SDLC Phases Flow in the Iterative Model

Build a version of the scope, evaluate it against real feedback, then cycle back through design, build, and test to improve it. Fidelity rises each pass.

• Best for: large systems where requirements firm up once people see something real, and anywhere you expect the first attempt to be wrong in instructive ways.
• Main weakness: without firm scope control, “one more iteration” becomes a permanent state. It’s also hard to give a stakeholder a completion date early on.
• The failure mode: treating iteration as a licence to avoid deciding. Iteration should reduce uncertainty each cycle. If iteration five is still exploring basics, the model isn’t the problem.

#5: Spiral Model

The Spiral model loops through four quadrants: set objectives, analyse and resolve risks, build and test, plan the next loop. Each loop tackles the biggest remaining risk first. Barry Boehm introduced it in 1986, and it’s still the most risk-driven model in use.

Spiral is the heavyweight. It exists for projects where failure would be catastrophic or ruinously expensive.

How the SDLC Phases Flow in the Spiral Model

You don’t build in priority order. You build in risk order. The scariest unknown gets prototyped and tested before anyone commits serious budget to the rest. The number of loops isn’t fixed in advance — it depends on how much risk remains.

• Best for: aerospace, defence, large healthcare platforms, and anywhere “is this technically possible at all?” needs answering before eight figures get spent.
• Main weakness: heavy overhead. Risk analysis at every loop needs people who can genuinely assess risk, and that expertise is expensive.
• The failure mode: the risk analysis becomes a documentation exercise. If the same risks appear on every loop unresolved, you’re running Waterfall with extra meetings.

#6: Prototype Model

The Prototype model builds a working mock-up before the real system. Users interact with it, and their feedback reshapes the requirements. In throwaway prototyping, the mock-up is discarded; in evolutionary prototyping, it’s hardened into the finished product.

Its whole purpose is to solve the “I’ll know it when I see it” problem.

How the SDLC Phases Flow

Gather rough requirements → build a quick prototype → demo it to users → refine requirements → repeat until requirements are stable → build the real thing properly.

• Best for: projects where stakeholders genuinely can’t describe what they want in the abstract, and interface-heavy products where the interaction is the product.
• Main weakness: prototypes cost time and money that produces no shippable code. Budget for it deliberately rather than discovering it mid-project.
• The failure mode: shipping a throwaway prototype. It cuts corners on purpose. Promoting a demo build to production because it “already works” saddles you with debt you never budgeted for. Evolutionary prototyping avoids this — but only if you decide upfront which variant you’re running.

#7: RAD Model

Rapid Application Development compresses design and build into fast cycles, leaning on reusable components and constant user involvement. Requirements are set loosely, then design and construction run together with users in the room. Feedback loops close in days rather than months.

RAD predates Agile and shares much of its DNA. The emphasis is different. RAD is specifically about speed through prototyping and component reuse.

How the SDLC Phases Flow in RAD

Requirements planning happens fast and loosely, then user design and construction run together in tight cycles with users in the room, then cutover moves it into production.

• Best for: internal business tools, MVPs, and short-timeline builds where users can genuinely show up every week. If RAD looks like your fit, our RAD model guide goes through the four stages in detail.
• Main weakness: it collapses without committed users. If stakeholders can’t give real time each week, the model has nothing to run on.
• The failure mode: using RAD on a system with deep integration requirements. It suits modular applications, not sprawling platforms with a dozen upstream dependencies.

#8: Big Bang Model

The Big Bang model has almost no formal process. You start coding with whatever requirements exist and figure the rest out as you go. There’s no defined phase sequence, minimal planning, and no guarantee about what emerges.

How the SDLC Phases Flow

They don’t, in any structured sense. Effort goes in, software comes out, and the shape is discovered along the way.

• Best for: tiny experiments, throwaway prototypes, academic exercises, and one-developer tools where the cost of being wrong is an afternoon.
• Main weakness: no predictability whatsoever. No estimate, no scope control, no way to tell a stakeholder when it’ll be done.
• The failure mode: letting it happen by accident on a real project. Big Bang is defensible as a deliberate choice on something disposable. It’s indefensible as the thing you drifted into because nobody picked a model.

#9: Agile Model

Agile repeats every SDLC phase in short cycles, typically one to four weeks, though Kanban runs as continuous flow instead. Each cycle produces releasable software. Scrum, Kanban, and XP are the methodologies teams use to run it.

Agile sits awkwardly in a list of models because it’s really a family: a set of values from the 2001 Agile Manifesto, plus the frameworks that implement them.

How the SDLC Phases Flow in Agile

All of them, every iteration. Each cycle plans, designs, builds, tests, and makes a slice of working software releasable, whether or not you actually ship it. The plan is expected to change between cycles.

• Best for: evolving products, unclear or shifting requirements, and stakeholders who can commit real time throughout rather than only at the start and end. It’s the default on most
  mobile app development company work, where store feedback keeps reshaping the roadmap.
• Main weakness: it needs an available, decisive stakeholder. Agile trades documentation for conversation. If that conversation doesn’t happen, you get neither.
• The failure mode: Agile theater. Sprints, standups, and a board. But scope locked at the start and releases queued quarterly. All of the ceremony, none of the adaptability.

How Do You Choose the Right Software Development Model?

Work through five questions in order: how stable are requirements, how bad is a production defect, how available is your stakeholder, how firm is the deadline, and how is the contract written. The first question that gives a hard answer usually decides it.

The Decision Tree

Question 1 — Will a defect in production cause physical harm, regulatory breach, or catastrophic loss?

• Yes → V-Model. Stop here. Certification evidence outranks every other consideration.

Question 2 — Is the core technology unproven, where “can this even be built?” is a live question?

• Yes → Spiral for the risky part, then switch to Iterative or Agile for the rest.

Question 3 — Can your stakeholders describe what they want, or do they need to see something first?

• They need to see it → Prototype first, then pick from the models below with requirements you can trust.

Question 4 — Are requirements genuinely locked, with a signed scope that won’t move?

• Yes → Waterfall. No, they’ll evolve → continue.

Question 5 — Can the product launch in useful pieces, or must it arrive whole?

• In useful pieces → Incremental. It must arrive whole → continue to question 6.

Question 6 — How short is the deadline, and how available are your stakeholders?

• Very short deadline, users available weekly → RAD
• Normal timeline, stakeholders engaged throughout → Agile
• Normal timeline, stakeholders available only at milestones → Iterative

Factors that actually swing the answer

Which Software Development Model Does Your Contract Force?

Your contract usually picks the model before anyone discusses engineering. Fixed-price with fixed scope structurally forces Waterfall or V-Model. Time-and-materials and dedicated-team contracts are what make Agile, Iterative, and Incremental genuinely workable in practice.

Why is ” fixed-price Agile ” mostly a contradiction?

A fixed price needs a fixed scope to price against. Agile assumes scope moves. Sign both and every backlog reprioritisation becomes a change request, which is Waterfall’s admin overhead with none of its planning discipline. Our custom software development cost guide works through how each pricing model behaves in practice.

What Does Each Software Development Model Actually Cost?

The cost of a Software Development Life Cycle (SDLC) model is defined by budget predictability, change flexibility, and risk management rather than developer hourly rates.

The number people forget is maintenance. Robert Glass, writing in IEEE Software, put maintenance at 40–80% of total software cost, averaging 60%. Whichever model you pick, most of the money is spent after launch.

Can You Combine Software Development Models?

Yes, and most real projects do. The common blends are a sequential discovery phase feeding an Agile build, prototyping ahead of any model, and Spiral for the risky component with something lighter for the rest. The rule is that the handoff point must be written down.

Sequential Discovery, Adaptive build

Do the discovery and architecture work as a documented front-end phase, agree the outline scope, then switch to iterations for the build. Enterprise and legacy modernisation projects almost always land here — leadership gets a plan they can defend, and the team keeps room to move inside it.

Prototype first, then anything

Prototyping isn’t really a rival to the other models. It’s a phase you bolt on the front when requirements are unclear. Once they’re stable, pick a model properly.

Spiral for the risk, Incremental for the rest

Use risk-driven loops on the component that might not work, then switch to a lighter model once the unknown is resolved. Most of the Spiral overhead only earns its keep on the genuinely risky part.

How TekRevol Picks and Runs the Right Model

TekRevol chooses the model from your constraints rather than from habit: requirement stability, compliance load, stakeholder availability, and contract type. We write the phase plan, owners, and sign-off points into the statement of work before the software development process starts.

Model choice is where most project disputes are quietly created. Here’s how we handle it:

We read the contract first

Fixed-price and Agile fight structurally. If your commercial terms and your delivery model don’t match, we say so during scoping; not in month three.

Discovery ends with a spec you own

You get screens, data fields, roles, and acceptance criteria in writing. It’s yours either way, and it’s what makes competing quotes comparable.

The model goes in the SOW with mechanics attached

A model name means nothing on its own. We write down iteration length, what you see at the end of one, who approves changes, and how long approval takes.