The final demonstration, evaluation and what comes next

The last week of the capstone brings everything together: the final demonstration to a panel and the client, the evaluation of the product and of each student, and the handover described in lesson 10. It is also a turning point. For most students the capstone is the last course before graduation and the first piece of work they will describe in job interviews, show in a portfolio, or build on in a startup or graduate program. This lesson covers how capstones are evaluated, how individual marks are separated from the team mark, how to turn the project into a lasting asset, and how to look back on the whole program.

Code freeze and the last sprint

Plan the end backwards from the final demonstration. Team Relay set a code freeze at the end of week 12: after it, only fixes for serious bugs could merge, each reviewed by two people. Week 13 was for rehearsing the demo, finishing the report, running the handover sessions and transferring accounts. Teams that keep adding features until the night before the demo usually arrive with a fragile system and an unfinished report. Those that freeze early arrive calm, with time to rehearse, and their demos go better. If a stretch goal is not finished by the freeze, leave it on a branch with notes for whoever continues the project; do not merge half a feature into the handover.

How capstones are evaluated

Capstone evaluation looks at the product, the process and the people. Panels typically use a rubric with written level descriptors for each criterion, so that different assessors apply the same standard. Common criteria are how well the product solves the client's problem, quality and testing evidence, design and architecture, communication in the report and demo, and handover and sustainability. Many courses also collect a short client evaluation, asking whether the team understood the problem, communicated well, delivered what was agreed and left the client able to use the product. Clients do not set grades, but their view weighs heavily with supervisors.

# Scoring the final demonstration with a weighted rubric: three assessors, five criteria,
# each scored 1-4 against written level descriptors. Large disagreements trigger a discussion.
criteria = {                      # weight in %
    "Solves the client's problem": 30,
    "Quality and testing evidence": 20,
    "Design and architecture": 20,
    "Communication and demo": 15,
    "Handover and sustainability": 15,
}
scores = {                        # assessor -> scores in criteria order
    "Instructor A": [4, 3, 3, 4, 4],
    "Instructor B": [3, 3, 3, 4, 3],
    "Industry guest": [4, 4, 1, 4, 4],
}
names = list(criteria)
for i, name in enumerate(names):
    vals = [s[i] for s in scores.values()]
    spread = max(vals) - min(vals)
    note = "  <- discuss before finalizing" if spread >= 2 else ""
    print(f"{name:30} {vals}  mean {sum(vals) / len(vals):.2f}{note}")
mean_level = {n: sum(s[i] for s in scores.values()) / len(scores) for i, n in enumerate(names)}
pct = sum(criteria[n] * mean_level[n] / 4 for n in names)
print(f"weighted score: {pct:.1f}%")

Solves the client's problem    [4, 3, 4]  mean 3.67
Quality and testing evidence   [3, 3, 4]  mean 3.33
Design and architecture        [3, 3, 1]  mean 2.33  <- discuss before finalizing
Communication and demo         [4, 4, 4]  mean 4.00
Handover and sustainability    [4, 3, 4]  mean 3.67
weighted score: 84.6%

The rubric output shows why panels discuss before finalizing. The three assessors agreed closely on most criteria but differed by two levels on design and architecture: the industry guest thought the single-instance design too fragile, while the instructors judged it appropriate for the client's scale and budget. The discussion that followed, with the team's ADR explaining the trade-off on screen, persuaded the guest, and the panel settled on level 3. A team that records its reasoning wins arguments like this; a team that cannot explain its choices loses them.

Separating individual marks from the team mark

Most of a capstone mark is shared, as lesson 1 explained, but courses adjust individual marks when contributions were clearly unequal. The evidence is the peer evaluation, repository and issue history read with care (lesson 7), the supervisor's notes from meetings and demos, and each student's reflection. One widely used approach is in the style of the WebPA method developed at Loughborough University: each student rates every team member, including themselves, on contribution; each rater's ratings are normalized so that every rater gives out the same total; each person's share of the normalized ratings becomes a factor that scales their part of the team mark, usually within limits such as 0.8 to 1.1.

# Peer-evaluation adjustment (in the style of the WebPA method):
# each member splits ratings across the team; each person's share of the ratings
# becomes a factor that scales their part of the team mark, within limits.
ratings = {   # rater -> {ratee: points out of 5 for overall contribution}
    "Priya":  {"Priya": 4, "Marcus": 5, "Sofia": 4, "Ethan": 3, "Lin": 5},
    "Marcus": {"Priya": 4, "Marcus": 4, "Sofia": 4, "Ethan": 3, "Lin": 5},
    "Sofia":  {"Priya": 5, "Marcus": 5, "Sofia": 4, "Ethan": 3, "Lin": 4},
    "Ethan":  {"Priya": 4, "Marcus": 5, "Sofia": 4, "Ethan": 4, "Lin": 4},
    "Lin":    {"Priya": 5, "Marcus": 4, "Sofia": 5, "Ethan": 2, "Lin": 4},
}
team = list(ratings)
n = len(team)
# Normalize each rater's ratings so every rater hands out the same total.
received = {p: 0.0 for p in team}
for rater, given in ratings.items():
    total = sum(given.values())
    for ratee, pts in given.items():
        received[ratee] += pts / total
team_mark = 81.4                      # the shared team mark out of 100
for p in team:
    factor = received[p]              # each rater gives out 1.0 in total, so 1.0 is an equal share
    capped = min(1.10, max(0.80, factor))
    print(f"{p:7} factor {factor:.3f} -> capped {capped:.2f} -> individual team mark {min(100, team_mark * capped):5.1f}")
print("sum of factors:", round(sum(received.values()), 3), "(equals the number of raters)")

