- Understand what a development methodology is and why it matters
- Identify the six phases of the iterative development process: Analysis, Design, Implementation, Testing, Documentation, Evaluation
- Compare iterative and linear development approaches
- Explain how methodologies help reduce errors and improve quality
- You can name and describe all six development 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 the iterative development process, 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 first agree what is needed (analysis), draw the blueprint (design), build it (implementation), inspect it (testing), prepare instructions and maintenance records (documentation), and judge whether 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 six-phase iterative development process
At National 5, software development is described using six phases. They have a logical order, but the process is iterative rather than strictly linear: testing, documentation, or evaluation can reveal a problem that sends the team back to an earlier phase.
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: Documentation
Documentation records how the software works and how to use it. User documentation can include installation instructions, tutorials, screenshots and explanations of error messages. Technical documentation can include commented code, data structures, algorithms, test results and maintenance notes. Clear documentation helps users operate the software correctly and helps developers understand, repair and improve it later. Documentation is updated when the software changes, so it can also reveal unclear features or design decisions that need revisited.
Phase 6: 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
The six phases appear to be linear — one phase after another. In practice, the process is iterative. When testing finds a bug, the team loops back to fix it. When documentation exposes an unclear feature, the design or implementation can be improved. When evaluation finds a missing feature, that feedback starts a new cycle.
- Linear: Complete analysis → design → implementation → testing → documentation → 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 the six-phase development process.
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.
Possible exam question: "Describe the stages of the iterative development process and explain how it helps reduce errors."
Strong answer structure: Name all six phases in order, including documentation. For each phase, give one sentence explaining what happens. Then explain how feedback catches errors early, when they are cheaper to fix: if testing finds a bug, the team returns to implementation and repeats the necessary work.
Avoid these mistakes: Listing phases without explaining them; forgetting documentation; claiming the process must always move in one direction; or saying testing is the final phase.
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 development phase involves writing the actual code? TYPE 1
2. In the development process, what does the Analysis phase determine? TYPE 1
3. What is an advantage of following a structured methodology? TYPE 1
4. Which phase produces user guides and technical maintenance information? TYPE 1
5. Which of the following best describes iterative development? TYPE 1
6. Describe what happens in the Design phase of the development process. 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 in an iterative development process. 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 of the six phases must be fully completed before the next begins — analysis, design, implementation, testing, documentation and evaluation — with no going back. In iterative development, work moves through phases in smaller cycles, with findings 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 supports regular updates, with documentation kept current as the app changes.
10. A project manager says: "Using a structured development process will slow us down. We should just code and see what happens." Evaluate this statement using your knowledge of the six phases. 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, errors in understanding the problem are built into later phases, and fixing them may require rewriting large sections of code. A bug caught in design costs little to fix; the same bug discovered after release can cost hundreds of hours and damage the client relationship. Testing checks the implementation, documentation supports users and future maintenance, and evaluation judges fitness for purpose. The project manager is comparing the visible cost of planning against the hidden cost of debugging, rework, missing documentation and scope creep. A structured, iterative process uses feedback to solve problems early and keep the product aligned with its requirements.
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
- All six phases matter, including documentation
- The process is iterative: testing can loop 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 the process is strictly sequential — clarify that later findings feed back
- Some think "methodology" means "slow" — it actually prevents costly rework
- Confusion between analysis (WHAT) and design (HOW) — address explicitly
Past paper tips
Questions may ask pupils to describe development phases or explain why a structured process matters. Pupils should name all six phases, explain their purposes, and mention the iterative feedback that helps prevent errors.
Extension activity
Show a case study of a failed software project. Ask: "Which development phase was skipped or done poorly?" Pupils often identify that bad analysis or skipped design caused the failure — a useful discussion prompt before Q10.
SQA command words covered
"Describe" (phases), "Explain" (why methodology matters, feedback loops), "Compare" (iterative vs linear), "Evaluate" (a given statement).