Choose an iterative model when user needs are uncertain and people can review working increments. Use a more sequential model when requirements and dependencies are stable and phase approvals are necessary. Formal acceptance tests can fit either approach: agree what must pass, who approves it, and what evidence to keep.
TL;DR
- Waterfall moves through sequential phases and fits stable requirements; Agile delivers in increments and adjusts from feedback.
- For a new product with uncertain needs, start with short iterations and customer review; add written acceptance checks when approval or evidence is required.
- Spiral repeatedly evaluates major risks; the V-model pairs development stages with corresponding test stages.
- Rapid application development uses prototypes and frequent user review, but depends on timely decisions and a manageable scope.
- Formal acceptance tests can accompany iterative delivery: agree the requirement, test evidence and approval owner for each increment.
- For a changing live product, add deployment checks, monitoring, incident ownership and maintenance regardless of the delivery model.
An SDLC model organizes planning, design, development, testing, release, and maintenance. Its value is in the decisions and checks it makes possible, not the label the team chooses.
Choose the model around the biggest risk
Start with the uncertainty that could do the most damage:
- Unclear user need: Use prototypes, Agile, or iterative delivery to learn before committing to the full scope.
- Stable scope with formal approvals: Use Waterfall or V-model controls to make requirements, tests, and sign-off explicit.
- High technical uncertainty: Use Spiral or staged experiments to test the dangerous assumptions early.
- Short deadline with modular scope: Consider Rapid Application Development when experienced people and frequent user feedback are available.
- A live product with frequent releases: Use DevOps practices so delivery and operations work as one system.
Most real teams combine parts of several models. The point is not to follow a label perfectly. It is to create enough structure for the project’s decisions, risks, and quality needs.
Which model should a buyer choose?
For a new product, start with iterative delivery: agree the outcome and budget for a small first release, show working software to users, then decide what to build next. This makes it possible to change the next increment without waiting for the entire product. It does not remove the need for a budget, written requirements, or a release date.
Use a sequential plan when the deliverable is well specified and the team cannot begin a later phase until an earlier one is approved. Choose the V-model when each significant requirement needs a corresponding test and documented acceptance. Use Spiral when the largest technical or safety risk needs a deliberate investigation before the team commits to a larger build. These choices are about the work’s constraints; none guarantees a lower project cost.
| Buyer situation | Starting approach | What to agree before work starts |
|---|---|---|
| New product and uncertain features | Iterative delivery | First release outcome, budget, review cadence and who can change priorities |
| Stable scope with required phase approvals | Sequential plan | Approved requirements, change process and acceptance owner |
| High-consequence requirements and evidence | V-model or iterative work with acceptance gates | Requirements, tests, evidence and person authorized to accept each release |
| A major unproven technical risk | Spiral or a focused prototype | Risk to test, success criterion, budget limit and decision date |
For a hypothetical four-week first increment with two people at $100 per hour each, 160 hours per person costs $32,000 before software, management and other expenses. This is a calculation, not a market quote or proof that one model is cheaper. Agree the hours and deliverables in the proposal; later increments need their own scope and budget.
What the software development life cycle covers
The software development life cycle usually includes:
- Discovery and planning
- Requirements
- Product and technical design
- Development
- Testing
- Deployment
- Operations and maintenance
Different models arrange these activities in different ways. Waterfall moves through them in sequence. Iterative models repeat them in smaller slices. DevOps extends the cycle into production monitoring and continuous delivery.
For a closer look at the work inside each stage, read our guide to the software building process.
Waterfall
Waterfall moves through defined phases in sequence. Requirements are completed before design, design before development, and development before testing and release.
When Waterfall fits
Waterfall can work when:
- Requirements are stable and well documented.
- The technology is understood.
- Approval or procurement requires formal phase gates.
- Changes are rare and expensive for a known reason.
- The project has a fixed handoff between specialist teams.
Strengths
- Milestones and documents are clear.
- Budget and schedule planning are easier when scope is genuinely stable.
- Stakeholder approval can happen at defined points.
- The record of decisions suits formal environments.
Risks
- Users may not see working software until late.
- A wrong early requirement can survive for months before the team tests it.
- Scope changes cause large planning and contract changes.
- Testing at the end leaves less time to correct structural problems.
Waterfall is a poor fit when the team still needs to discover what users need. A detailed plan cannot remove that uncertainty.
Agile
Agile delivery breaks the work into small increments. The team builds, reviews, and adapts the product in short cycles rather than treating the initial plan as final.
Agile is a set of principles, not one prescribed process. Scrum, Kanban, and other frameworks give teams different ways to apply those principles.
When Agile fits
Agile is useful when:
- User feedback should shape the product.
- Requirements will change as the team learns.
- The product can be delivered in useful increments.
- Business and technical people can make frequent decisions.
- Early working software is more useful than a complete specification.
Strengths
- The team can test decisions sooner.
- Useful work can reach users before the entire roadmap is complete.
- Scope can respond to evidence.
- Frequent review makes blockers and quality problems visible.
Risks
- Weak product ownership can turn iteration into churn.
- Constant priority changes can damage architecture and focus.
- Long-term commitments are harder to estimate before discovery.
- Teams sometimes use “Agile” to avoid documentation or decisions.
Agile still needs a clear goal, stable ownership, acceptance criteria, and technical discipline. It changes how the team plans; it does not remove planning.
Scrum
Scrum is an Agile framework that organizes work into time-boxed sprints. A product owner manages priorities, the development team completes a selected set of work, and regular reviews and retrospectives create feedback.
Scrum can help a cross-functional product team that needs a steady planning rhythm. It can become heavy when meetings and roles are copied without a real product backlog or empowered owner. Teams should use the parts that improve delivery rather than treating the framework as the product.
Iterative and incremental delivery
Iterative delivery improves a solution through repeated cycles. Incremental delivery adds usable parts over time. Teams often use both: ship a small slice, learn from it, then improve and extend it.
When it fits
- The team understands the broad goal but not every detail.
- A large system can be divided into useful releases.
- Feedback from one version should influence the next.
- Technical architecture can support gradual expansion.
Strengths
- Working software appears early.
- High-priority risks can be handled first.
- Feedback is based on something people can use.
- Changes cost less when each increment remains small.
Risks
- Repeated changes can create technical debt without architectural care.
- The end date can drift if the team never defines a release boundary.
- Dependencies between increments may be underestimated.
- Stakeholders may confuse visible progress with a production-ready product.
This approach is common in MVP development, where the first release should test a clear product assumption rather than reproduce the final vision at a smaller scale.
Spiral
The Spiral model organizes work around repeated risk analysis. Each loop typically includes planning, risk assessment, engineering, and evaluation. The team tests dangerous assumptions before increasing its commitment.
When Spiral fits
- The project is large or technically uncertain.
- Failure carries a high cost.
- Requirements may change after experiments or stakeholder review.
- New technology, integrations, or architecture need proof.
- The team has enough expertise to assess risk well.
Strengths
- Risk receives explicit attention in every cycle.
- Prototypes can test the hardest parts early.
- Plans can change when evidence changes.
- Stakeholders review progress before the next major commitment.
Risks
- It requires experienced risk management.
- The process can be too costly for a small, low-risk project.
- Repeated loops make the end date harder to predict.
- Poor exit criteria can keep discovery running without a decision.
V-model
The V-model is a sequential approach that pairs each development stage with a corresponding testing stage. Requirements connect to acceptance testing, system design to system testing, and detailed design to integration or unit testing.
When the V-model fits
- Requirements are stable.
- Verification and traceability matter.
- The product operates in a regulated or safety-sensitive environment.
- The team must plan tests before development begins.
Strengths
- Testing is designed alongside requirements.
- Each requirement can be traced to verification.
- Roles, outputs, and approval points are clear.
- Defects caused by incomplete test planning are easier to prevent.
Risks
- Late requirement changes are expensive.
- Users may still wait too long to see a realistic product.
- The process can encourage document completion over learning.
- It is excessive for a small project with low consequences of failure.
Rapid Application Development
Rapid Application Development, or RAD, emphasizes workshops, prototypes, reusable components, and frequent user review. The team works within a short time box and defers lower-priority improvements rather than extending the deadline.
When RAD fits
- The product can be split into clear modules.
- Users are available to review prototypes often.
- The technical risk is limited.
- Experienced designers and developers can work quickly together.
- Speed matters more than a complete first release.
Strengths
- Users see and correct the product early.
- Prototypes make requirements concrete.
- Modular work can move in parallel.
- Lower-priority scope can be deferred without blocking the core release.
Risks
- The method depends on fast user decisions.
- Rushed prototypes can become fragile production code.
- Architecture and documentation may receive too little attention.
- It does not suit tightly coupled systems or high technical risk.
Prototyping
Prototyping creates an early representation of the product so the team can test a workflow, interface, or technical idea. The prototype may be disposable, or it may evolve into the product.
Use a throwaway prototype when the goal is learning and the code is not designed for production. Use an evolutionary prototype only when the team is prepared to improve its architecture as the product grows.
Prototyping fits unclear requirements and interaction-heavy products. Its main risk is expectation: stakeholders may see a polished interface and assume the system behind it is also complete.
DevOps
DevOps joins software development with release and production operations. It uses shared ownership, automation, monitoring, and frequent feedback to make deployment a routine part of delivery.
DevOps is not a replacement for product discovery or development planning. It changes how the team builds, tests, releases, and operates software after priorities are set.
When DevOps fits
- The product needs frequent, reliable releases.
- The same team can own software beyond deployment.
- Automated testing and infrastructure work are worth the investment.
- Production behavior should guide improvements.
Strengths
- Smaller releases reduce the size of each change.
- Automated checks make release quality more repeatable.
- Monitoring shortens the path from production problems to action.
- Development and operations share responsibility for reliability.
Risks
- Tools do not fix unclear ownership or weak engineering practices.
- Automation takes time to design and maintain.
- Legacy systems may resist frequent deployment.
- Security and compliance need to be built into the delivery pipeline.
What about Big Bang and CMMI?
Big Bang development starts with little formal planning and lets the product emerge from the work. It may be acceptable for a disposable experiment built by one or two people. It is not a dependable delivery model for software that other people must fund, use, or maintain because scope, cost, and quality remain uncontrolled.
Capability Maturity Model Integration, or CMMI, is different from the delivery models above. It helps an organization assess and improve the maturity of its processes. It does not tell one product team how to arrange discovery, design, development, and release. An organization can use CMMI while its teams use Waterfall, Agile, or hybrid delivery models.
Compare the main SDLC models
| Model | Best fit | Main advantage | Main risk |
|---|---|---|---|
| Waterfall | Stable, sequential scope | Clear phases and approvals | Feedback arrives late |
| Agile | Changing product needs | Frequent learning and reprioritization | Churn without strong ownership |
| Iterative | Large product built in slices | Working versions arrive early | Release boundary can drift |
| Spiral | High technical or delivery risk | Risk is tested before commitment grows | Process requires expertise and time |
| V-model | Stable work with formal verification | Tests trace back to requirements | Change is expensive |
| RAD | Modular product with a short deadline | Fast prototypes and user review | Architecture may be rushed |
| Prototyping | Unclear workflow or interface | Makes assumptions testable | Prototype may be mistaken for production |
| DevOps | Live product with frequent releases | Reliable delivery and operational feedback | Automation alone cannot fix weak ownership |
How to choose an SDLC model
Work through these questions with the people who own product, engineering, quality, and operations.
How stable are the requirements?
If the requirements come from a fixed regulation or contract, sequential controls may fit. If the team expects user research or market response to change the solution, choose an iterative model.
When can users review working software?
Frequent access to users supports Agile, RAD, and prototyping. If review can happen only at formal milestones, the plan needs stronger up-front acceptance criteria.
What happens if the team is wrong?
High-consequence technical, security, or compliance risks need early experiments and verification. Spiral and V-model practices can provide that control in different ways.
Can the product be released in useful slices?
Incremental delivery works when each release can produce a complete outcome. A tightly coupled migration or infrastructure change may need a different release strategy even if development happens iteratively.
How experienced is the team?
RAD and Spiral depend on strong judgment. Agile depends on an empowered product owner and a team able to manage quality while priorities change. A model that exceeds the team’s current capability may add risk instead of reducing it.
What does production require?
If the software will keep changing after launch, include DevOps practices from the start: automated checks, deployment controls, monitoring, incident ownership, and maintenance.
Use a hybrid deliberately
A hybrid model is useful when each part has a clear job. A team might:
- Run discovery and prototypes to test the problem.
- Approve a stable first-release scope.
- Build in short Agile cycles.
- Trace regulated requirements to formal tests.
- Release through a DevOps pipeline.
Do not combine models by accident. Write down which decisions are fixed, which can change, when users will review the product, and what must be true before release.
Example: a changing workflow with a formal acceptance gate
Suppose a company is replacing a staff approval spreadsheet. The approval sequence is still being learned, but the final system must preserve a record of who approved each request. This is a hypothetical example, not a Hapy project.
Use short iterations to test the screens and sequence with staff. Keep the approval-record requirement and its acceptance test visible throughout the work. For each increment, record the requirement, the test result, any unresolved exception, and the person who can accept it. For example, test that an authorized approver’s action appears against the correct request, and that an unauthorized user cannot approve it. A failed check blocks acceptance until the owner decides how to resolve it.
Before the final release, run the agreed tests against the intended release and have the named business owner review the evidence. If a contract or governing rule requires a particular process, follow that requirement; an iterative team cannot waive it. NASA’s software life-cycle guidance illustrates that a project can select among life-cycle models while defining the criteria for moving between phases. It does not prescribe this example or make it compliant with a particular regulation.
The right SDLC model should make the project’s biggest risk easier to see and manage. If the process creates more ceremony without improving a decision, test, or handoff, simplify it. Review Hapy’s services when you need to match a delivery model to that risk.
