2.1 SDLC And Process Model Tradeoffs
The Software Development Life Cycle is not a sacred sequence of boxes. It is a way to reason about how an idea becomes running software, how feedback returns, and how decisions change.
A useful SDLC view is:
Need -> understand -> design -> build -> verify -> release -> operate -> learn -> adjust
Different organizations draw different diagrams, but the core engineering question is stable: where do we place feedback so risk becomes visible early enough?
Process is a feedback design
Process models are often taught as names: Waterfall, V-Model, Incremental, Spiral, Prototyping, Agile, Scrum, Kanban, DevOps.
In real work, the better question is what each model makes easy or hard:
- Does it discover requirement mistakes early?
- Does it surface technical risk early?
- Does it create evidence for compliance or safety?
- Does it keep work small enough to integrate?
- Does it make ownership clear?
- Does it support recovery after release?
No model saves a team from thinking. A model is a tool for structuring decisions, not a substitute for decisions.
Context variables
Before choosing a process stance, inspect:
| Variable | If high, you usually need |
|---|---|
| Requirement clarity | Strong specification and validation |
| Requirement volatility | Short iterations and frequent user feedback |
| Technical risk | spikes, prototypes, proof of concept, risk reviews |
| Failure cost | verification, rollback, audit trail, staged release |
| Compliance | traceability and controlled change |
| Team distribution | explicit communication and interface contracts |
The smell of process theater
A process becomes theater when it produces ceremonies but not feedback. Standups without blockers moving, sprint planning without working increments, architecture reviews without decisions, and postmortems without actions are all examples.
Good process makes reality harder to ignore.