Loading…
Free A-Level Computer Science guide
An evaluation makes a supported judgement about the final solution. Return to the original problem and success criteria, cite evidence and distinguish achieved behaviour from planned improvements.
Content owner: Michael Print · Written for A-Level learners · Checked against official specifications
For each criterion, state the result, point to the test or feedback that supports it and explain the consequence for the original problem. A partly met criterion needs an honest limitation and a justified next step.
These are fictional teaching exercises. Your assessed project must be your own work. Follow your centre's supervision and authentication rules and OCR section 4e: permitted AI assistance must be acknowledged and its effect made clear; copied output cannot establish your own knowledge, understanding or ability.
OCR H446 · 3.4.1–3.4.4
Useful foundations
By the end, you should be able to
Run planned checks on the complete solution after the last relevant change. A test from an earlier prototype does not automatically prove the final version behaves the same. Include representative normal, boundary and invalid data, plus interactions such as restart/reload and a complete user task.
Compare expected and actual results. If a final test fails, report the failure and its effect. If time permits a correction, identify the updated version and rerun affected checks. Keep final results distinct from the developmental narrative so the reader can see what works now.
Return to each analysed criterion. Correct conflict checks and successful reload are separate claims requiring separate evidence. “All objectives met” does not explain either.
Use achieved, partly achieved or unachieved judgements where helpful, and explain the scope. Passing eight planned conflict cases supports those cases; it does not prove every conceivable input. Consider whether the original measures were appropriate and identify gaps without retroactively pretending the requirement was different.
Criterion
State the original measure being evaluated.
Evidence
Cite a final test identifier/result or appropriate user evidence.
Judgement
Explain what the result means for the original problem and the scope of the claim.
Next step
If partly met, identify the practical limitation and an evidence-based improvement.
| Criterion | Evidence | Judgement / implication |
|---|---|---|
| Eight conflict/boundary cases correct | F1–F8 final test results | Achieved for specified interval policy |
| Reload saved data after restart offline | F9 output differs from expected on malformed file | Partly achieved: valid data reloads; corruption recovery needs work |
| Users find a named activity in trial task | Two observed trials and comments | Promising evidence, but small sample limits generalisation |
Ask representative users to carry out realistic tasks and collect specific feedback. A comment such as 'looks good' does not show that they can recover from a conflict. Observe success, errors and explanations, then relate them to the analysis and interface design.
Balance strengths against limitations. A local file keeps the prototype usable offline but may not support simultaneous coordinators. Explain how that constraint affects the original setting, rather than calling it a minor technical detail without assessing its impact.
Maintenance concerns keeping an existing solution useful: fixing discovered defects, adapting to a changed environment and making changes easier to manage. Clear modular structure, readable names, documented formats and regression checks support this, but require explanation tied to your design.
Prioritise improvements by impact, feasibility and evidence. A reliable recovery path for malformed saved data may matter more than cosmetic animation. Describe the proposed change, its likely benefit, dependencies and how it would be tested. Do not describe an unimplemented proposal as a present feature.
Explain how far the solution addresses the original problem for the intended users and workload. State the most material limitation and the evidence needed before broader use.
A confident but bounded conclusion is stronger than either an unsupported claim of perfection or a vague admission that 'everything could be better'.
Worked example
| Delivered feature | Evidence | Effectiveness judgement |
|---|---|---|
| Preserved room/time values | U2: coordinator changes only time | Supports recovery without re-entering all values |
| Written conflicting-booking identifier | U2: coordinator locates the affected entry | Explains the rejection for this task |
| Colour cue alongside text | Screenshot plus U2 | Additional cue; colour alone would not establish access for all users |
Worked example
5 original questions total 18 marks. Attempt each before opening the independently written indicative marking guidance.
Explain why a successful prototype test from two months earlier is insufficient evidence for the final product. [3]
Indicative answer
An interface preserves entered values and names the conflicting booking. An observed coordinator corrects the time and resubmits successfully. Evaluate the effectiveness of these delivered features, including an evidence limitation.
Indicative answer
A learner writes 'the interface is excellent because one friend likes its colours'. Explain two weaknesses. [4]
Indicative answer
Describe how to evaluate a partly met save/reload criterion. [3]
Indicative answer
Propose one maintenance improvement for the booking prototype and explain how to verify it. [4]
Indicative answer
This guide addresses OCR H446 3.4.1–3.4.4. 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.
Found an error? Email a correction.
Use the free examples first, then explore one-to-one tuition if guided practice would help.