Session 13 — Project presentations

Session 13 of 13PresentationDraft3 min read

Draft for the lecturer's approval.

The date, weight and order of the presentations are set in Moodle. The site does not publish a grade and does not accept submissions.

Goals

• Show a system that runs, not only describe it.
• Present one failure and explain where it happened.
• Compare with a simpler baseline, with numbers.
• Explain one decision in the code, each student on their own.

Three things to show

In the presentation you need to be able to show three things:

1. The system runs on a real example from your own collection.
2. One case fails, and you know whether the failure is in search, decision, tool or coordination.
3. There is a comparison with a simpler version: the same cases, with the number of successes and the number of calls.

Every student needs to explain a decision in the code, even if the work was submitted as a pair. The submission questions and the official files are in Moodle.

A comparison table

One table is enough. It answers whether the complexity you added bought anything:

Measure	Simple baseline	Your system
Successes
Correct refusals
Calls
Time

If your system is not better than the baseline, that is a finding. Present it, and explain what you would test next.

Presenting a failure

Pick one case that failed, and show its log. Answer four questions:

• What the right answer was, and how you know.
• At which step in the log the path went wrong.
• Whether the failure is in search, decision, tool or coordination.
• What you would change, and how you would check that the change helped without breaking other cases.

A failure you can locate shows that you understand the system. A presentation with no failure at all raises the question of whether you tested enough cases.

Before the presentation

• A full run from a clean folder, following the README, on the computer you will present from.
• A fallback in case the network or the model service is unavailable: a saved log of a real run, marked as such.
• Both partners can explain every part of the code, not only the part they wrote.

Hold a full rehearsal as a pair, with a clock. One presents, and the other asks two questions: "Why not a fixed workflow?" and "What happens if this tool fails?". Swap roles.

Check your understanding

In the middle of the presentation the model service does not answer. What do you do?

Pick an answer to see the explanation. There is no grade here.

Summary

What stays. A good presentation shows a run, one failure you understand, and a comparison in numbers with a simple baseline.

What breaks. A demo with no baseline. A hidden failure. A team member who cannot explain the code.

The mark is saved only in this browser. It is not an academic record and is not sent to a server.