A development method organises learning, decisions and delivery. Choose it by requirement stability, risk, feedback and constraints, then explain how those characteristics affect the project.
Content owner: Michael Print · Written for A-Level learners · Checked against official specifications
The idea to start with
Waterfall emphasises sequential phases and agreed outputs; agile uses short feedback-driven iterations; extreme programming adds disciplined engineering practices; spiral organises iterations around risk; rapid application development emphasises fast prototyping and user involvement.
A sound algorithm states inputs, outputs, preconditions, decisions, repetitions and termination. Trace the actual rules, including zero/boundary cases, before trusting a design.
OCR H446 · 1.2.3(a–c)
Before you start
Useful foundations
Requirements and test cases
Sequence, selection and iteration
By the end, you should be able to
Explain the activities and trade-offs of five named methods
Justify a method for an unfamiliar scenario
Trace an algorithm using explicit bounds
Design an algorithm from measurable requirements
Waterfall
Waterfall phases produce agreed outputs for the next phase, making progress and documentation visible. Stable requirements and contractual approval gates fit review of scope/design before extensive implementation.
Late discoveries can be expensive if they require revisiting earlier decisions. Users may not see a working system early enough to correct misunderstandings. Waterfall does not mean testing is unimportant or that maintenance never feeds back: it means phase sequencing dominates the organisation.
Explain the change cost in the scenario rather than claiming no phase can ever be revisited.
A typical waterfall sequence
1
Analysis
Establish the problem and agreed requirements.
2
Design
Explain the solution before building it.
3
Implementation
Build the designed solution.
4
Testing
Check behaviour against the requirements.
5
Deployment
Make the checked system available for use.
6
Maintenance
Support and adapt it over time.
Phase sequencing dominates, but later findings can still require revisiting earlier decisions.
Agile: feedback changes the next increment
Agile approaches deliver small increments, seek frequent customer feedback and adapt priorities as understanding develops. A prioritised backlog and short iterations can expose useful functionality early. This suits uncertain requirements and an available stakeholder, but changing priorities can make fixed total cost/scope difficult.
Documentation and testing still matter; agile is not permission to improvise without a design.
Extreme programming: engineering practices within agile
Extreme programming (XP) is an agile approach emphasising practices such as small releases, pair programming, automated tests/test-driven development, continuous integration and refactoring. In test-driven development a developer first writes a failing test for the next behaviour, implements it, then refactors while retaining passing tests.
Pairing provides immediate review but requires coordination and staff time. Frequent integration catches conflicts early; it does not replace testing requirements or usability.
Spiral development
The spiral model repeats cycles that establish objectives/options, analyse risks, develop/validate a solution and plan the next cycle. A prototype may investigate a particular risk before committing to an expensive design.
For example, a system requiring unusually low sensor latency can prototype that performance first rather than building all interfaces before discovering the limit.
Risk analysis can improve decisions for large, complex or uncertain systems, but costs expertise and time. It is not the same as simply rewriting a product several times.
Explain which risk is being investigated, what evidence reduces uncertainty and how that evidence changes the next development decision.
Rapid application development
RAD emphasises timeboxed rapid prototyping, strong user involvement and reuse/tools to produce working interfaces or components quickly. A small internal form-and-report system with an available user can suit it: a prototype reveals misunderstood fields much earlier than a static description.
A quick prototype can encourage poor structure if it is treated as finished without checking reliability, security, performance and maintainability. RAD is harder when the system has tightly coupled complex components, users cannot supply feedback or a prototype cannot test the important constraint.
Speed of initial construction is one criterion; quality and long-term support remain requirements.
Select a method with a reason chain
Use requirement stability, consequence of failure, feedback availability, scale, integration, deadline and team skills. A payroll change with tightly prescribed rules and approval evidence may benefit from planned phases; an exploratory booking interface may benefit from short iterations. Safety/performance uncertainty may justify spiral-style risk investigation.
These methods can be combined, so state which practices solve which problem rather than assuming the label guarantees success.
Write and follow an algorithm
Translate the requirement into input/output and constraints before choosing code. Identify what must repeat, when it stops and what happens at boundaries. For a count of non-negative readings, decide whether zero is allowed and whether values arrive in an array or as input.
An empty array must not accidentally access its first element.
A trace table records state changes in execution order. Our pseudocode arrays are zero-based, for i=0 to n-1 includes both endpoints when n>0, and the empty case is explicitly handled. Python range(n) has an exclusive stop.
Keep assignment = distinct from equality ==, and show outputs only when the algorithm outputs them.
Worked example
Choose a method for a changing booking interface
Stakeholders know the booking rules but disagree about how to display available sessions. Deliver a small interactive increment early, gather feedback and adjust the interface in later iterations: an agile approach is justified by uncertainty and accessible users.
Use automated tests for fixed availability rules and continuous integration to catch regressions. A rapid prototype may resolve interface choices, but separately test simultaneous bookings and access controls before release.
If a new external service has uncertain latency, investigate that risk with a focused prototype. A method choice should respond to evidence, not promise that short iterations remove all risk.
Worked example
Trace a count-and-total algorithm
Requirement: from an array of integer readings, return the count and sum of readings at least 10. Empty input returns (0, 0).
For [8, 10, 14], start count=0 and total=0. Value 8 changes neither; value 10 makes count=1,total=10; value 14 makes count=2,total=24.
The Python implementation has an equivalent empty-array boundary and needs no initial element access. Expected output is (2, 24) and (0, 0).
State after each iteration
Reading
Condition true?
Count
Total
8
No
0
0
10
Yes
1
10
14
Yes
2
24
Runnable Python 3: readings at least 10python
def qualifying_readings(readings):
count = 0
total = 0
for reading in readings:
if reading >= 10:
count += 1
total += reading
return count, total
print(qualifying_readings([8, 10, 14]))
print(qualifying_readings([]))
Original A-Level practice
5 original questions total 20 marks. Attempt each before opening the independently written indicative marking guidance.
Question 1
4 marks
A system has fixed regulated requirements and contractual approval gates. Give a waterfall benefit and a drawback if a major requirement changes late.
Show solution and marking guidance+
Indicative answer
1 mark: phases produce reviewable agreed outputs/documentation.
1 mark: this fits clear requirements and formal approval gates.
1 mark: a late change may invalidate earlier design/implementation.
1 mark: revisiting those phases increases cost/time, so change handling remains necessary.
Question 2
4 marks
Name two XP practices and explain how each can reduce defects.
Show solution and marking guidance+
Indicative answer
1 mark each for two valid practices, such as pair programming, automated tests/test-driven development or continuous integration.
1 mark each for a connected mechanism: immediate review, tests checking specified behaviour/regressions, or early discovery of integration problems. Naming a practice twice earns no additional mark.
Question 3
4 marks
Distinguish spiral development from RAD for a project with uncertain sensor latency and an unsettled interface.
Show solution and marking guidance+
Indicative answer
1 mark: spiral explicitly analyses risks in repeated cycles.
1 mark: a performance prototype can test the sensor-latency risk before large commitments.
1 mark: RAD emphasises rapid prototypes and user involvement.
1 mark: early interface prototypes can reveal usability/field requirements, but do not by themselves establish latency reliability.
Question 4
4 marks
Trace qualifying_readings for [10, 9, 12, 10], and give a boundary test for the comparison.
Show solution and marking guidance+
Indicative answer
1 mark: counts after each reading are 1, 1, 2, 3.
1 mark: totals after each reading are 10, 10, 22, 32.
1 mark: return (3, 32).
1 mark: test [9, 10, 11] to show below/on/above the threshold, with expected (2, 21), or equivalent explicitly justified boundary values.
Question 5
4 marks
Design a function returning the largest integer in a non-empty list. State what to do with empty input.
Show solution and marking guidance+
Indicative answer
1 mark: handle/reject empty input explicitly, for example ValueError.
1 mark: initialise largest to the first actual value, not zero.
1 mark: examine every subsequent value and update largest when a larger one is found.
1 mark: return largest after iteration. Initialising to zero would fail on all-negative data.
Specification and references
This guide addresses OCR H446 1.2.3(a–c). Check your examination year and the complete specification for the assessment scope.
These are independently written explanations and practice questions. CompSciTutoring.co.uk is not affiliated with or endorsed by an examination board. The marking guidance is indicative; always check the syllabus for your examination year.