Skip to main content
ScotlandComputer ScienceSyllabus dot point

How is software developed in stages, and how do iterative and agile approaches differ from the traditional waterfall process?

The iterative software development process (analysis, design, implementation, testing, documentation and evaluation) and the difference between the traditional waterfall approach and agile methodologies.

An SQA Higher Computing Science answer on the software development process, covering the seven iterative stages from analysis to maintenance, and the difference between the traditional waterfall model and agile methodologies.

Generated by Claude Opus 4.811 min answer

Reviewed by: AI editorial process; not yet individually human-reviewed

Have a quick question? Jump to the Q&A page

Jump to a section
  1. What this key area is asking
  2. The stages of the software development process
  3. Why the process is iterative
  4. The waterfall model
  5. Agile methodologies
  6. Examples in context
  7. Try this

What this key area is asking

The SQA wants you to know the stages software passes through as it is developed, to explain why the process is iterative, and to compare the traditional waterfall model with agile methodologies. You should be able to recommend an approach for a given scenario and justify it.

The stages of the software development process

Software is not written in one go. It moves through a sequence of stages, each producing something the next stage depends on.

  • Analysis. Work out exactly what the program must do. The output is a requirements specification: the purpose, the scope (what is and is not included) and the functional requirements, agreed with the client.
  • Design. Plan how the program will meet the requirements: the structure of the code, the algorithms and the user interface. Notations such as structure diagrams, flowcharts and pseudocode are used here.
  • Implementation. Write the actual program code in a chosen language, turning the design into working software.
  • Testing. Run the program against systematic test data (normal, extreme and exceptional) to find errors and confirm it meets the requirements.
  • Documentation. Produce the user guide (how to use the software) and the technical guide (installation, hardware and software requirements).
  • Evaluation. Judge the finished software against the requirements specification: is it fit for purpose, robust, efficient and readable?
  • Maintenance. After release, fix faults (corrective), adapt to new environments (adaptive) and add improvements (perfective).

Why the process is iterative

This matters because real projects are rarely understood perfectly at the start. Iteration lets understanding improve as the work proceeds, so the stages are revisited rather than ticked off once and forgotten.

The waterfall model

The waterfall model is the traditional approach. The stages run strictly in order, each completed and signed off before the next begins, like water flowing down a series of steps. The requirements are fixed at the start.

Its strength is that it is simple to manage and document, and it suits projects where the requirements are stable and well understood, such as a system replacing an existing one with the same behaviour. Its weakness is that changes discovered late are expensive, because going back means revisiting completed, signed-off stages, and the client does not see working software until near the end.

Agile methodologies

Agile suits projects where the requirements are likely to evolve, the client is unsure of the final product, or fast delivery of a usable version matters. Its trade-off is that less detailed documentation is produced up front, and it relies on close, ongoing collaboration with the client.

Examples in context

Most large commercial software, such as mobile apps and web services, is now built with agile methods (for example Scrum), releasing updates every few weeks so users get features quickly and the team responds to feedback. Safety-critical systems, such as aircraft control software, lean towards a more rigorous, heavily documented and verified process closer to waterfall, because every requirement must be proven before release. Many real teams blend the two: a broad waterfall-style plan with agile iterations inside it.

Try this

Q1. Name the stage of the development process where the requirements specification is produced. [1 mark]

  • Cue. Analysis.

Q2. State one strength and one weakness of the waterfall model. [2 marks]

  • Cue. Strength: simple to manage with clear documentation, good for stable requirements. Weakness: late changes are expensive and the client sees working software only near the end.

Q3. Explain why an agile approach suits a project with evolving requirements. [2 marks]

  • Cue. Each short iteration delivers a working increment the client reviews, so the team adapts the design as the requirements become clear.

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.

SQA Higher (style)4 marksDescribe two stages of the software development process, and explain why the process is described as iterative rather than a one-way sequence of steps.
Show worked answer →

Pick any two stages and describe each. Analysis is where the developer works out exactly what the program must do and produces a requirements specification agreed with the client. Testing is where the working program is run against systematic test data to find errors and confirm it meets the requirements.

The process is iterative because developers move backwards as well as forwards between stages. A problem found during testing sends the team back to design or implementation; a requirement clarified during design can change the analysis. Each pass refines the solution, so the stages are revisited rather than completed once and abandoned.

Markers reward a correct description of two named stages and a clear explanation that iteration means returning to earlier stages, not a single straight-through sequence.

SQA Higher (style)3 marksA small team is building a mobile app for a client who is unsure of the final requirements. Recommend an agile approach rather than the waterfall model and justify your choice.
Show worked answer →

Recommend an agile methodology.

Justification: agile delivers the software in short iterations, each producing a working increment that the client can review. Because the client is unsure of the requirements, the frequent feedback lets the team adapt the design as needs become clear, rather than committing to a fixed specification at the start.

The waterfall model would force the requirements to be fixed up front and completed in strict order, which is risky here because changes discovered late are expensive to make. Agile welcomes changing requirements, so it fits an evolving brief.

Markers reward recommending agile, explaining its short feedback-driven iterations, and contrasting this with the rigid up-front, sequential nature of waterfall.

Related dot points

Sources & how we know this