Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
Software development lifecycle (SDLC) models aren't just abstract frameworks—they're the strategic blueprints that determine whether a project succeeds or fails. In Advanced Design Strategy, you're being tested on your ability to match the right model to the right project context, understanding how factors like requirement stability, risk tolerance, team structure, and delivery timelines influence which approach works best. These models represent fundamentally different philosophies about how software should evolve from concept to deployment.
Don't just memorize the names and steps of each model. Focus on understanding when and why you'd choose one over another. Exam questions will ask you to analyze scenarios and recommend appropriate methodologies, compare trade-offs between flexibility and predictability, or explain how a model's structure addresses specific project risks. Know what problem each model solves, and you'll be ready for anything.
These models prioritize upfront planning, comprehensive documentation, and predictable progression. They assume requirements can be fully defined before development begins and that changes are costly once work starts.
Compare: Waterfall vs. V-Model—both are sequential and documentation-heavy, but V-Model embeds testing planning from day one rather than treating it as a final phase. If asked about improving quality assurance in a plan-driven approach, V-Model is your answer.
These models acknowledge that perfect upfront planning is often impossible. They build in cycles of refinement, allowing teams to learn and adjust as they go.
Compare: Iterative vs. Spiral—both use repeated cycles, but Spiral adds formal risk assessment to each iteration. Choose Iterative for moderate uncertainty; choose Spiral when project failure would be catastrophic.
Agile models embrace change as a competitive advantage rather than a threat. They prioritize working software, customer collaboration, and responding to feedback over following a fixed plan.
Compare: Scrum vs. Kanban—both are Agile, but Scrum uses fixed-length sprints while Kanban emphasizes continuous flow. Scrum works better for teams needing structure; Kanban suits teams optimizing existing processes. FRQ tip: If asked about improving team efficiency without major process overhaul, Kanban is often the answer.
These models prioritize speed and user involvement, getting functional software in front of users as quickly as possible. They're built for situations where time-to-market or requirement clarity is the primary constraint.
Compare: RAD vs. Prototyping—both get working software to users quickly, but RAD aims for production-ready increments while Prototyping creates throwaway models to clarify requirements. Use Prototyping when you don't know what to build; use RAD when you know but need it fast.
| Concept | Best Examples |
|---|---|
| Stable requirements, predictable delivery | Waterfall, V-Model |
| Quality assurance emphasis | V-Model, Spiral |
| Risk management priority | Spiral |
| Changing requirements, customer collaboration | Agile, Scrum, Kanban |
| Time-boxed iterations with ceremonies | Scrum |
| Continuous flow without fixed sprints | Kanban |
| Speed and rapid delivery | RAD, Incremental |
| Requirement discovery and clarification | Prototyping |
| Gradual refinement through cycles | Iterative, Spiral, Incremental |
A client has fixed requirements, strict regulatory documentation needs, and zero tolerance for defects. Which two models would you recommend, and why might you choose one over the other?
Compare and contrast Scrum and Kanban: What project characteristics would make you choose one over the other?
Your team is building software for a startup that isn't sure exactly what features users want. Which models prioritize requirement discovery, and how do they differ in their approach?
Explain why Spiral Model is often chosen for aerospace or medical device software despite its higher overhead costs.
An FRQ describes a project with evolving requirements, a six-month deadline, and a need for early stakeholder feedback. Identify which models could work and explain the trade-offs between them.