- Understand what a development methodology is and why it matters
- Identify the five phases of ADDIE: Analysis, Design, Implementation, Testing, Evaluation
- Compare iterative and linear development approaches
- Explain how methodologies help reduce errors and improve quality
- You can name and describe all five ADDIE phases with examples
- You can explain why testing feeds back into implementation
- You can identify whether a scenario describes iterative or linear development
- You can write a short explanation of how methodology improves software quality
Answer before the lesson begins. These check prior knowledge — it's fine if you're unsure.
1. What is a development methodology?
2. In ADDIE, which phase comes after Design?
3. Why do software projects need a methodology?
Key vocabulary
Development Methodologies
What is a development methodology?
A development methodology is a structured approach to planning, designing, building, and testing software. Instead of developers randomly writing code, a methodology provides a framework — a series of phases and processes — that helps teams work together, reduce errors, and deliver quality software on time.
Think of it like building a house. You don't just start laying bricks. You first plan (analysis), design the blueprint (design), build the structure (implementation), inspect for problems (testing), and finally evaluate if it meets the client's needs (evaluation). Each step follows logically from the last, and problems found later inform what needs to be fixed earlier.
Without a methodology, software projects often fail because:
- Requirements aren't clear, so developers build the wrong thing
- Testing happens too late, when bugs are expensive to fix
- Communication breaks down between teams
- Changes keep the project scope growing (scope creep)
The ADDIE model
ADDIE is the most common software development methodology. It has five phases that occur in sequence, but testing and evaluation often loop back to earlier phases for improvements.
Phase 1: Analysis
In analysis, the team works with the client to understand what needs to be built. Questions include: What problem does the software solve? Who are the end users? What inputs does the system need? What outputs must it produce? What are the constraints (time, budget, hardware)? The output is a requirements document that clearly defines what the software must do. Without clear requirements, the later phases will go wrong.
Phase 2: Design
Design is where the team plans how to build it. This includes: system architecture (how components connect), database design (how data is organized), user interface mockups (how users will interact with the software), and algorithms and pseudocode (steps to solve the problem). A good design prevents errors that would be expensive to fix later. If the design is flawed, the whole implementation will be flawed.
Phase 3: Implementation
Implementation is where developers actually write the code. They follow the design specification, using the programming language chosen in the design phase. Implementation includes writing source code, creating databases, building the user interface, and creating the build system. Developers also do basic testing as they code (unit testing), but comprehensive testing comes in the next phase.
Phase 4: Testing
Testing checks that the software works correctly and meets the original requirements. Types include unit testing (does each function work in isolation?), integration testing (do components work together?), system testing (does the entire system work as intended?), and user acceptance testing (does the client accept it as complete?). When bugs are found, developers must return to implementation — or even design — to fix them. This is the feedback loop.
Phase 5: Evaluation
Evaluation happens after the software is deployed (released to users). The team reviews whether the software solves the original problem, meets user needs, performs reliably in the real world, and is maintainable for future changes. User feedback from evaluation often leads to new requirements and a new development cycle for version 2.
Iterative vs. linear development
ADDIE appears to be linear — one phase after another. But in practice, it's iterative. When testing finds a bug, the team loops back to fix it. When evaluation finds a missing feature, that feedback starts a new cycle.
- Linear: Complete analysis → complete design → complete implementation → complete testing → complete evaluation. Each phase is 100% done before moving on.
- Iterative: Do a bit of each phase, test, get feedback, improve. Repeat in smaller cycles.
Modern software development is increasingly iterative because it allows for faster feedback and reduces the risk of building the wrong thing.
Why methodology matters
Methodology is not bureaucracy — it's a proven way to catch errors early (problems found in design are cheaper to fix than problems found after launch), communicate clearly (a requirements document ensures everyone understands the goal), reduce scope creep (a clear scope prevents endless feature requests), deliver on time (structured planning makes accurate estimates possible), and maintain quality (systematic testing ensures standards are met). Without methodology, software projects often go over budget, miss deadlines, and disappoint users.
Worked examples
Scenario: A school needs software to track books, borrowers, and due dates.
Scenario: A bank is building a mobile app for account transfers.
Scenario: A game studio is making an action game.
A company is building a hotel booking website. The project manager says: "Let's skip the design phase and go straight to coding. It'll be faster."
Explain why this is a bad idea using your knowledge of ADDIE.
Skipping design is risky for several reasons:
- No clear plan: Developers won't know the database structure, user interface layout, or search algorithm to use. Decisions made ad-hoc lead to inconsistent and poor-quality code.
- Errors compound: A bad architectural decision made during coding is very expensive to fix later — for example, if the database structure is wrong, all queries must be rewritten.
- Scope creep: Without a design spec, clients keep requesting changes ("Can we show hotel ratings?" "Can users save favourites?"). Without scope control, the project grows, defeating the goal of "going faster."
- Testing is harder: Testers need a specification to test against. Without one, there is no clear standard for what "correct" means.
- It takes longer overall: Skipping design might save one week of planning, but costs several weeks of debugging, rework and scope creep. The shortcut actually makes the project slower.
Past paper question: "A company is developing a new e-commerce website. Describe the ADDIE methodology and explain how it helps reduce errors."
Strong answer structure: Name the five phases in order. For each phase, give one sentence explaining what happens. Then explain how this structure catches errors early, when they are cheaper to fix. Mention the feedback loops: "If testing finds a bug, the team loops back to implementation, not waiting until evaluation."
Avoid these mistakes: Listing phases but not explaining them. Saying "ADDIE makes projects faster" — it's about quality, not speed. Saying "Testing is the last phase" — Evaluation is last, but Testing loops back. Not mentioning why methodology matters.
Questions 1–5 are auto-checked. Questions 6–10 are self-marked — write your answer, then reveal the model answer to check your work.
1. Which phase of ADDIE involves writing the actual code? TYPE 1
2. In ADDIE, what does the Analysis phase determine? TYPE 1
3. What is an advantage of following a structured methodology? TYPE 1
4. Which phase involves checking if the finished software solves the original problem? TYPE 1
5. Which of the following best describes iterative development? TYPE 1
6. Describe what happens in the Design phase of ADDIE. TYPE 2
In the design phase, the team plans how the software will be built. This includes creating system architecture diagrams showing how components connect, designing the database structure, producing user interface mockups, and writing algorithms or pseudocode. A thorough design prevents costly errors during implementation — if the design is flawed, everything built from it will be flawed too.
7. A software testing team finds a bug in the code. Explain what happens next according to ADDIE. TYPE 2
When a bug is found in testing, the developer returns to the implementation phase to fix the code. The tester then re-runs their tests to verify the fix is successful. If the bug reveals a deeper design flaw — for example, the system architecture is fundamentally incorrect — the team may need to return to the design phase before reimplementing.
8. Why is skipping the Analysis phase likely to cause problems later in the project? TYPE 2
Without analysis, developers do not have clear requirements and may build the wrong program entirely. Any misunderstanding of the problem is then embedded in every subsequent stage — the design, implementation and testing are all built on a false assumption. By the time the mistake is discovered, all that work may need to be redone, costing far more time and money than a proper analysis would have taken.
9. Compare iterative and linear development. Explain which approach is more suitable for a mobile app that will be updated regularly, and justify your answer. TYPE 3
In linear development, each ADDIE phase must be fully completed before the next begins — analysis is finished, then design, then implementation, with no going back. In iterative development, work moves through phases in smaller cycles, with testing feeding back to earlier stages repeatedly throughout the project. For a mobile app, iterative development is more suitable because user expectations and market conditions change quickly. Small, frequent releases allow real user feedback to shape each version of the product, catching problems while they are still cheap to fix. A linear approach risks building a complete product over many months only to find it misses what users actually want. The iterative model also aligns with how app stores work — releasing regular updates in response to feedback is expected and supported by the platform.
10. A project manager says: "Using ADDIE will slow us down. We should just code and see what happens." Evaluate this statement using your knowledge of ADDIE. TYPE 3
This statement is incorrect. While following a methodology adds upfront planning time, it prevents much more expensive problems later. If a developer skips straight to coding, any errors in understanding the problem are built into every subsequent phase — fixing them after implementation means potentially rewriting large sections of code. A bug caught in the design phase costs very little to fix; the same bug discovered after the system is live can cost hundreds of hours and may damage the client relationship permanently. The project manager is comparing the visible cost of planning (a few days of analysis and design) against the invisible cost of skipping it (weeks of debugging, rework, and scope creep). ADDIE-compliant projects typically finish faster overall because time is spent solving each problem once, not rediscovering it repeatedly. The statement confuses short-term speed with total project efficiency.
Suggested timing
Approximately 60 minutes. Warm up 5 min · Notes 20 min · Examples 15 min · Now You Try 5 min · Task set remainder. Can be extended with group discussion on real-world case studies.
Key points to emphasise
- Methodology is not bureaucracy — it's a tool to reduce errors and improve quality
- ADDIE appears linear but is iterative: testing loops back to implementation
- Catching errors in design is much cheaper than catching them after release
- The feedback loop from evaluation leads to version 2, so development is cyclical
Common misconceptions
- Pupils often think ADDIE is sequential with no loops — clarify that testing feeds back
- Some think "methodology" means "slow" — it actually prevents costly rework
- Confusion between analysis (WHAT) and design (HOW) — address explicitly
Past paper tips
Recent papers ask pupils to describe ADDIE phases or explain why methodology matters. Pupils often list phases but don't explain the purpose or feedback loops. Strong answers mention the iterative nature and error prevention. See also: 2025 Q1, 2024 Q2, SQP Q3.
Extension activity
Show a case study of a failed software project (e.g., NHS IT systems that went over budget). Ask: "Which ADDIE phase was skipped or done poorly?" Pupils often identify that bad analysis or skipped design caused the failure — good discussion prompt before Q10.
SQA command words covered
"Describe" (phases), "Explain" (why methodology matters, feedback loops), "Compare" (iterative vs linear), "Evaluate" (a given statement).