You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
This lesson covers the main software development methodologies required by the OCR H446 specification: Waterfall, Agile, Extreme Programming (XP), Spiral and Rapid Application Development (RAD). You must understand how each works, its advantages and disadvantages, and when each is appropriate.
A programming methodology (or software development methodology) is a structured approach to planning, designing, developing, testing and maintaining software. It defines the stages of the development process and the order in which they are carried out.
The Waterfall model is a linear, sequential approach where each phase must be completed before the next begins.
Requirements -> Design -> Implementation -> Testing -> Deployment -> Maintenance
| Stage | Description |
|---|---|
| Requirements | Gather and document all requirements from the client. The full specification is agreed upon before any design begins |
| Design | Create the system architecture, data structures, algorithms and interface design based on the requirements |
| Implementation | Write the code according to the design specification |
| Testing | Test the system against the requirements to find and fix defects |
| Deployment | Release the system to users |
| Maintenance | Fix bugs, update features and respond to changing needs |
| Advantage | Explanation |
|---|---|
| Simple and easy to understand | Clear, linear stages with defined milestones |
| Well-documented | Each stage produces documentation before the next begins |
| Easy to manage | Progress is measurable — you know which stage you are in |
| Good for small, well-understood projects | When requirements are clear and unlikely to change |
| Disadvantage | Explanation |
|---|---|
| Inflexible — difficult to go back | Once a stage is complete, changes are expensive and disruptive |
| Late discovery of problems | Working software is not produced until late in the process; users cannot test early |
| Poor for changing requirements | If the client changes their mind, the whole process may need to restart |
| High risk | Errors in early stages (e.g. requirements) may not be discovered until testing |
Agile is an iterative, incremental approach where the project is developed in short cycles called sprints (typically 1-4 weeks). Working software is delivered frequently, and requirements can change throughout the project.
| Principle | Meaning |
|---|---|
| Individuals and interactions | Over processes and tools |
| Working software | Over comprehensive documentation |
| Customer collaboration | Over contract negotiation |
| Responding to change | Over following a plan |
Sprint 1 Sprint 2 Sprint 3 ...
[Plan-Develop- [Plan-Develop- [Plan-Develop-
Test-Review] Test-Review] Test-Review]
| | |
v v v
Working Increment Working Increment Working Increment
Each sprint:
| Advantage | Explanation |
|---|---|
| Flexible — embraces changing requirements | New features or changes can be incorporated in the next sprint |
| Early delivery of working software | The client sees working software after every sprint |
| Continuous feedback | Regular reviews ensure the product meets client needs |
| Lower risk | Problems are discovered early through frequent testing and review |
| Disadvantage | Explanation |
|---|---|
| Less predictable | Difficult to estimate final cost and timeline at the start |
| Requires client involvement | The client must be available for regular feedback |
| Less documentation | Emphasis on working software can lead to insufficient documentation |
| Scope creep | Without a fixed specification, the project can grow beyond the original plan |
Extreme Programming is an Agile methodology that emphasises technical excellence and close collaboration.
| Practice | Description |
|---|---|
| Pair programming | Two programmers work together at one computer — one writes code (driver), the other reviews in real-time (navigator) |
| Test-driven development (TDD) | Write automated tests BEFORE writing the code. Code is then written to pass the tests |
| Continuous integration | Code changes are integrated into the shared repository multiple times per day. Automated tests run on every integration |
| Refactoring | Continuously improve the structure of existing code without changing its behaviour |
| Small releases | Deliver small, frequent releases to the client |
| Simple design | Keep the design as simple as possible — do not over-engineer |
| Collective code ownership | Any developer can modify any part of the code |
| On-site customer | A client representative is available at all times to answer questions |
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.