Effectiveness

Criterion E: Evaluating the Effectiveness of Your Computational Solution

Criterion E is the evaluation component of your Internal Assessment (IA). It asks you to reflect honestly and analytically on how well your completed computational solution meets the success criteria you defined at the start of the project. Rather than simply describing what your solution does, you are expected to judge whether it actually achieves what it was designed to do - and to support that judgement with evidence.

Evaluating Against Success Criteria

In Criterion E, you work through each success criterion and assess the extent to which your solution has met it. This is not a binary pass/fail exercise - you are expected to provide a nuanced evaluation that acknowledges partial successes, limitations, and areas for improvement. The IB rewards honest, evidence-based reflection far more than inflated claims of complete success.

For each criterion, you should:

  • State clearly whether the criterion has been fully met, partially met, or not met.
  • Provide specific evidence from your solution - for example, screenshots, test results, or user feedback.
  • Explain why the criterion was or was not met, identifying any technical or design factors that influenced the outcome.
  • Suggest realistic improvements that could address any shortcomings.

The Importance of Evidence

Claims made without evidence carry little weight in Criterion E. Your evaluation must be grounded in concrete demonstrations of your solution's behaviour. This might include test tables showing inputs and expected versus actual outputs, feedback collected from the client or end users, or annotated screenshots highlighting specific functionality. The evidence you gather during Criterion D (testing) feeds directly into your Criterion E evaluation, so maintaining thorough test records throughout the project is essential.

Deep Dive: Writing Strong Success Criteria Evaluations

One of the most common weaknesses in Criterion E responses is a lack of specificity. The table below illustrates the difference between a weak evaluation statement and a strong evaluation statement for the same success criterion.

Success criterion: The login system should only allow authorised users to access the application.

Weak evaluation statement:

"The login system works and users can log in. The criterion has been met."

This is weak because it makes a claim without evidence, does not explain how it was tested, and does not acknowledge any limitations or edge cases. It tells the examiner nothing about the quality of the solution.

Success criterion: The login system should only allow authorised users to access the application.

Strong evaluation statement:

"This criterion has been fully met. Test cases 3 to 7 (see Criterion D) demonstrate that entering an incorrect password prevents access and displays an appropriate error message. Entering a valid username and password redirects the user to the main dashboard. The client confirmed during the final review session that the login behaviour matched their expectations. One limitation is that the current system does not implement account lockout after repeated failed attempts, which could be addressed in a future iteration by adding a failed-attempt counter."

This is strong because it references specific evidence, describes the observed behaviour, incorporates client feedback, and honestly identifies a remaining limitation with a concrete improvement suggestion.

Success criterion: The system should generate a monthly summary report and export it as a PDF file.

Partially met evaluation statement:

"This criterion has been partially met. The system successfully generates a monthly summary report that displays all required data fields, as evidenced by test case 12. However, the PDF export functionality was not fully implemented due to time constraints - the report can currently be printed but cannot be saved directly as a PDF from within the application. A future improvement would involve integrating a PDF generation library to automate the export process, which would fully satisfy this criterion."

Acknowledging partial success honestly and explaining why a criterion was not fully met is valued highly by examiners. It demonstrates maturity and analytical thinking.

 Key Takeaways

  • Criterion E evaluates how well your completed solution meets the success criteria established during the planning stage.
  • Each success criterion must be assessed with specific, concrete evidence - not vague claims of success.
  • Honest evaluation of partial or unmet criteria is rewarded; examiners value analytical reflection over inflated claims.
  • Recommendations for improvement should be specific and technically realistic, linked directly to identified limitations.
  • Client and user feedback provides authentic, real-world evidence to support your evaluation.
  • Test results from Criterion D are essential evidence for Criterion E - maintain thorough test records throughout the project.