Loading...
Development methods organise feedback, risk and delivery. Compare how a team would handle a concrete change instead of learning a list of disconnected advantages.
What you'll be able to do
A waterfall model organises work through major stages such as requirements, design, implementation, testing and deployment. Clear baselines and documented reviews can suit stable, well-understood requirements and contractual checkpoints. Discovering a misunderstood requirement late can make change expensive because several dependent artefacts need revision.
Agile approaches deliver and review working increments, using feedback to adjust priorities and detail. This suits uncertainty and regular stakeholder access. It still needs planning, design and useful documentation. Short cycles do not remove dependencies or guarantee that a team will finish everything originally imagined. Compare the ability to obtain feedback and manage scope, rather than calling one method universally modern or correct.
Extreme programming is an agile approach associated with practices such as frequent small releases, automated tests, continuous integration, pair programming and refactoring. The practices reinforce rapid feedback and maintainable code; they require discipline and collaboration, and are not simply permission to code without design.
The spiral model repeatedly considers objectives, alternatives and risks, develops or evaluates an appropriate prototype, and plans the next cycle. It can suit significant technical uncertainty but introduces risk-analysis overhead. Rapid application development emphasises rapid prototyping, user involvement, timeboxing and reusable components or tools. Fast interface construction helps only if the underlying data, performance and integration requirements can also be met.
For an unfamiliar recognition algorithm, a risk-focused prototype can test feasibility before a team commits to an elaborate interface. For a small reporting tool with changing layouts and available users, short prototypes and feedback may expose misunderstandings early. A tightly specified interface to an external system may still need a stable documented contract within an iterative project.
Algorithms can be expressed, traced and tested under any lifecycle. Revisit assumptions when feedback changes a requirement; do not merely edit the screen while leaving validation or data structures inconsistent. A useful comparison names a scenario constraint, explains how a method handles it and acknowledges a consequence. Project marks reward evidence and justified decisions, not the lifecycle name alone.
| Approach | Central organising idea | A question to ask |
|---|---|---|
| Waterfall | Major phase baselines | How stable and understood are requirements? |
| Agile | Working increments and feedback | Can stakeholders review frequently? |
| XP | Technical practices supporting short cycles | Can the team sustain testing and integration? |
| Spiral | Repeated risk-focused cycles | Which uncertainty could invalidate the plan? |
| RAD | Rapid prototypes and timeboxed delivery | Can tools/components meet the real constraints? |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.