Speaker note: This deck mirrors the project guide page section by section — treat it as the quick-reference version.
Speaker note: The C and Java versions are not two separate projects — the Java version extends the same application.
Speaker note: These four facts are the ones every question in this deck eventually traces back to.
Speaker note: "Mandatory for every topic" is the key phrase — the topic changes the story, not the requirement list.
Speaker note: Six milestones; the full weekly schedule lives in the syllabus.
Speaker note: The full weekly schedule is in the syllabus — this is only the project's own milestones inside it.
Speaker note: Same formulas as the syllabus, now paired with which LOs each checkpoint actually measures.
Speaker note: RAP1/RAP2 are the two checkpoints this whole deck is about.
Speaker note: LO.6 (file organization) only appears in RAP2 — it is taught in weeks 13–14, after the midterm checkpoint.
Speaker note: The same toolchain from the Prerequisites deck, now with exact templates and repository names.
Speaker note: "PDF only, no HTML folder" is a real acceptance condition — an HTML Doxygen output in the archive is a rejection risk.
Speaker note: The Java repository additionally needs to produce a release — that is checked at demo time.
Speaker note: A public repository during the term is itself an acceptance-condition problem, independent of code quality.
Speaker note: Both templates live under github.com/ucoruh — use "Use this template" there.
Speaker note: Each template's README and its docs/guide/ page "Showing your project without GitHub Pages" have the details.
Speaker note: Almost every rubric criterion maps to code that should live specifically in lib, not scattered into app.
Speaker note: 200 topics, eight groups, one rule: first team to write it down gets it.
Speaker note: This deck shows one representative topic near the end — the full 200 are only on the page, by design.
Speaker note: Step 3 is the one students forget — approval is tied to the plan, not to writing your name in the table.
Speaker note: The requirement itself — which structure, which operation — never changes, only which feature in the app demonstrates it.
Speaker note: V1–V6 for the midterm (C), F1–F9 for the final (Java) — implemented by you, not from a library.
Speaker note: This is checked at the demo — walking through your OWN insert/delete code, not a call to a library method.
Speaker note: These three are due in the first three content weeks — start the project plan around them, not around the whole list.
Speaker note: V6 is the last midterm requirement, taught the week right before the midterm demo — plan the buffer accordingly.
Speaker note: F1 is the port of everything already built in C — it is not new functionality, but it is real work.
Speaker note: F6 is taught in two separate weeks (trie in 9, disjoint sets alongside strings in 12) — plan it in two passes.
Speaker note: F7–F9 are the last three requirements, taught in the two weeks right before the final demo — the tightest part of the schedule.
Speaker note: "Persistent" is tested literally at the demo: add a record, close the program, reopen it, show the record is still there.
Speaker note: These four rules are the same four checked in "Acceptance conditions" later in this deck — they are not optional polish.
Speaker note: One archive, uploaded once per checkpoint, with the repository link on the report cover.
Speaker note: The presentation and video are final-only — the midterm checkpoint is code, report and a live demo, nothing pre-recorded.
Speaker note: This is a GitHub repo clone, gitignore-filtered — it extracts and builds on its own.
Speaker note: video/ is explicitly NOT committed to GitHub — it is added to the zip archive only, right before submission.
Speaker note: Inconsistent naming is a small but avoidable source of confusion when grading dozens of submissions.
Speaker note: This is graded, not just recommended — "Software engineering" is a rubric criterion worth 20 points on each checkpoint.
Speaker note: A demo question directly asks "how were branches used, how were merges/conflicts resolved" — this is not a formality.
Speaker note: Meaningful commits from BOTH members is an explicit acceptance condition — one member's name on every commit is a red flag.
Speaker note: The version tag is what "the state you submit for grading" means precisely — tag it, do not just submit whatever main happens to be.
Speaker note: Two rubrics, 100 points each, seven criteria apiece — every criterion on a 1–5 achievement scale.
Speaker note: The formula matters: a level-3 criterion earns 60% of its points, not zero — partial credit is real and scales linearly.
Speaker note: Criteria 1–4 (65 points) are the four V-code groups; 5–7 (35 points) are analysis and engineering, not code alone.
Speaker note: File organisation alone is worth 20 of 100 points on the final — the same weight as engineering and presentation combined.
Speaker note: These are not rubric points lost — a submission failing any one of these is not accepted at all.
Speaker note: This is a hard gate, checked before the rubric is even applied — fix these first, then worry about the score.
Speaker note: The demo is roughly 10 minutes per team — these are the categories of questions, not a fixed script.
Speaker note: "Both members" is checked literally — a repo with commits from only one teammate is itself a finding.
Speaker note: "Line by line" is literal — being able to point at the code and narrate it is what is being assessed here.
Speaker note: This is the literal "persistence" test from the rules slide, performed live in front of the instructor.
Speaker note: This section is why "shared understanding" is graded, not just tested for — the demo checks it directly.
Speaker note: Code review and the demo check exactly the honesty the ethics codes describe — this is not an abstract clause.
Speaker note: "Not graded" is stronger than "loses points" — an unexplainable section simply does not count toward the score.
Speaker note: A few of the most common ones — the full list is on the project guide page.
Speaker note: All three answers trace back to the same rule: the team-and-topic table is first-come, first-served, then locked.
Speaker note: These three all point back to the same "Acceptance conditions" slide earlier in this deck — it is worth re-reading.
Speaker note: 200 topics, eight groups of 25 — this deck shows the map and one worked example, not all 200.
Speaker note: All data is synthetic and every application is network-free — that rule from §5.3 holds across all eight groups.
Speaker note: The next two slides show exactly one topic box, in full, as a worked example of this pattern.
Speaker note: This is topic 001 of 200, shown in full so the pattern is clear before you browse the rest on the page.
Speaker note: Every one of V1–V6 and F1–F9 appears exactly once — that is the rule every one of the 200 topic boxes follows.
Speaker note: Putting only one topic in the deck is deliberate — 200 topic boxes belong on the page, not on 200 slides.
Speaker note: The syllabus, prerequisites and this guide are the three pages every student should have open in week 1.