Presentation and Demonstration

Four rules for the slides themselves:

• One idea to a slide, and a title that states it: "Two orders for the last plate cannot both succeed", not "Implementation".
• No paragraphs. If a slide has to be read, it will be read instead of you being listened to.
• Every diagram is one you drew and can explain line by line, from the UML set (Chapter 35).
• Screenshots, not promises: slide 3 shows the built page, not a wireframe (Chapter 68).

The demonstration: a path, not a tour

Six minutes, and the order matters. Do not open every screen; walk one story through the system, so that the examiner sees the loop close:

Six minutes, three hundred and sixty seconds. Steps 8 and 9 are the ones most teams never think to show, and they are worth more than another screen: they say that the team thought about the system running rather than only about the code compiling.

Then one minute to close: what we learned, in three sentences (Chapter 66's three), and an invitation to questions.

Three habits that make a demonstration look practised:

• Say what you are about to do before you do it. "I will now ask for three when two are left, and you will see the message a student gets."
• Narrate the state, not the mouse. "Ganesh at the counter is seeing this list refresh by itself", not "now I click here".
• Use the seeded names. Priya orders, Ganesh serves, Lata reads the report. It reads as a system in use rather than as a form being filled.

Who speaks when

Four members, and the rule is that each explains what they built, because the viva will ask them anyway (Chapter 76):

One member keeps time and drives the machine, and nobody stands behind the person typing. Agree who answers a question that lands between two people, and agree that whoever is asked answers, rather than the confident one answering everything: an examiner marking four students will notice.

Rehearse it twice, on the machine

The first rehearsal always finds something, and it is never what you expected. The worked team's two rehearsals found: the projector made their contrast look fine but their Only 2 left note unreadable from four metres, so the demonstration zoomed the browser to 125 per cent; and the counter page's ten-second refresh meant a silence they had not planned for, so step 4 now has a sentence to say while it happens.

Rehearse on the machine you will use, from the cold start of Chapter 71, with the phone already prepared, and to the clock. Twelve minutes is shorter than anybody believes: a team that has not timed it reaches slide 6 as the examiner asks them to wrap up, which means the hard part, the testing and the results are never shown.

When something breaks

It will, in a room with one projector and four nervous people. What is assessed is whether you know your own system.

• Say what should have happened, in the mechanism's own words: "the list refreshes every ten seconds, so it should have moved; let me reload it."
• One minute, then move on and come back. Chapter 71's rule.
• Have the rehearsed fallbacks. The three that cover almost everything: the browser at phone width instead of the phone; npm run db:setup to put the data back in seconds; and the printed screenshots, which are in the report you handed them.
• Never blame the network you removed. You have already made the demonstration local (Chapter 71), so a failure is yours and is best treated as interesting rather than embarrassing.

The guide's internal review

Different event, same preparation. Your guide has seen the increments, so this is about the whole against the plan: what was planned, what was built, what slipped and why, what the review of each increment changed, and what you learned. Bring the plan (Chapter 17) and mark it up honestly: a team that says "the stock rule took two days longer than its six-hour estimate and here is what we did about it" is showing exactly the judgement the five marks are for.

Do this for your project

1. Prepare two talks: the guide's, about the plan; the examiner's, about the problem.
2. Ten slides, one idea each, a title that states it, no paragraphs.
3. Give a slide to the hardest thing you solved, and be able to show its code.
4. Write the demonstration as one story through the system, not a tour of screens.
5. Include a restart and a health check: show that it is a system.
6. Give each member the part they built, and agree who answers what.
7. Rehearse twice, on the machine, to the clock, from a cold start.
8. Prepare three fallbacks and rehearse them too.

Mistakes that cost marks

Giving the guide's progress talk to the examiner, who does not know what any of it is.

Thirty slides, and the demonstration cut short.

Reading the slides aloud.

A tour of every screen, with no story and no loop closed.

One member speaking for all four, which the marks are not designed for.

No rehearsal, so nobody knows it takes nineteen minutes.

A wireframe on the "what we built" slide, three months after it was built.

Debugging in front of the examiner for five minutes.

Quick revision

• Two events: the guide's review (5, internal, progress against the plan) and the examiner's demonstration (10, external, plus the viva's 5).
• The examiner knows nothing: begin with the problem and a number.
• Twelve minutes: 5 of slides (300 s), 6 of the system (360 s), 1 to close; 720 in all.
• Ten slides, one idea each; give one to the hardest part and show its code.
• The demonstration is one story: stock, order, refusal, counter, kitchen, report, phone, restart, health.
• Each member speaks for what they built; one keeps time and drives.
• Rehearse twice on the machine, to the clock, and rehearse the fallbacks.
• When it breaks: say what should have happened, one minute, move on.

Questions you must be able to answer

1. How do the guide's presentation and the examiner's demonstration differ? In what the audience knows. The guide has followed the project and is assessing progress and judgement against the plan; the examiner has never seen it and must be given the problem, the system, the design and the evidence in about twelve minutes.

2. How should twelve minutes be divided? Roughly five minutes of slides, six of the working system, and one to close and invite questions. The system gets the larger half because ten of the external marks are for the demonstration.

3. What should a presentation devote a whole slide to that most do not? The hardest problem the team solved, and its solution. For the worked project that is the stock rule: two orders for the last plate cannot both succeed, four lines of SQL in one transaction, and a test that proves it.

4. Why demonstrate a restart and a health check? Because they show that the team built a system rather than a program: the data survives the process, and there is a way to tell whether the application and its database are up. Very few student demonstrations show either.

5. Why should each member present the part they built? Because the viva will ask them about it individually, and because four students are being marked. A single presenter leaves the others with nothing an examiner can assess.

6. What do you do when the demonstration fails in front of the examiner? Say what should have happened, in the mechanism's own terms, give it about a minute, use a rehearsed fallback, and return to it later. Knowing why it failed is itself evidence that you built it.