Choosing the Right SDLC for Your Project
No single SDLC model is right for every project. QA engineers who join new projects must quickly assess which model is in use — or advocate for a change if the wrong model is being applied. Understanding selection criteria for SDLC models makes you a more strategic QA partner and helps you set realistic expectations for quality activities at each stage.
30 min•By Priygop Team•Updated 2026
SDLC Selection Criteria
- Use Waterfall when: Requirements are well-understood and stable (unlikely to change), the project is long-term with clear milestones, the team is large and distributed, regulatory compliance requires heavy documentation (government contracts, medical device software)
- Use V-Model when: Safety-critical systems where every requirement must have a mapped test (automotive, aviation, medical), regulatory audits require traceability between requirements and test cases, high cost of defects demands early verification
- Use Agile/Scrum when: Requirements are expected to evolve, frequent delivery of working software is valuable, the team is small and co-located or well-connected, customer feedback is available throughout development
- Use Spiral when: Large, high-risk projects where upfront risk identification is critical, novel technology is being used and technical risks are significant, the budget allows for iterative risk mitigation before full commitment
Practical Example — SDLC Phase Gate Checker
Practical Example — SDLC Phase Gate Checker
# Practical: Modelling SDLC Entry/Exit Criteria in Python
# Demonstrates: phase gates, QA activities per phase, shift-left timing
from dataclasses import dataclass, field
from typing import List
@dataclass
class SDLCPhase:
name: str
entry_criteria: List[str]
qa_activities: List[str]
exit_criteria: List[str]
completed_items: List[str] = field(default_factory=list)
def can_enter(self) -> bool:
"""Check if all entry criteria are met before starting this phase."""
unmet = [c for c in self.entry_criteria if c not in self.completed_items]
if unmet:
print(f"❌ Cannot enter '{self.name}' — unmet entry criteria:")
for item in unmet: print(f" • {item}")
return False
print(f"✅ Entry criteria met — '{self.name}' can begin.")
return True
def can_exit(self) -> bool:
"""Check if all exit criteria are satisfied before moving forward."""
unmet = [c for c in self.exit_criteria if c not in self.completed_items]
if unmet:
print(f"⚠️ Cannot exit '{self.name}' — incomplete exit criteria:")
for item in unmet: print(f" • {item}")
return False
print(f"✅ Exit criteria met — '{self.name}' complete.")
return True
# ─── Example: System Testing Phase (Waterfall) ───────────────────────────────
system_testing = SDLCPhase(
name="System Testing",
entry_criteria=[
"All code modules delivered",
"Unit test report reviewed",
"Test environment configured",
"Test data prepared",
],
qa_activities=[
"Execute system test cases",
"Log defects in Jira",
"Verify defect fixes",
"Daily progress reporting",
],
exit_criteria=[
"95% test cases executed",
"Zero critical defects open",
"All high-priority defects fixed",
"Test Summary Report signed off",
],
# Simulate partial completion — entry OK, exit not yet met
completed_items=[
"All code modules delivered",
"Unit test report reviewed",
"Test environment configured",
"Test data prepared",
"95% test cases executed",
# "Zero critical defects open" ← not done yet
],
)
system_testing.can_enter() # ✅ passes
system_testing.can_exit() # ❌ fails — critical defects still open
# ─── QA Parallel Activity Planner ────────────────────────────────────────────
def qa_sprint_plan(sprint_days: int = 14) -> None:
"""Show QA activities mapped to sprint timeline (Agile shift-left)."""
activities = [
(1, 3, "Sprint Planning — review stories, define acceptance criteria"),
(1, 7, "Write test cases for sprint features (parallel to dev)"),
(3, 10, "Test features as completed — don't wait for all dev done"),
(8, 13, "Regression testing — verify no existing features broken"),
(13, 14, "Sprint review prep — demo-ready, acceptance criteria verified"),
]
print(f"\n─── QA Sprint Plan ({sprint_days}-day sprint) ───")
for start, end, activity in activities:
print(f" Days {start:02d}-{end:02d}: {activity}")
qa_sprint_plan()SDLC Quick Review — Module 2
Tip
Tip
Practice Choosing the Right SDLC for Your Project in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Diagram
Loading diagram…
Shift-left = test earlier. 10x cheaper to fix bugs in requirements vs production.
Practice Task
Note
Practice Task — (1) Write a working example of Choosing the Right SDLC for Your Project from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Choosing the Right SDLC for Your Project is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- No single SDLC model is right for every project.
- Use Waterfall when: Requirements are well-understood and stable (unlikely to change), the project is long-term with clear milestones, the team is large and distributed, regulatory compliance requires heavy documentation (government contracts, medical device software)
- Use V-Model when: Safety-critical systems where every requirement must have a mapped test (automotive, aviation, medical), regulatory audits require traceability between requirements and test cases, high cost of defects demands early verification
- Use Agile/Scrum when: Requirements are expected to evolve, frequent delivery of working software is valuable, the team is small and co-located or well-connected, customer feedback is available throughout development