Priya   factor 1.069 -> capped 1.07 -> individual team mark  87.0
Marcus  factor 1.114 -> capped 1.10 -> individual team mark  89.5
Sofia   factor 1.021 -> capped 1.02 -> individual team mark  83.1
Ethan   factor 0.726 -> capped 0.80 -> individual team mark  65.1
Lin     factor 1.069 -> capped 1.07 -> individual team mark  87.0
sum of factors: 5.0 (equals the number of raters)

Team Relay's factors were close to 1 for four members and lower for Ethan, whose teammates rated him below average. The supervisor did not apply the factor mechanically. She looked at the evidence from lesson 7, which showed that Ethan's pipeline, environments and restore drill were essential and largely invisible, and at his reflection, which described that work clearly. She also noted from meetings that he had been slow to respond during weeks 8 and 9, when he was ill, and had told the team only late. She adjusted the factor partway toward 1. Peer evaluation is evidence, not a verdict, and good courses combine it with other sources and allow students to explain.

Peer evaluation works best when students know from the first week how it will be used, rate with specific comments rather than numbers alone, and give interim evaluations mid-term so that problems surface while there is time to fix them. Rate honestly and fairly: rating everyone 5 out of friendship hides real problems and is unfair to those who did more; punishing a teammate for a personal disagreement is worse. If you have concerns about a teammate, raise them with the supervisor during the term, not first in the final evaluation.

The client's verdict

At the end of term, Grace and Sam completed the course's client evaluation. They rated Team Relay highly on understanding the problem and on communication, and slightly lower on delivery, because shift swaps, which drivers had asked for, did not make it. Their written comments mattered most: the co-op decided to roll RescueRoute out to all drivers over the summer, with the volunteer developer as technical contact, and to offer the shift-swap feature to the next year's capstone class as a project. For a capstone, a client who keeps using the product after the students leave is the strongest possible outcome.

Turning the project into a portfolio

Employers increasingly ask to see real work. A capstone, with the client's permission, is ideal: it shows a real problem, a team, decisions and results. Write a short case study for your portfolio: the problem, your role, two or three decisions you made and why, the results with honest numbers, and what you would do differently. Link to the public repository if the code is open source, and to a short video. Respect confidentiality: never publish client data, internal documents or anything the client asked you not to share, and use the synthetic data set for screenshots. In interviews, be specific about your own contribution and generous about your teammates'.

Open source and continuing the project

If the code is open source, the project can continue after you. Make it easy: a CONTRIBUTING guide, a list of good first issues, a clear license and a maintainer named by the client. Some community projects attract contributors from other volunteers or from local companies' volunteering programs; most do not, and that is fine, because an open license still lets the client hire anyone to work on it. Team Relay's repository was transferred to the co-op's organization account with the MIT license, and Sofia and Lin each became occasional contributors after graduating, fixing small issues that the volunteer developer reported.

Entrepreneurship and next steps

Occasionally a capstone reveals a product with a market beyond one client. Food rescue organizations across the country face the same scheduling problem as the co-op. If a team wants to pursue such an idea, it must first respect the agreements made in the proposal: who owns the code and the data, and what the client was promised. An MIT-licensed project can be built upon by anyone, including its authors, but client data and any client-specific work stay with the client. Talk to your institution's technology transfer or entrepreneurship office, which often runs incubators, mentoring and small grants for student ventures.

In the United States, the Small Business Innovation Research (SBIR) and Small Business Technology Transfer (STTR) programs fund research and development by small businesses through federal agencies such as the National Science Foundation, the National Institutes of Health and the Department of Defense, in phases from feasibility studies to development. Their authorization lapsed on 30 September 2025, and after about seven months Congress passed a reauthorization, signed on 14 April 2026, extending the programs through 30 September 2031 with new limits on the number of proposals per company and stronger security reviews. Check agencies' current solicitations before applying. States, universities and many cities add incubator and seed programs.

Most graduates will not start a company, and the capstone's main value is the professional habits it builds. Graduate study is another path: a capstone that raised interesting questions, such as how to evaluate fairness in volunteer scheduling or how to make accessible interfaces for older users, can grow into a research project. Whatever comes next, the evidence you produced, a working product, a report, documented decisions and a satisfied client, travels with you.

Looking back on the program

The capstone is a good moment to look back at the whole program and see how its parts connect. Team Relay's project drew on nearly every course. Discrete mathematics and algorithms (CMPUT-272 and CMPUT-204) appeared in the scheduling helper and its invariants. Databases (CMPUT-291) shaped the data model and its constraints. Software engineering (CMPUT-301) gave the process, version control and testing. Computer networks and operating systems underlay every request, and distributed systems (CMPUT-450) explained why one instance was enough and what would change at larger scale. Security (CMPUT-331) shaped the threat model and authentication, human-computer interaction (CMPUT-421) the accessibility and research methods, web development (CMPUT-404) the stack, product management (CMPUT-401) the discovery and prioritization, and machine learning (CMPUT-367) the decision not to build a model. Theory of computation (CMPUT-474) was the course students thought least relevant, until the team realized that their reminder-parsing code was a finite automaton and that no tool could have verified their scheduling code fully in general.

Write your own version of this map in your final reflection. It is a useful way to see what you have learned, to notice gaps you might fill with your first job or further study, and to explain to employers how the parts of a computing degree fit together in practice. The specific technologies Team Relay used will change within a few years. The habits behind them will not: understand the problem before building, keep the design as simple as the problem allows, write decisions down, test honestly, protect the people whose data you hold, communicate clearly, and leave things better for whoever comes next.

Worked examples