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 software development methodologies — the systematic, structured approaches teams use to take a software system from a vague idea to a working, maintained product. A methodology is not just a sequence of steps; it embodies a philosophy about how to deal with uncertainty, change and risk. Choosing the right one is a genuine engineering decision: the same project can succeed under one approach and fail under another, depending on how stable its requirements are, how large and risky it is, and how closely the customer can be involved.
This lesson addresses systematic approaches to problem solving within the Systematic approach to problem solving section of the AQA A-Level Computer Science (7517) specification (subject content area 4.13). It covers the analysis → design → implementation → testing → evaluation/maintenance lifecycle, and the principal methodologies built on it: the waterfall model; agile development; rapid application development (RAD); the spiral model; and extreme programming (XP). You are expected to describe the stages of the software lifecycle, explain the characteristics, advantages and disadvantages of each methodology, and — most importantly — recommend and justify a suitable methodology for a given scenario.
Underneath every methodology lies the same set of fundamental activities, collectively the software development lifecycle (SDLC).
| Stage | What happens | Typical output |
|---|---|---|
| Analysis | Investigate the problem; elicit and document requirements; study any existing system. | Requirements specification |
| Design | Plan the architecture, data structures, algorithms and user interface. | Design documents, data models, screen layouts |
| Implementation | Write the code that realises the design. | Source code |
| Testing | Check the system against requirements; find and fix defects. | Test plans and results |
| Evaluation / Maintenance | Deploy; assess against objectives; fix bugs and make changes over the product's life. | Working, maintained system |
What distinguishes the methodologies is how these stages are sequenced and repeated — once, strictly in order (waterfall), or many times in small loops (agile, spiral, RAD). Keeping the SDLC stages clear in your mind is the key to describing any methodology, because each one is simply a different arrangement of these same activities.
Building software without a structured approach tends to produce missed deadlines and budget overruns, systems that do not match what the user actually wanted, code that no one can maintain, and unreliable, low-quality results. A methodology imposes discipline: it defines what is done, when, by whom, and how progress is judged — making large projects predictable and manageable rather than chaotic.
The waterfall model is linear and sequential: each stage must be completed and signed off before the next begins, and (in its pure form) you do not return to an earlier stage. Like water flowing down a series of steps, work only moves forwards.
flowchart TB
A["Analysis
(requirements)"] --> D["Design"]
D --> I["Implementation"]
I --> T["Testing"]
T --> DEP["Deployment"]
DEP --> M["Maintenance"]
Advantages
Disadvantages
Best for: large, well-understood projects with stable requirements — for example, safety-critical control systems or systems built to a fixed legal specification, where the cost of getting requirements wrong is high and they are unlikely to change.
Agile is iterative and incremental. Rather than one long pass, the team delivers the software in a stream of small, working increments produced in short, time-boxed iterations (often called sprints, typically one to four weeks). Each iteration carries out all the lifecycle stages — a little analysis, design, build and test — for a small slice of functionality.
The values behind agile are captured by the Agile Manifesto, which prioritises:
| Agile values | over |
|---|---|
| Individuals and interactions | processes and tools |
| Working software | comprehensive documentation |
| Customer collaboration | contract negotiation |
| Responding to change | following a plan |
A typical agile cycle:
flowchart LR
B["Prioritise
backlog"] --> P["Plan
iteration"]
P --> BUILD["Design,
build, test"]
BUILD --> DEMO["Demo working
increment"]
DEMO --> FB["Customer
feedback"]
FB --> B
Advantages
Disadvantages
Best for: projects with evolving or unclear requirements — web and mobile applications, start-up products and anything where early feedback materially improves the result.
Exam Tip: Do not equate agile with Scrum. Agile is a philosophy — a set of values and principles. Scrum is one specific framework that implements those principles (with roles such as Scrum Master and events such as the daily stand-up). If a question asks about agile generally, write about iterations, working increments and customer collaboration, not Scrum ceremonies.
The spiral model combines the staged discipline of waterfall with iterative prototyping, and adds a defining emphasis on risk analysis. Development proceeds through a series of loops (spirals); each loop passes through four quadrants, and the most dangerous risks are tackled first.
| Quadrant | Activity |
|---|---|
| Determine objectives | Define goals, constraints and alternative approaches for this loop. |
| Identify and resolve risks | Analyse the biggest risks; build prototypes or experiments to reduce them. |
| Develop and test | Build and verify the increment for this loop. |
| Plan the next iteration | Review with the customer and plan the next spiral. |
Advantages
Disadvantages
Best for: large, complex, high-risk developments — aerospace, defence or novel R&D — where a costly mistake must be caught before significant investment.
RAD prioritises rapid prototyping and fast delivery over extensive up-front planning. It uses short, time-boxed cycles and intense user involvement, refining prototypes with the user until they are right.
| Phase | Activity |
|---|---|
| Requirements planning | Gather broad requirements quickly, without exhaustive detail. |
| User design | Users and developers build and refine prototypes together, iteratively. |
| Construction | Rapidly turn agreed prototypes into working software. |
| Cutover | Final testing, data conversion, deployment and user training. |
Advantages
Disadvantages
Best for: small-to-medium projects with tight deadlines where the user interface and user experience are central and users are available to collaborate.
Extreme Programming (XP) is an agile methodology that takes good engineering practices to their logical extreme. Whereas agile is largely about process and values, XP prescribes concrete technical disciplines:
| Practice | What it means |
|---|---|
| Pair programming | Two developers share one workstation — one writes code, the other reviews in real time. |
| Test-driven development (TDD) | Automated tests are written before the code they verify. |
| Continuous integration | Code is merged and tested frequently (often many times a day) to catch conflicts early. |
| Refactoring | Code is continuously improved in small steps without changing its external behaviour. |
| Simple design | Build only what is needed now; avoid speculative complexity. |
Best for: projects where code quality, correctness and adaptability are paramount and the team can sustain these demanding disciplines.
| Feature | Waterfall | Agile | Spiral | RAD | XP |
|---|---|---|---|---|---|
| Structure | Linear, sequential | Iterative, incremental | Iterative + risk analysis | Iterative prototyping | Iterative + engineering rigour |
| Flexibility to change | Low | High | Medium–high | High | High |
| Customer involvement | Start and end | Throughout | At each loop | Throughout | Throughout |
| Documentation | Extensive | Light | Moderate | Light | Light–moderate |
| Risk management | Weak | Moderate | Strong (central) | Weak | Moderate |
| Delivery | One final release | Frequent increments | Increment per spiral | Rapid prototypes | Frequent, tested increments |
| Best suited to | Stable, well-defined projects | Evolving requirements | Large, high-risk systems | Fast UI-led delivery | Quality- and change-critical work |
The examined skill is justified selection. Work from the project's characteristics to the methodology, not the other way round.
| If the project... | then favour... | because... |
|---|---|---|
| has clear, fixed, fully documented requirements | Waterfall | the structure and documentation pay off when nothing will change. |
| has requirements that will evolve as users learn what they want | Agile | iterations absorb change and deliver value early. |
| is large, novel and high-risk | Spiral | risk-first loops catch costly mistakes before heavy investment. |
| needs a usable system fast, with users on hand and a UI focus | RAD | prototyping with users produces the right interface quickly. |
| above all needs robust, change-tolerant, high-quality code | XP | TDD, pairing and continuous integration build quality in. |
Exam Tip: "Recommend a methodology" questions reward reasoning, not naming. Always tie the choice to specific features of the scenario — "the requirements are expected to change as the charity trials the app, so an iterative agile approach allows…" earns far more than "use agile because it is flexible". Where useful, name a second-choice method and say why it is weaker here; that demonstrates genuine evaluation.
Whatever methodology is chosen, the analysis and design stages determine whether a project builds the right thing and builds it well. They deserve detailed attention because exam questions frequently ask about the activities and outputs of each.
Analysis is concerned with understanding the problem fully before any solution is proposed. Its central activity is requirements elicitation — discovering what the system must do — using techniques such as interviews with stakeholders, questionnaires for large user groups, observation of the current way of working, and examination of existing documents and systems. The requirements gathered are split into two kinds:
| Requirement type | Question it answers | Example |
|---|---|---|
| Functional | What must the system do? | "The system shall let a volunteer log hours against a project." |
| Non-functional | What qualities must it have? | "The system shall respond within two seconds and run on Android 10+." |
The main output of analysis is a requirements specification — an agreed, documented statement of what the system must achieve, which later becomes the yardstick for acceptance testing.
Design turns the what of analysis into the how of a buildable plan, without yet writing production code. Typical design activities and their outputs include:
| Design activity | Output |
|---|---|
| Decompose the problem into modules | A modular structure / hierarchy chart |
| Model the data | Data structures, an entity-relationship model, a data dictionary |
| Design the processing | Algorithms expressed as pseudocode or flowcharts |
| Design the interaction | User-interface layouts and screen flows |
| Plan the verification | An outline test plan |
Two recurring themes connect design back to earlier topics: decomposition (breaking a large problem into smaller, independently solvable sub-problems) and abstraction (hiding detail so each part can be reasoned about on its own). These are the same computational-thinking principles applied to algorithm design, now applied at the scale of a whole system.
The clearest way to feel the difference between methodologies is to imagine one project run two ways. Suppose a college wants a room-booking system.
Run as waterfall: analysts spend several weeks interviewing staff and producing a complete requirements specification, which is signed off. Designers then produce the full data model and interface designs; only then do developers write the entire system; only then is it tested as a whole; finally it is deployed. If, during testing, staff realise they also need recurring weekly bookings — a requirement missed at analysis — accommodating it means revisiting the specification, the design and the code: expensive, late rework. The upside is that everything is thoroughly documented and the timeline was predictable from the start.
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.