3.4.2-3.4.3 - Formative project skills: evaluating the final product

Judge each original success criterion against evidence

A success criterion is an observable standard established during analysis. Evaluation returns to that original standard; it does not rewrite it to fit whichever results are favourable. Use identifiers to connect the criterion to relevant developmental tests, final tests and user observations. Explain what each result establishes about the final version.

Consider supplied evidence from a miniature archive catalogue. Development test D3 exposed a duplicate-identifier fault; D4 showed a remedy on a later prototype. Final tests F1–F3 and user task U1 were collected on final v6. The catalogue's timing tests use the agreed 500-record dataset and named test laptop.

Met, partially met and unmet must describe the evidence and the wording of the criterion. Partial success is useful when a criterion has distinct aspects, such as correctness and speed. A strict numerical threshold is not met merely because some participants succeed. You can still describe a feature as partly effective without claiming that its particular threshold was reached.

A missing test leaves a claim unverified; it is not evidence that the feature passed or failed. State the gap and what observation would resolve it. Passing selected cases supports those cases, not a guarantee for all possible inputs or future environments. Keep original criteria visible even when the result is disappointing.

Build a line of reasoning from results to conclusion

A reasoned judgement connects a claim, specific evidence and an explanation of its significance, then considers limitations before reaching a conclusion. Listing test identifiers alone does not explain how a requirement has been met. Saying “the program is good” provides neither a measurable claim nor support.

For C2, a useful evaluation is: “F2 returned the correct entry in all six searches on the agreed dataset. However, two took 2.6 seconds, exceeding the 2-second limit. Search correctness is supported, but the criterion is only partly met because staff may wait longer than the agreed response time. Investigate those slow searches and retest any change with the same workload. These measurements establish behaviour on the test laptop, not every device.” Each sentence advances the judgement rather than repeating a verdict.

Developmental evidence explains the journey and why a remedy was chosen. Final evidence checks what the integrated final version does. If D4 shows that a prototype fixed duplicates but F1 on the final version again changes an old record, the final failure cannot be dismissed because the older test passed. Compare versions and circumstances; the contradiction prompts investigation, not selective reporting.

Choose evidence relevant to each claim, including counterevidence. Distinguish a proposal from an implemented improvement: “add an offline export cache and test it” is a future action, not proof that C4 is now met. A justified conclusion may recommend further work or accept a limitation within a stated use, but should say which original needs remain unsatisfied.

Clear sustained reasoning is part of evaluation itself. It is not a reason to add arbitrary marks for an essay introduction, a compulsory paragraph formula or a particular word count. These local exercises use distinct formative skill points; they do not reproduce the official holistic project grading process.

Evaluate what an implemented usability feature achieves

An implemented usability feature is effective only to the extent that evidence shows it helps the intended user with the intended task. Begin with the feature from the design, show it in the final interface, and explain its mechanism. Then compare the intended effect with task observations and actual feedback.

In a supplied practice record, design feature U2 places the text “Identifier already used: choose another” beside the identifier field and retains all other entries after rejection. A final-interface capture can establish the message's location and the preserved entries. Its annotation should identify these features and explain that they aim to make correction clear while avoiding retyping.