How does a structured development process turn a vague problem into reliable, maintainable software?
Describe and compare iterative (agile) and structured (waterfall) development methodologies, and apply the analysis, design, implementation, testing, documentation, evaluation and maintenance stages of the software development process.
A focused answer to the SQA Advanced Higher Computing Science content on development methodologies, covering iterative agile and structured waterfall approaches and every stage of the software development process from analysis to maintenance.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
The SQA wants you to describe the full software development process and to compare the two methodologies that organise it: the iterative (agile) approach and the structured (waterfall) approach. You need to know what happens at each stage, what each stage produces, and when each methodology is the better fit.
The stages of the software development process
Every methodology arranges the same underlying work. Know what each stage delivers.
The structured (waterfall) methodology
In a waterfall approach the stages flow downwards in a single pass: analysis, then design, then implementation, then testing, and so on. Each stage is completed and formally signed off before the next starts, and you only return to an earlier stage to fix a defect. The strength is a clear, heavily documented plan; the weakness is that a requirement missed at analysis is expensive to fix once you are deep into implementation.
The iterative (agile) methodology
An agile approach breaks the work into short iterations (often one to four weeks). Each iteration is a miniature pass through design, build and test that ends with a working, demonstrable increment of the software. The customer reviews each increment and steers the next, so changing requirements are handled cheaply. Agile values working software, customer collaboration and responding to change over comprehensive documentation and rigid plans.
Comparing the two methodologies
The choice is a trade-off, not a verdict that one is always better.
- Handling change. Agile absorbs changing requirements each iteration; waterfall resists change once a stage is signed off.
- Feedback. Agile gives the customer working software early and often; waterfall delivers only at the end.
- Documentation. Waterfall produces heavy documentation at each stage; agile keeps documentation lighter, favouring working code.
- Predictability. Waterfall gives a clearer up-front cost and timetable; agile trades some predictability for flexibility.
- Team and project fit. Agile suits small, communicative teams and uncertain problems; waterfall suits large, regulated projects with fixed requirements.
Try this
Q1. Name the stage of the software development process that produces the software specification. [1 mark]
- Cue. Analysis.
Q2. Give one reason an agile methodology suits a project with frequently changing requirements. [1 mark]
- Cue. Each short iteration can take on the new requirements without scrapping a frozen up-front specification.
Exam-style practice questions
Practice questions written in the style of SQA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
AH style: methodology4 marksA small team is building a fitness-tracking app for a client whose requirements are likely to change as they see early versions. Recommend a development methodology and justify your choice with two reasons.Show worked answer →
Recommend an iterative (agile) methodology (1 mark). Justification one: agile delivers the software in short increments, so the client sees working features early and can give feedback (1 mark). Justification two: requirements that change part-way through are absorbed in the next iteration rather than forcing an expensive return to a frozen specification, as a waterfall approach would (1 mark). A final mark is available for noting that agile suits a small co-located team because it relies on frequent face-to-face communication over heavy documentation (1 mark).
AH style: process stages3 marksState three pieces of documentation produced across the software development process and the stage that produces each.Show worked answer →
Any three, one mark each, for example: a software specification produced at the analysis stage (1 mark); a structure or class diagram produced at the design stage (1 mark); a test plan with expected results produced before or during testing (1 mark). Other valid answers include user and technical documentation produced at the documentation stage, or an evaluation report at the evaluation stage. Markers want the document correctly paired with its stage.
Related dot points
- Describe and implement object-oriented programming using classes, objects, instantiation, attributes and methods, encapsulation, inheritance, and polymorphism through method overriding.
A focused answer to the SQA Advanced Higher Computing Science content on object-oriented programming, covering classes and objects, instantiation, encapsulation, inheritance and polymorphism through method overriding, with UML class diagrams.
- Describe and implement the data structures used in Advanced Higher: one- and two-dimensional arrays, records, sequential files, linked lists, stacks and queues, including their operations.
A focused answer to the SQA Advanced Higher Computing Science content on data structures, covering one- and two-dimensional arrays, records, sequential files, linked lists, stacks and queues with their core operations.
- Describe and implement the standard searching and sorting algorithms (linear and binary search, bubble, insertion and quicksort), explain recursion, and compare algorithm efficiency.
A focused answer to the SQA Advanced Higher Computing Science content on standard algorithms, covering linear and binary search, bubble, insertion and quicksort, recursion, and comparing the efficiency of algorithms.
- Plan and carry out testing using normal, extreme and exceptional data and dry runs with trace tables, and evaluate software for fitness for purpose, robustness, efficiency and maintainability.
A focused answer to the SQA Advanced Higher Computing Science content on testing and evaluation, covering normal, extreme and exceptional test data, dry runs and trace tables, and evaluating software for fitness for purpose, robustness, efficiency and maintainability.