MAIE6000C Chap.7 The Vertical Slice and the Midterm Design Review
The Vertical Slice and the Midterm Design Review
A checkpoint, not a dress rehearsal
The module states the purpose of this milestone plainly: to judge whether a team has actually joined its components together believably, to surface risk early, and to reset scope from evidence instead of from optimism.
It is worth fifteen per cent of the course, and its published criteria read different artefacts, so knowing which is which tells you where the last two days before the review are best spent.
Five elements, one run
An input arriving at the system, a single stored change of state, one asynchronous or worker step, one result written down, and one operational signal: a log, a status or a health response.
The word carrying the weight is one. Five things demonstrated separately prove that five things exist. The same five demonstrated in sequence on a single item prove they are connected, and connection is what the criteria call credible integration.
The module adds that the slice does not need to be broad.
Where the ninety published rubric points sit
Twenty five go to midterm implementation progress, described as important features or workflows visibly working or meaningfully integrated. Fifteen each go to architecture coherence, integration and technical maturity, and documentation and milestone clarity.
Ten each go to project direction and scope control and to testing or validation progress. Forty of those points are therefore unavailable to a demonstration whose parts are joined by a human performing a step off screen.
Two criteria are answered by writing
Documentation and milestone clarity, and project direction and scope control, together carry twenty five points and neither requires new code.
Both are satisfied by a submission note saying what works now, what changed since the proposal, what was cut and why, and what the second half of the semester will do.
A team spending its final evening on a feature instead of that note is trading a criterion it could complete for one it probably cannot.
Coherence is checked against your own documents
Architecture coherence asks whether the architecture makes sense, has reasons behind it, and matches what the repository holds, with code and documentation supporting the same design claims.
That criterion cannot be satisfied by good architecture alone and can be lost by good architecture described inaccurately.
It is the one place where writing less is safer: a document describing four services and one queue, all of which exist, scores better than one describing an elegant design of which half is planned.
Order of operations on the day
The published mechanics are to submit the milestone correctly, create and push the midterm tag, update the readme inside the week seven submission folder, and revise the second-half plan after the review.
Order matters, because the tag fixes what gets read. Update the documentation first, commit, then tag, then push both, then record the tagged identifier. Tagging first and improving the notes afterwards produces the commonest recoverable mistake in this course.
What this chapter covers
- 01
The five required demonstration elements, as one run rather than five exhibits
- 02
Where the ninety published rubric points sit, criterion by criterion
- 03
Which criteria read the repository and which read the live demonstration
- 04
The two criteria answered by writing rather than by building
- 05
Architecture coherence, and why accurate description beats elegant description
- 06
The three-line published definition of done for this milestone
- 07
Document, commit, tag, push, record: the order on the day
- 08
Using the review rather than surviving it
Two midterm demonstrations, one clear verdict
- 4Name the criteria Team A cannot address and give their point values.
- 2Say why the gap is larger than the amount of work involved.
- 2Give Team A's two-day repair.
Key terms
- Vertical Slice
- One complete path through every layer on a single item, as opposed to several finished layers that have not been joined.
- Credible Integration
- Evidence that components are connected rather than merely present, which the midterm criteria weigh more heavily than feature count.
- Design Review
- The midpoint technical checkpoint whose outputs are feedback, identified risks and a revised plan rather than a verdict alone.
- Revised Plan
- The tighter, clearer statement of the second half of the semester that the published definition of done lists as a deliverable in its own right.
- Tagged State
- The repository contents at the milestone tag, which is what a reviewer inspects regardless of what was pushed afterwards.
- Operational Signal
- Logs, status output or health output shown during the run, which is the fifth required element and the one most often omitted.
- Submission Folder
- The per-milestone directory in the repository holding the checkpoint evidence, named in the required repository structure.
The Vertical Slice and the Midterm Design Review FAQ
What exactly has to be shown at the Week 7 demo?
Five elements in a single run on one item: an input arriving at the system, a single stored change of state, one asynchronous or worker step, one result written down, and one operational signal: a log, a status or a health response. The module adds that the slice does not need to be broad but must show believable joining-up between the request side, the store, the background step and whatever reports on behaviour.
The published definition of done adds two lines beyond the run itself: the repository shows real integration progress, and the revised plan is tighter and clearer than the proposal was.
Is a polished interface worth building before the midterm?
Not at the expense of the connection between components. None of the six published criteria scores interface quality, while twenty five points go to visible implementation progress and fifteen to integration and technical maturity. A team with four finished screens joined by a manual step scores badly on both, because the joining step is exactly what makes a prototype disconnected.
The same team can usually recover in about two days by attaching what already works to the queue, which is why the honest advice before the midterm is to connect rather than to polish.
How should I spend the last evening before the milestone?
On the submission note and the revised plan rather than on a feature. Twenty five of the ninety rubric points sit on documentation and milestone clarity and on project direction and scope control, and neither requires code. Both are satisfied by writing what works now, what changed since the proposal, what was cut and why, and what the second half will do.
A feature started the night before arrives untested and undocumented, which puts other criteria at risk, while the note is a criterion you can complete with certainty.
Assessment move
Two days before the review, do a full dress run: restart the machine, start from a clean state, submit an item somebody else picks, and time it. Whatever breaks is the thing to fix, and whatever you had to explain out loud is the thing to add a signal for. Then write the submission note before you touch code again.
Working through The Vertical Slice and the Midterm Design Review in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C The Vertical Slice and the Midterm Design Review question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
