Community resourceWorksheet
OCR H446 1.2.3 Comparing and selecting methodologies
Part 3 of 6 · H446 1.2.3 · Software development
There is no universal best methodology in H446 1.2.3, only a choice defended from the evidence a context supplies. This worksheet drills the selection routine, reading the constraints, naming a process mechanism, stating its consequence and admitting a cost, then revising the choice when new facts arrive.
Students will:
- extract the constraints that matter from a described project brief
- connect a process mechanism to a constraint and then to a project consequence
- recommend a methodology and explain why a named alternative fits less well
- revise a recommendation when new evidence removes a risk or fixes a requirement
- explain why blanket slogans about cost, planning or code quality are unsafe
Inside: 6 explanation cells, 1 multiple-choice question, 2 fill-in-the-blanks cells and 4 written answers. 40 marks, about 45 to 60 minutes.
Series: H446 1.2.3 · Software development, part 3 of 6.
Shared by Coding PathwayVerified teacher
- 13 cells
- About 45 minutes
- CC BY-SA 4.0
- Shared 31 Aug 2026
- Updated 3 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Comparing and selecting methodologies
There is no universal best methodology. Examination contexts supply evidence; strong answers identify a process mechanism, connect it to a constraint, state the consequence and acknowledge a cost or condition.
Use a constraint lens
A trigger-word answer says “deadline → RAD” or “complex → spiral”. A reasoned answer asks whether users can evaluate prototypes, whether uncertainty is mainly usability or high technical risk, whether requirements are stable, and what control/documentation the project needs.
Worked reasoning routine
Project: a small internal stock-checking interface. Staff can review screens daily; the workflow is poorly understood; an operational version is needed soon.
- Evidence: unclear interface/workflow, available users, short timescale, small internal scope.
- Candidate mechanism: RAD produces a prototype quickly and staff evaluation refines it.
- Consequence: misunderstandings are found through use before the final interface is fixed.
- Limitation: staff time is required and rapid prototypes must not become untested production code.
- Judgement: RAD is suitable if the team protects testing/data integrity while iterating.
Which new fact most weakens a recommendation of RAD for the stock interface?
- AThe first screen has three input fields
- BThe organisation owns computers
- CStaff cannot attend reviews until after deployment
- DThe developer can draw a prototype
- mechanism
- constraint
- consequence
- keyword
Guided selection: competing evidence
A satellite-data service has expensive integration, uncertain third-party technology and severe failure costs. Users can review reports monthly, but a regulator also requires traceable approval evidence.
Spiral directly addresses unresolved technical/failure risk. Planned waterfall-style deliverables may still support traceability. A well-reasoned answer can recommend spiral while explaining how formal stage evidence is retained; it need not pretend one label removes every trade-off.
Recommend a primary methodology for the satellite-data service and explain why one alternative is less suitable.
Apply at least three supplied constraints and reach a qualified conclusion.
Students type their answer here.
The third-party technology becomes proven and requirements are contractually fixed before development. Explain how this new evidence could change the recommendation.
A justified recommendation should be revisable when its assumptions change.
Students type their answer here.
Apply the model independently
The remaining tasks change the context or reduce the support. Complete them without copying the worked model, then check that each explanation connects a mechanism to its consequence.
A regional transport app must launch basic journey planning in four months. Passenger priorities are changing, representatives can review every two weeks, and live-data integration is technically risky. Discuss how waterfall, agile/XP, spiral and RAD could contribute, then recommend a primary approach.
Compare mechanisms rather than writing four independent definitions. Apply deadline, changing priorities, user access, integration risk and code quality. Acknowledge limitations and reach a supported judgement.
Students type their answer here.
Explain why each slogan is unsafe: (a) waterfall is always cheapest; (b) agile means no planning or documentation; (c) spiral is best for every large project; (d) RAD always produces poor code.
Replace each absolute with a condition and mechanism.
Students type their answer here.
Review your understanding
Before submitting, check that you can explain the main distinction in your own words, apply it in an unfamiliar context and justify each consequence rather than only naming a feature.