Software Design & Development · Development Methodologies
SDD1 — Development Methodologies
📅 Tue 2 Jun 2026 · P3 (single)
⏱ ~60 minutes
Learning intentions
I can describe the iterative development process and name its six phases in order
I can describe agile methodology and how it differs from iterative development
I can compare the two methodologies and justify which suits a given scenario
Success criteria
I can name all six phases of the iterative development process in order
I can give at least two differences between iterative and agile
I can read a scenario and justify which methodology is more appropriate
Warm up — before we start
Quick recap of National 5 software development basics · check when done
Question 1
Which stage of software development happens first, before any design or coding begins?
Question 2
Which stage of software development involves actually writing the code?
Question 3
What is the term for checking that a program works correctly and finding any errors?
Key vocabulary
Methodology
An organised approach to carrying out a software project — a set of phases or practices followed in a particular order.
Iterative development process
A methodology that breaks work into six repeated phases, refining the software each time round the cycle.
Agile methodology
A methodology where requirements and solutions evolve through short cycles and continuous client collaboration.
Sprint
A short, fixed-length cycle in agile development (typically 1–4 weeks) that produces a working piece of software.
Phase
One distinct stage of a development methodology, e.g. analysis, design, or testing.
Documentation
Written records describing how software works, produced for future developers and users.
Choosing how to build software
Before any software project begins, a development team must agree on a methodology — an organised approach that decides how the work will be planned, carried out, and reviewed. Two methodologies are covered at Higher: the iterative development process, which has been used for decades and favours careful upfront planning, and agile methodology, which emerged as a faster, more flexible alternative. Choosing the right methodology for a project affects everything that follows — how the team is organised, how much is documented, and how quickly problems are caught.
The iterative development process
Software is rarely built perfectly the first time. The iterative development process breaks work into six phases, each one feeding into the next. Once the final phase (evaluation) is complete, the cycle can loop back to analysis to refine the software further — this is why it is called iterative. Each phase is normally completed in full before the next one begins, which makes this a good fit for projects with clear, stable requirements.
Phase 1
AnalysisUnderstand the problem: purpose, scope, boundaries, functional requirements
↓
Phase 2
DesignPlan the solution: structure diagrams, pseudocode, wireframes
↓
Phase 3
ImplementationWrite the actual code based on the design
↓
Phase 4
TestingCheck the software works correctly; find and fix errors
↓
Phase 5
DocumentationRecord how the software works, for future developers and users
↓
Phase 6
EvaluationCheck how well it meets requirements → loops back to Analysis
Agile methodology
Agile emerged in the early 2000s as a response to the rigidity of the iterative approach. In agile, requirements and solutions evolve through collaboration between self-organising teams and the client throughout the project, rather than being fixed at the start.
Work is broken into short cycles called sprints (typically 1–4 weeks)
Each sprint produces a working, testable piece of software — not just documents
The client is involved throughout, reviewing output after every sprint
Requirements are expected to change — the process adapts to them
Evaluation happens continuously within every sprint, not just at the end
Teams are small, collaborative, and self-managing
Comparing the two
Both methodologies cover the same underlying work — analysis, design, coding, testing, evaluation — but organise it very differently. The table below summarises the key differences examined at Higher.
Feature
Iterative
Agile
Requirements
Defined at start of each cycle
Expected to change; welcomed
Client involvement
At start (analysis) and end (evaluation)
Continuous — reviews every sprint
Evaluation
At end of each iteration
Continuous — every sprint
Team structure
Defined roles and hierarchy
Small, self-organising, cross-functional
Best suited for
Clear, stable requirements
Unclear or changing requirements
Risk
Problems found late if requirements were wrong
Lower — problems caught each sprint
Worked examples
Example 1 — Applying the iterative process
1
Scenario: A government department needs new payroll software. The requirements are set by law and cannot change. The project has a fixed budget, a fixed deadline, and a large team of specialists in different departments.
2
Because the requirements are legally fixed and unlikely to change, the team can complete a thorough analysis once at the start and trust it will remain valid.
3
A large team of specialists working across different departments suits the iterative process's defined roles and hierarchy — each phase can be handed cleanly from one specialist team to the next.
✓
Conclusion: The iterative development process is more appropriate here, because the requirements are fixed and the large, specialised team structure matches iterative's defined roles.
Example 2 — Applying agile methodology
1
Scenario: A small start-up is building a new social media app. They have a rough idea of what they want but expect features to evolve based on early user feedback. They have a team of 5 developers who meet daily.
2
Because the team expects requirements to change as they learn from user feedback, agile's adaptive approach — where requirements are welcomed to change between sprints — fits better than a methodology that fixes requirements upfront.
3
A small team of 5 who meet daily matches agile's preference for small, self-organising, cross-functional teams with fast, face-to-face communication.
✓
Conclusion: Agile is more appropriate here, because the start-up expects changing requirements and has a small, collaborative team — both are strong matches for agile's characteristics.
Example 3 — Identifying differences from a scenario
1
Task: A pupil is asked to describe two differences between how evaluation is carried out in iterative versus agile development.
2
Difference 1 — Timing: in iterative development, evaluation happens once, at the end of each full cycle; in agile, evaluation happens continuously, at the end of every sprint.
3
Difference 2 — Who is involved: in iterative development, the client is typically only involved again at the evaluation phase; in agile, the client reviews and gives feedback throughout, not just at fixed checkpoints.
✓
Both differences are stated as a direct comparison ("in iterative... whereas in agile...") rather than describing only one methodology — this is what full marks require.
Now you try
A small start-up is building a new social media app. They have a rough idea of what they want but expect features to evolve based on early user feedback. They have a team of 5 developers who meet daily.
Write: which methodology is more appropriate, and give two reasons for your answer, referring directly to the scenario.
Agile would be more appropriate. First, the scenario states that the start-up "expects features to evolve based on early user feedback" — agile welcomes changing requirements between sprints, whereas iterative development expects requirements to be fixed at the start. Second, the scenario describes "a team of 5 developers who meet daily" — this small, collaborative, fast-communicating team matches agile's preference for small, self-organising teams, rather than iterative's larger, more hierarchical team structure.
⚠️ Common mistakes — examiner feedback
Naming only some of the six iterative phases, or listing them out of order
Thinking "iterative" means no planning — it still requires full analysis and design each cycle, just repeated
Forgetting that agile's evaluation happens continuously, every sprint, not just once at the end
Confusing a "sprint" with unplanned, unstructured coding — a sprint is still a short, structured cycle with a clear goal
Giving a generic answer that doesn't refer to the specific scenario given in the question
📝 Exam tip
Always put your answer in context. Don't just write a definition — explain why it applies to the scenario. For example: "Agile would be more suitable because the client frequently changes their requirements, and agile welcomes changing requirements between sprints." Quoting or closely paraphrasing details from the scenario shows the examiner your reasoning is scenario-specific, not a memorised generic answer.
Task Set A — Core questions
Task Set A — Core questions
Work through all questions, then check your answers.
Question 1
Which phase of the iterative development process comes immediately before Testing?
Question 2
Which best describes an agile "sprint"?
Question 3
Agile organises work into short, fixed-length cycles called what?
Question 4
A project has requirements set by law that cannot change, a fixed budget and deadline, and a large team of specialists. Which methodology is more appropriate?
Question 5
What is the name of the final phase of the iterative development process, after which the cycle can loop back to Analysis?
Question 6
Describe two differences between how evaluation is carried out in iterative development compared with agile. (2 marks)
Model answer
Question 7
Which of the following is NOT one of the six phases of the iterative development process?
Question 8
Name the phase of the iterative development process where structure diagrams, pseudocode, and wireframes are created.
Question 9
A school canteen wants to try a lunch pre-ordering app for a term and adjust it based on how pupils actually use it. Two developers will build it, working closely together. Which methodology is more appropriate, and why? Refer to the scenario. (3 marks)
Model answer
Question 10
What term describes an organised approach to carrying out a software project, made up of a set of phases or practices followed in order?
Task Set B — Extension
Task Set B — Extension · Beyond the specification
Longer written answers — no auto-check. Discuss your answers with your teacher.
Extension 1
A company says: "We always know exactly what the client wants before we start, so agile is a waste of time." Do you agree? Justify your answer, considering when this claim might and might not hold true. (4 marks)
Model answer
Extension 2
Think of an app on your phone. Which methodology do you think was used to build it, and why? Would your answer change comparing the app when it first launched versus how it is now? (3 marks)
Model answer
Extension 3
Some real projects use a hybrid of both methodologies. Suggest how a team might combine ideas from iterative development and agile, and explain why this could be useful. (3 marks)
Model answer
📁 File this in OneNote under: Higher Computing Science → Software Design & Development → SDD1
📌 Teacher notes — not for pupils
Single period — keep it moving. No code today, which is deliberate: it gives the mixed-ability class an equal starting point before Python begins next week.
Suggested timing: 5 min warm-up · 5 min vocab · 15 min iterative phases — draw the cycle on the board as you go through the flow-pipeline · 10 min agile + comparison table · 10 min worked examples (read through 1–2 together, let pupils attempt 3 independently) · 5 min "now you try" · remaining time into Task Set A, finishing for homework if needed.
Common pupil confusion: they often have stronger opinions in Task Set B's discussion-style questions at this level — use this to model good scenario-based reasoning for the group, since this exact skill (always reference the scenario) is tested repeatedly in later SDD lessons.
Task Set B is unlikely to be finished in the single period — set as homework or revisit briefly at the start of SDD2.