The External Evaluation: How the Thirty Marks Are Earned
Chapter Seventy-Five
Syllabus topic Module 2's evaluation: "Working Application Demonstration", "Technical Design & Implementation", "Project Report Evaluation", "Viva Voce".
Pages 487 to 491 of 499
In one line
An examiner marks what is in front of them, so every good thing about your project that cannot be seen in twelve minutes has to be made visible by an artefact you put on the table.
In the wording to use when asked: the external evaluation assesses the demonstrated system, the quality and coherence of its design and implementation, the report as a document, and the candidate's own understanding, out of thirty marks; the assessment is evidential, so each criterion is met by something the examiner can inspect or ask about.
What an examiner can actually see
This is the whole chapter in one table, and it is where most marks are lost:
| What students believe is judged | What the examiner can see |
|---|---|
| how many hours we worked | nothing at all |
| how difficult it was | only if you name the hard part and show its solution |
| how much we learned | only what you can say in three sentences |
| how well we worked as a team | the commit history, the pull requests, and who can answer what |
| that we tested it | the test report, the counts, and the traceability matrix |
| that we planned it | the plan, marked up against what happened |
| that we understood the design | whether the code matches the diagrams |
Effort is invisible; artefacts are not. Everything on the right exists already if you have followed this book, which means the work of the last week is not to produce it but to put it where the examiner will look.
Working Application Demonstration, 10 marks
The examiner sees the system run, or does not. What separates the bands, in practice:
| Band | What it looks like |
|---|---|
| Full marks | starts from cold, one story walked end to end, a refusal shown honestly, a restart, a health check, and the phone |
| Most of them | it all works, but as a tour of screens with no story and no error case |
| Half | it works after some fiddling, or only the happy path exists |
| Few | it does not start, or the demonstration is of screenshots |
Chapter 71 is the readiness, Chapter 74 is the path. The two things that cost most here are a first start in front of the examiner and never showing a refusal: a system that has only ever been shown doing the right thing invites the question of what it does with the wrong thing, and that question is then answered live.
Technical Design and Implementation, 10 marks
This is the component students prepare least and it is worth as much as the demonstration. The examiner can open your diagrams, your repository and your code side by side, and what they are really asking is one question: does the code match the design, and did somebody decide it?
The External Evaluation: How the Thirty Marks Are Earned
Five things to put in front of them, all of which you already have:
| Put on the table | It answers | |
|---|---|---|
| 1 | the architecture diagram, and the code's folders beside it | is the design real, or drawn afterwards |
| 2 | the decision records: the stack, paise, hashed sessions, one clock, the conditional update | did somebody choose, or did it happen |
| 3 | the layer check (npm run layers) | is the layering enforced or aspirational |
| 4 | the ER diagram and sql/schema.sql, column for column | do the model and the database agree |
| 5 | the four lines of SQL that cannot oversell, and the test that proves it | can you explain your own hardest code |
Item 2 is the cheapest ten minutes in the whole project. A decision record is five lines: what was decided, why, and what it costs (Chapter 36). An examiner who reads "we used scrypt because Node.js 22, which we support, has no Argon2, and each hash records its settings so we can move later" is reading an engineer, not a student who copied a tutorial.
And be ready for the opposite question, which is the fair one: where does the code not match the design? There is always somewhere. Naming it yourself, with the reason, is worth more than being caught by it.
Project Report Evaluation, 5 marks
Judged as a document, in perhaps ten minutes of reading. What a reader reaches for first, in order: the contents page, the results, the limitations, the traceability matrix, the references. Chapter 73's fourteen checks are what protect these five marks, and the two that matter most are that every number says where it came from and that the limitations section exists.
A report cannot rescue a broken demonstration, and a demonstration cannot rescue a report with invented numbers, because the viva joins them: the examiner reads a number in the report and asks how it was measured.
Viva Voce, 5 marks
Five marks for whether the project is yours. It is not a general knowledge test: the questions come out of your own project, and Chapter 76 collects them with answers. The only preparation that works is to have done the work and to have read your own report.
Making the invisible visible
| Invisible virtue | The artefact that proves it | Chapter |
|---|---|---|
| We planned it | the Gantt chart, marked up with what actually happened | 17 |
| We prioritised | the MoSCoW table, and the Coulds that were not built | 13 |
| We decided rather than drifted | the decision records | 36 |
| We tested | the test report, the counts by level, the traceability matrix | 55 |
| We found and fixed defects | the issue, its commit, and the test added with the fix | 56 |
| We worked as four | git shortlog -sne HEAD, and reviewed pull requests | 62, 72 |
| We know what it cannot do | the limitations section | 66 |
| Somebody can run it | the README, followed on a clean clone | 69 |
The External Evaluation: How the Thirty Marks Are Earned
Print two or three of these as a single page each and keep them in a folder on the table. When an examiner asks "how did you divide the work?", the answer is better with a page in their hand.
The day, in order
| When | What | Notes | |
|---|---|---|---|
| 1 | 30 minutes early | arrive, find the room, find a socket | the socket is not a joke |
| 2 | 20 minutes before | cold start from Chapter 71, place one test order, reset with npm run db:setup | prove it before anyone watches |
| 3 | 10 minutes before | phone on the hotspot, browser zoom set, other windows closed, notifications off | the projector changes everything |
| 4 | 0 | hand over the report, say who is who | names and roll numbers, once, clearly |
| 5 | first 5 minutes | the slides: problem, scope, requirements, architecture, the hard part, testing, results | Chapter 74 |
| 6 | next 6 minutes | the demonstration, one story, ending with the restart and the health check | Chapter 74 |
| 7 | 1 minute | what we learned, and invite questions | |
| 8 | then | the questions, each member answering for their own part | Chapter 76 |
| 9 | after | leave the machine as you found it, take everything, thank the examiner |
Two notes on step 2. Reset after your own test order, or the examiner's first look is at your rehearsal's data. And do not switch the laptop off between the test and the demonstration: the whole point of the earlier cold start is that the next one is not the first.
Passing, and what to do about a weak component
Forty per cent is needed in each half, so 12 of these 30 and 8 of the guide's 20, counted separately: strong internal marks do not rescue a weak external appearance, and the reverse is equally true.
If one component is weak and the examination is a week away, spend the week in this order, because this is the order of the marks at risk: make the demonstration certain (10), put the design evidence on the table (10), run Chapter 73's checks on the report (5), read your own report aloud to each other (5, and it is most of the viva preparation there is).
Do this for your project
- Accept that effort is invisible, and plan what the examiner will see.
- Make the demonstration certain first: it is the largest single number.
- Prepare the design evidence as pages on the table, not as things you could find.
- Write the decision records if you have not; they are five lines each.
- Name your hardest problem, and be able to show and explain its code.
- Know where the code does not match the design, and say so first.
- Run the report checks, and make sure every number says where it came from.
- Rehearse the day in the order above, including the reset after your own test order.
The External Evaluation: How the Thirty Marks Are Earned
Mistakes that cost marks
Preparing the demonstration and nothing else, and losing the ten design marks by default.
Diagrams drawn after the code, which never match it.
No decision records, so every choice looks accidental.
A number in the report that nobody measured, found by one question.
Arriving five minutes before, with a phone that cannot reach the laptop.
Demonstrating on the data left over from your own rehearsal.
One member answering everything, when four are being marked.
Quick revision
- The external 30: demonstration 10, technical design and implementation 10, report 5, viva 5; pass at 12.
- Effort is invisible: an examiner marks artefacts and answers.
- Demonstration: cold start, one story, a refusal, a restart, a health check, the phone.
- Design: diagram beside the folders, decision records, the layer check, ER beside the schema, the hardest code.
- Report: contents, results, limitations, traceability, references; every number sourced.
- Bring the invisible-virtue pages: plan, priorities, decisions, test report, issues, contributors, limitations, README.
- The day: 30 minutes early, cold start, reset, report, 5 slides, 6 demonstration, 1 close, questions.
Questions you must be able to answer
1. How are the external thirty marks divided? Working Application Demonstration 10, Technical Design and Implementation 10, Project Report Evaluation 5, Viva Voce 5, and 40 per cent of the thirty, which is 12, is needed to pass the external half on its own.
2. Why is "we worked very hard on this" worth nothing to an examiner? Because effort cannot be inspected. Only the demonstrated system, the code and diagrams, the report and your answers can be, so anything you want credited has to exist as one of those.
3. What is the examiner really asking under "technical design and implementation"? Whether the code matches the design and whether somebody decided it: the diagram against the folders, the decision records behind the choices, the layering actually enforced, the database agreeing with the model, and whether you can explain your own hardest code.
4. Why do decision records matter so much for the marks they cost to write? Because they are the only evidence that a choice was made rather than copied. Five lines on why scrypt rather than Argon2id, or why money is stored in paise, turns a defensible answer into a written one.
The External Evaluation: How the Thirty Marks Are Earned
5. What should a team do in the last week if one component is weak? Work in the order of the marks at risk: make the demonstration certain, then put the design evidence on the table, then run the report checks, then read the report aloud to each other, which is most of the viva preparation available.
6. What is the one thing to do twenty minutes before the examination? The cold start of Chapter 71, with one test order placed and then npm run db:setup to reset, so that the system has already been proved that morning and the examiner's first look is at clean data.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself for the same subject.