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 15 Sept 2026
Preview
The whole resource, exactly as a class sees it. Answers and marking are held back.
Comparing and selecting development methodologies
No development methodology is best for every project. OCR questions provide details such as changing requirements, technical risk, access to users, time, team structure and the need for documentation. A strong recommendation uses those details and explains why the chosen process fits them.
Use a constraint lens
Avoid choosing from a single word. A short deadline does not automatically mean RAD, and a large project does not automatically mean spiral. Ask what is uncertain, whether users can give regular feedback, whether rapid prototypes would be useful, whether the team can work closely together, and how much formal control or documentation is required.
Worked recommendation
A small organisation needs a stock-checking interface. Staff can review screens each day, the current workflow is poorly understood and a usable version is needed soon.
- Use the project evidence: the interface is unclear, users are available and the project is small.
- Explain what the method does: RAD produces a prototype quickly and asks the users to evaluate it.
- Explain why that helps: staff can find misunderstandings by trying the interface before the design is fixed.
- Add a limitation: the team must still test data handling and must not treat an early prototype as finished software.
- Reach a judgement: RAD is suitable if staff remain available and testing is protected.
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
- feature
- requirement
- result
- keyword
Guided selection: when the evidence points in different directions
A satellite-data service must connect to expensive, unfamiliar technology. A failure could lose important data. Users can review reports each month, and a regulator requires clear approval records.
Spiral is a strong candidate because the team can identify the most serious technical risks and investigate them before committing to the full system. The need for approval records does not automatically make waterfall the best answer: the team can still produce clear plans, test evidence and review documents during spiral development.
A recommendation can recognise a competing requirement. It should explain which need matters most and how the chosen approach will handle the other one.
Recommend a primary development methodology for the satellite-data service. Explain why it is suitable and why one alternative is less suitable.
Use at least three details from the project. Explain what each compared methodology would do and finish with a qualified conclusion.
Students type their answer here.
The third-party technology is later shown to be reliable, and all requirements are fixed by contract before development begins. Explain how this new evidence could change the recommendation.
Identify what has become less risky, then compare the cost of spiral with the control offered by planned stages.
Students type their answer here.
Compare several possible approaches
The next tasks contain competing project needs. Organise the answer around the project evidence rather than writing a separate memorised paragraph about every methodology.
A regional transport app must provide basic journey planning within four months. Passenger priorities are changing, representatives can review the app every two weeks and connection to live travel data is technically risky. Discuss the relative suitability of waterfall, agile with XP practices, spiral and RAD. Recommend a primary approach.
Compare how the approaches deal with changing priorities, user feedback, the deadline, integration risk and code quality. Explain drawbacks as well as benefits and support the final recommendation.
Students type their answer here.
Explain why each statement is unreliable: (a) waterfall is always cheapest; (b) agile means there is no planning or documentation; (c) spiral is best for every large project; (d) RAD always produces poor code.
For each statement, replace the absolute claim with an accurate condition and explanation.
Students type their answer here.
Review your understanding
Check that each recommendation names relevant project evidence, explains what the methodology does, states why that helps or causes difficulty and reaches a conclusion supported by the comparison.