Software Design & Development · Development Methodologies

SDD1 — Development Methodologies

📅 Thu 13 Aug 2026 · P3+P4 (double)

⏱ ~120 minutes

Learning intentions

I can describe the iterative development process and name its seven stages 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 seven stages 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 stages or practices followed in a particular order.

Iterative development process

A methodology with seven ordered stages, where later work can send development back to any earlier stage that needs to be revisited.

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.

Stage

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.

Maintenance

Updating software after release to correct faults, adapt it to new needs, or improve its performance.

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 organises work into seven stages: analysis, design, implementation, testing, documentation, evaluation, and maintenance. The stages give the project a clear order, which makes the process a good fit for projects with stable requirements and careful upfront planning. However, the path is not one-way. When work in a later stage exposes a problem, the team returns to whichever earlier stage needs to be revisited, corrects the issue, and then continues forward again. That ability to revisit earlier work is what makes the process iterative.

Stage 1

AnalysisUnderstand the problem: purpose, scope, boundaries, functional requirements

↓

Stage 2

DesignPlan the solution: structure diagrams, pseudocode, wireframes

↓

Stage 3

ImplementationWrite the actual code based on the design

↓

Stage 4

TestingCheck the software works correctly; find and fix errors

↓

Stage 5

DocumentationRecord how the software works, for future developers and users

↓

Stage 6

EvaluationJudge how well the completed solution meets its requirements

↓

Stage 7

MaintenanceCorrect, adapt, or improve the software after release

Iteration can happen from any later stage. Testing might reveal that the design logic is wrong, so the team returns to design. Evaluation might reveal a missed requirement, so the team returns to analysis. Maintenance might uncover a fault that requires changes to design, implementation, testing, and documentation. The team does not have to wait until evaluation or maintenance, and it does not always restart at analysis: it loops back to the relevant earlier stage.

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 rather than being reserved for one distinct lifecycle stage
Teams are small, collaborative, and self-managing

Comparing the two

Both methodologies involve analysing, designing, implementing, testing, documenting, evaluating, and maintaining software, but they organise that work very differently. The table below summarises the key differences examined at Higher.

Feature	Iterative	Agile
Requirements	Defined during analysis, then revisited if later work exposes a problem	Expected to change; welcomed
Lifecycle organisation	Seven ordered stages; later work can return to any relevant earlier stage	Short sprints repeat the development work and produce working software
Client involvement	Mainly at planned review points, including analysis and evaluation	Continuous — reviews every sprint
Evaluation	A distinct stage after documentation; findings can trigger earlier work to be revisited	Continuous — within every sprint
Maintenance	A distinct seventh stage after evaluation; maintenance findings can start another iteration	Improvements and fixes can be prioritised into future sprints
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

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.

Because the requirements are legally fixed and unlikely to change, the team can begin with a thorough analysis and plan the later stages in detail. If testing, evaluation, or maintenance exposes a problem, the team can still return to the relevant earlier stage.

A large team of specialists working across different departments suits the iterative process's defined roles and hierarchy — each stage 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

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.

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.

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

Task: A pupil is asked to describe two differences between how evaluation and feedback are handled in iterative versus agile development.

Difference 1 — Timing: iterative development includes evaluation as a distinct sixth stage, after documentation and before maintenance; agile evaluates working software continuously within each sprint.

Difference 2 — Using findings: in iterative development, a problem found during testing, evaluation, or maintenance sends the team back to whichever earlier stage needs correction; in agile, regular client feedback is used to adjust priorities for the next sprint.

✓

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.

⚠️ Common mistakes — examiner feedback

Naming only some of the seven iterative stages, leaving out maintenance, or listing documentation and evaluation in the wrong order
Thinking "iterative" means no planning — it still follows the seven stages in order while allowing relevant earlier work to be revisited
Drawing iteration only as Evaluation → Analysis — a problem found in any later stage can return the team to whichever earlier stage needs correction
Forgetting that agile's evaluation happens continuously within every sprint rather than in one distinct evaluation stage
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 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)

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)

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)

📁 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 stages — draw the process 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.