At a glance
Teams, with your community partner present · Unit 4, Day 20, the last class of the build · your partner runs the software, the room reviews it, and the project is passed to whoever owns it next — in writing
What happens
Your partner comes to the room. They sit at the machine. They run the software your team built, in front of everybody, and you keep your hands off the keyboard.
Then the project changes hands. Not the files — the responsibility. Somebody who was not in this room for any of the last five weeks has to be able to use it next month and change it next year. Whether that is a gift or a burden was decided by choices your team made in Unit 4, Day 1, and today is when you find out which one you built.
This is the finale of The Software Project and the last piece of its assessment.
The three parts of the class
1. The demonstration — your partner drives. Ten minutes. They open it and use it for the thing they actually wanted. You may answer a direct question; you may not take the mouse, and you may not narrate. Everything the room learns in these ten minutes, it learns from watching a real person meet your interface without you in front of it.
2. The handover itself. The package below changes hands, item by item, out loud, with your partner confirming they have each piece and know what it is for. “I emailed it” is not a handover.
3. The team review. Fifteen minutes, structured, with the whole room. What the plan said, what actually happened, and what you would tell the team who inherits this. The protocol for keeping this about the work rather than the people is the one you have run twice already in The Code Review.
The handover package
Judged as a whole. A package missing any of these is incomplete, and the two that get skipped are always six and seven.
- The software itself, in a folder named something that means something to your partner, on a machine or drive they control — not only on yours, and not only in your account.
- A one-page guide in their language: what it is for, how to start it, what it will ask, what it gives back, and one worked example with realistic values.
- What to do when it goes wrong — the two or three failures you know are possible, what each one looks like on screen, and what to do about it.
- The known-limits list. What it does not do, what it will never do, and what would happen if their situation changed. Plain, honest, unashamed.
- Where the data lives: what is in it, how to back it up, and how to delete it without you.
- How to change it. The repository and its history, the language and version it needs, the tests and how to run them, the design decisions that are not obvious from the code, and the one paragraph you wish somebody had written for you on the first day of this course. This is what Writing Code Others Can Read has been preparing you for, inside the code itself.
- A named next owner and a follow-up promise you can keep. Who to ask; one check-in at a date you name. Then keep it.
The team review
Come with these answered in writing, not improvised at the front:
- What did your plan say on Unit 3, Day 15, and where did reality diverge from it first?
- Which milestone was hardest to hit, and what would you change about how the team worked rather than about the code?
- What did each member own, and did it hold?
- What is in the “deliberately not doing” list, and are you still comfortable defending every item?
- One recommendation, specific enough to act on, for the next team who touches this.
What you hand in today
- The complete handover package, in your partner’s hands and confirmed item by item.
- The team review, written, one document per team.
What you hand in next class
- Your Final Reflection and your Code Journal — both individual, both complete per Journal Checklist. You begin the reflection in class on Unit 4, Day 19 and finish it in class on Unit 4, Day 21, which exists for exactly that. Nothing about either one is carried home tonight.
The reflection’s last section is the one this task adds to what your
journal has been doing all semester: your own evaluation of the
Essential Skills and work habits the Ontario Skills Passport names —
three of them, where you started, where you are now, and the dated
evidence for both. It is written in the Unit 4, Day 21 period along
with the rest of the reflection, and it is expectation D4.4, which
is why it is marked at all: what is judged is the evidence and the
reasoning, never the rating you give yourself. How Marks Work sets
out why that distinction is not a technicality.
How this is assessed
Per How Marks Work, today assesses the close of the project, not a performance. A modest program handed over completely and honestly scores above an impressive one whose partner leaves holding a memory stick and a hope.
Today is part of the final thirty per cent of your mark, together with the Final Examination. The package is judged as a team’s work, because that is what it is — but what is recorded against your name is the part of it you wrote and answer for, the item you confirmed out loud, and your Final Reflection. Four names on a cover page do not produce four identical marks here any more than anywhere else in this course.
Read the criteria table below on Unit 4, Day 17, not on Day 20. That period is set aside for exactly this, Judging Your Own Work is the routine, and Day 18’s rehearsal is where you act on what it tells you.
Two things carry the most weight. First, whether your partner can actually use it — visible in ten minutes with your hands in your lap. Second, whether somebody else could change it, which is judged from the documentation and the history, and which is the entire argument of Who Maintains This and What Happens When You Leave.
Success criteria
| Quality | What it looks like |
|---|---|
| Your partner drives | They run it; you do not touch the keyboard |
| It does the thing they asked for | The core works, in front of witnesses |
| Package complete | All seven items, confirmed one by one |
| Honest about limits | Known-limits list read aloud, not buried |
| Changeable by a stranger | History, tests, and reasoning all present |
| Data explained | Where it lives, how to back it up, how to delete |
| Review is about the work | Plan versus reality, stated plainly |
| A named next owner | A person, and a check-in date you will keep |
| Skills judged on evidence | Three skills, the first week and now, each claim dated and citable |
Reflect
Your Final Reflection closes the course. On the first day you were handed a working program nobody in the room had written, and it took a whole period to work out what it did. Today somebody is inheriting yours.
So: what did your team do — specifically, name the file, the commit, the paragraph — so that the person who inherits this does not have the day you had? And what did you not get to, and who should be told?
If your partner cannot come
It happens, and it is not a failure. Record the demonstration with them somewhere they are comfortable, at a time that suits them, and play it to the room — their hands, their pace, their surprises, not a narrated tour by you. Everything else about the handover is unchanged and still happens today: the package, the confirmation item by item, and the named next owner. Arrange it with me before Unit 4, Day 18 so the recording exists in time for the rehearsal, rather than becoming one more thing to do on the night before.
Curriculum connection
B1.3
produce the software according to specifications (i.e., code, test, deploy), and create user documentation and training materials;
Link to original
B1.5
close the project (i.e., confirm that software meets all user requirements, deliver software in appropriate format, plan software support and maintenance);
Link to original
B1.6
review the management of the project (e.g., compare plan to actual performance, outline successes, make recommendations for improvement) and prepare a report in an appropriate format;
Link to original
B2.2
demonstrate the ability to meet project goals and deadlines by managing individual time during a group project;
Link to original
B2.3
reflect on, and assess, team and individual progress during the project review.
Link to original
A4.4
create clear and maintainable external user documentation (e.g., Help files, training materials, user manuals).
Link to original
D4.4
evaluate their own development of Essential Skills and work habits that are important for success in computer studies, as identified in the Ontario Skills Passport.
Link to original