Loading...
Evaluation turns tests and user evidence into a reasoned judgement about the outcome. Address each success criterion and explain what maintenance or further work would resolve genuine limitations.
What you'll be able to do
Post-development testing checks the integrated result, not just isolated routines tested earlier. Use evidence of functionality and robustness, including relevant invalid input, empty data, repeated actions and boundary conditions. The scope follows the actual system and its requirements; a universal list of screenshots does not prove every project’s behaviour.
Usability evidence investigates how intended users carry out meaningful tasks. Record the task, observed difficulty or feedback and relevant conditions. A positive opinion about appearance does not establish numerical correctness or prove that a task can be completed without help. Likewise a passing unit test does not establish that users understand the interface. Both forms of evidence can matter, for different claims.
For each success criterion from analysis, identify relevant evidence and explain whether it is met, partly met or unmet. Cross-reference specific development and final tests rather than claim success because the program opens. Discuss the effectiveness of usability features from the design, including shortcomings and the effects on the intended user.
The evaluation allocation is 20 marks, comprising 5 for testing to inform evaluation and 15 for evaluation of the solution. The latter rewards a clear evidence-supported line of reasoning, not a congratulatory feature list. A failed or partially met criterion should lead to an honest explanation of its cause, practical impact and feasible next action. Do not silently rewrite the original criterion just to make it appear achieved.
Maintainability concerns how easily the program can be understood, corrected and adapted. Consider modularity, naming, interfaces, documentation, validation and external dependencies. Explain a concrete maintenance risk, such as a file format changing while parsing assumptions remain scattered through several routines, and how a defined interface or tests could reduce it.
A development proposal should name a demonstrated limitation, a plausible change and an expected benefit or trade-off. If performance was not measured on larger data, describe that uncertainty and propose a representative test rather than claim unlimited scalability. Distinguish work already completed from a future intention. Final evidence should remain reviewable under current centre submission instructions, with sources and permitted assistance acknowledged appropriately.
| Criterion status | What a justified evaluation adds |
|---|---|
| Met | Evidence and why it supports the whole criterion |
| Partly met | Working part, limitation and user consequence |
| Unmet | Observed failure or missing behaviour and reason |
| Further work | Specific feasible change and how to assess it |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.