SDLC Methodologies: Agile and Waterfall
SDLC Methodologies: Agile and Waterfall
The Software Development Life Cycle (SDLC) is the structured process used to develop software. Different methodologies suit different project types — choosing the right one is a crucial software engineering decision.
The Waterfall Model
The waterfall model is a sequential, linear approach where each phase must be completed before the next begins. It flows downward like a waterfall.
Phases:
1. Requirements analysis — gather and document all requirements upfront
2. System design — architecture, data structures, interfaces
3. Implementation — write the code
4. Testing — verify the software works correctly
5. Deployment — release to users
6. Maintenance — fix bugs, add features post-release
Characteristics:
- Each phase produces documentation that feeds the next
- No going back to a previous phase (in pure waterfall)
- All requirements must be known at the start
- Heavy emphasis on planning and documentation
Advantages:
- Simple to understand and manage
- Clear milestones and deliverables
- Well-suited for projects with fixed, well-understood requirements
- Good documentation produced
- Progress is easily measured
Disadvantages:
- Inflexible — changes are costly once a phase is complete
- Client sees the product only at the end — late discovery of issues
- Risk of building the wrong thing if requirements change
- Testing happens late, so bugs found late are expensive to fix
- Not suitable for complex or evolving projects
Best for: Small projects with clear, unchanging requirements (e.g., regulatory compliance systems, simple embedded systems).
Agile Methodology
Agile is an iterative, incremental approach that delivers software in small, frequent releases. It embraces change and values working software over documentation.
The Agile Manifesto (2001) values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Key principles:
- Deliver working software frequently (every 1–4 weeks)
- Welcome changing requirements, even late in development
- Close daily cooperation between business and developers
- Face-to-face conversation as the primary communication method
- Working software is the primary measure of progress
- Continuous attention to technical excellence
- Simplicity — maximise the amount of work not done
Scrum (Agile Framework)
Scrum is the most popular Agile framework, organising work into fixed-length iterations called sprints (typically 2–4 weeks).
Scrum roles:
| Role | Responsibility |
|---|---|
| Product Owner | Defines features, prioritises the backlog, represents the customer |
| Scrum Master | Facilitates the process, removes impediments, not a manager |
| Development Team | Self-organising, cross-functional (3–9 people) |
Scrum artifacts:
| Artifact | Description |
|---|---|
| Product Backlog | Prioritised list of ALL features/requirements |
| Sprint Backlog | Features selected for THIS sprint |
| Increment | The working software produced at the end of each sprint |
Scrum events:
| Event | Purpose | When |
|---|---|---|
| Sprint Planning | Select items from product backlog for the sprint | Start of sprint |
| Daily Standup | 15-minute progress check (what did I do, what will I do, any blockers) | Every day |
| Sprint Review | Demo the increment to stakeholders, get feedback | End of sprint |
| Sprint Retrospective | Reflect on the process, identify improvements | End of sprint |
Other Methodologies
Extreme Programming (XP):
- Pair programming (two developers, one computer)
- Test-driven development (TDD): write tests before code
- Continuous integration: merge code frequently
- Refactoring: continuously improve code quality
Spiral Model:
- Combines waterfall's structure with iterative prototyping
- Each cycle through the spiral includes: planning → risk analysis → engineering → evaluation
- Emphasises risk assessment at each iteration
- Suited for large, complex, high-risk projects
Rapid Application Development (RAD):
- Prototyping-based approach
- Quick prototypes built, shown to users, refined
- User feedback drives development
- Less emphasis on planning, more on building
V-Model:
- Extension of waterfall where testing phases mirror development phases
- Each development stage has a corresponding testing stage
- Requirements → acceptance testing, design → integration testing, coding → unit testing
- Emphasises verification and validation throughout
Comparison Table
| Factor | Waterfall | Agile |
|---|---|---|
| Requirements | Fixed upfront | Evolving |
| Delivery | One final release | Frequent increments |
| Client involvement | Start and end only | Continuous |
| Flexibility | Rigid | Highly adaptable |
| Documentation | Heavy | Minimal (just enough) |
| Testing | End of project | Every iteration |
| Risk | High (late feedback) | Low (early feedback) |
| Team size | Any | Small, cross-functional |
| Best for | Stable requirements | Changing requirements |
Choosing a Methodology
| Scenario | Best approach |
|---|---|
| Requirements are clear and unlikely to change | Waterfall |
| Client wants to see progress frequently | Agile |
| Safety-critical system (medical, aviation) | V-Model or Waterfall |
| Innovative product, unclear requirements | Agile |
| Large team, distributed across locations | Agile (with modifications) or Waterfall |
| High-risk, large-scale project | Spiral |
| Tight deadline, need something working fast | RAD or Agile |
Exam Tips
- Don't just list features — justify why a methodology suits a given scenario
- Agile is not "no planning" — it plans continuously in short cycles
- Waterfall is not always bad — it works well when requirements are truly fixed
- In comparison questions, use a structured table covering at least: requirements, delivery, testing, flexibility, client involvement
- Know Scrum roles and events — these are commonly tested
- The spiral model's distinguishing feature is risk analysis at each iteration
- When asked "which methodology for X scenario", consider: how clear are requirements? How involved is the client? How critical is the system? How large is the team?