Commit 61debf
2026-04-25 21:18:46 lisa: Restructure C01: add C01-home, consolidate Critical Path under C01 Hub now links to /sd/C01/C01-home so we have room to add C02..C05 landing pages as those checkpoints come up. Critical Path moved out of the top-level sd/ into sd/C01/ with the richer 10-task example. Adds Mr Chen's SAT GitHub Projects video walk-through as a key- concept page. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>| /dev/null .. sd/C01/C01-home.md | |
| @@ 0,0 1,31 @@ | |
| + | # C01 — Design Brief & Project Management |
| + | |
| + | Hamilton College · Year 12 · 2026 |
| + | |
| + | The first SAT checkpoint covers your design brief, your project plan (Gantt chart in GitHub Projects), and how you keep that plan trustworthy through the year. |
| + | |
| + | --- |
| + | |
| + | ## Key concepts |
| + | |
| + | Short explainers with diagrams and videos for the concepts you'll be quizzed on at validation: |
| + | |
| + | - [Problem-Solving Methodology](/sd/C01/Problem-Solving%20Methodology) — the four stages (Analysis, Design, Development, Evaluation) and their activities |
| + | - [Testing vs Validation vs Evaluation](/sd/C01/Testing%20vs%20Validation%20vs%20Evaluation) — three similar-sounding terms that mean different things |
| + | - [Critical Path](/sd/C01/Critical%20Path) — the longest chain of dependent tasks; how to find it and why it matters for C1-3 |
| + | - [TELOS Feasibility](/sd/C01/TELOS%20Feasibility) — Technical, Economic, Legal, Operational, Scheduling — the feasibility framework for your design brief |
| + | - [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) — what GitHub Projects renders, what it doesn't, and how to close the gap |
| + | - [AI Disclosure](/sd/C01/AI%20Disclosure) — how to log AI use so your work stays authentic |
| + | - [Mr Chen's SAT GitHub Projects](/sd/C01/Mr%20Chen's%20SAT%20GitHub%20Projects) — a video walk-through of the same kind of project board you're building, on a real complete example |
| + | |
| + | ## Other C01 material |
| + | |
| + | - [Overflow](/sd/C01/Overflow) |
| + | |
| + | ## Resources |
| + | |
| + | - [C01 Resources](/sd/Resources/C01-Resources) — per-checkpoint reading and reference material |
| + | |
| + | --- |
| + | |
| + | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
| sd/C01/Critical Path.md .. | |
| @@ 14,45 14,75 @@ | |
| ## Finding it by eyeball | |
| - | Here's a 19-day project with 8 tasks (A–H): |
| + | Here's a 15-day project with 10 tasks (A–J) and an explicit predecessor table: |
| + | |
| + | | Activity | Predecessor | Duration | |
| + | |----------|-------------|----------| |
| + | | A | — | 2 | |
| + | | B | — | 3 | |
| + | | C | — | 1 | |
| + | | D | A | 2 | |
| + | | E | B, C | 4 | |
| + | | F | D | 1 | |
| + | | G | D, E | 3 | |
| + | | H | F, G | 5 | |
| + | | I | G | 3 | |
| + | | J | E | 2 | |
| ```mermaid | |
| gantt | |
| - | dateFormat D |
| - | axisFormat Day %d |
| + | title Project Schedule |
| + | dateFormat YYYY-MM-DD |
| + | axisFormat %d |
| tickInterval 1day | |
| - | section Critical path |
| - | A : crit, a, 0, 3d |
| - | B : crit, b, after a, 4d |
| - | D : crit, d, after b, 5d |
| - | G : crit, g, after d, 4d |
| - | H : crit, h, after g, 3d |
| - | |
| - | section Off-path (slack) |
| - | C : c, 0, 5d |
| - | E : e, after c, 4d |
| - | F : f, after b, 2d |
| + | section Tasks |
| + | A :a, 2024-01-01, 2d |
| + | B :b, 2024-01-01, 3d |
| + | C :c, 2024-01-01, 1d |
| + | D :d, after a, 2d |
| + | E :e, after b c, 4d |
| + | F :f, after d, 1d |
| + | G :g, after d e, 3d |
| + | H :h, after f g, 5d |
| + | I :i, after g, 3d |
| + | J :j, after e, 2d |
| ``` | |
| + | > [!info] How to read the axis |
| + | > Each number on the axis is a working day. The project starts at the beginning of day 01 and finishes at the end of day 15. A bar labelled "days 01–03" means the task runs for the whole of days 1, 2, and 3 — a 3-day duration. |
| + | |
| Trace the chain where bars touch end-to-end with **no gap**: | |
| - | - **A** (days 0–3) |
| - | - **B** (days 3–7) |
| - | - **D** (days 7–12) |
| - | - **G** (days 12–16) |
| - | - **H** (days 16–19) |
| + | - **B** (days 01–03) — 3 days |
| + | - **E** (days 04–07) — 4 days, starts the instant B finishes |
| + | - **G** (days 08–10) — 3 days, starts the instant E finishes |
| + | - **H** (days 11–15) — 5 days, starts the instant G finishes |
| + | |
| + | **Critical path: B → E → G → H** (total 3 + 4 + 3 + 5 = 15 days). |
| - | **Critical path: A → B → D → G → H.** |
| + | ### Why the other tasks aren't on it |
| - | ### Why C, E, F aren't on it |
| + | These tasks have **slack** — they can slip without delaying the project end date: |
| - | These tasks have **slack** — they can slip without delaying the project end date. Task F finishes at day 7, but its successor G doesn't start until day 12. That's a 5-day gap: F has **5 days of slack**. You could delay F by up to 5 days and the project still finishes on time. |
| + | - **A** runs days 01–02, and its successor D starts on day 03. No slack between A and D. But D finishes on day 04, while G (D's successor) doesn't start until day 08. So the A → D chain has **3 days of slack**. |
| + | - **C** finishes on day 01, but E doesn't start until day 04. C has **2 days of slack**. |
| + | - **F** finishes on day 05, but H doesn't start until day 11. F has **5 days of slack**. |
| + | - **I** finishes on day 13, but the project ends on day 15. I has **2 days of slack**. |
| + | - **J** finishes on day 09, but the project ends on day 15. J has **6 days of slack** — the most of any task. |
| ### The rule | |
| Look for the chain where there's **zero breathing room** between the end of one bar and the start of the next. That's your critical path. | |
| + | A useful shortcut: the critical path always runs through whichever predecessor finishes **last** at each merge point. |
| + | |
| + | - At E's merge, B (ends day 03) finishes after C (ends day 01), so B is on the critical path, not C. |
| + | - At G's merge, E (ends day 07) finishes after D (ends day 04), so E wins. |
| + | - At H's merge, G (ends day 10) finishes after F (ends day 05), so G wins. |
| + | |
| + | Follow the "last to finish" predecessor backwards from the end and you've traced the critical path. |
| + | |
| ## Why it matters at validation | |
| The C1-3 interview rubric requires level 9–10 students to *document dependencies and the critical path* (`C012-Roadmap-vs-Gantt.md`). A Roadmap View screenshot with no annotations cannot evidence this — you must add dependency arrows, highlight the critical path, and label slack on non-critical tasks before your interview. | |
| /dev/null .. sd/C01/Mr Chen's SAT GitHub Projects.md | |
| @@ 0,0 1,28 @@ | |
| + | # Mr Chen's SAT GitHub Projects |
| + | |
| + | A walk-through of Mr Chen's own SAT GitHub Projects board — the same kind of project plan you are building for C1-2 and C1-3, demonstrated on a real, complete example. |
| + | |
| + | --- |
| + | |
| + | ## Watch (≈ video) |
| + | |
| + | {{Video|src=https://www.youtube.com/watch?v=RmrLJvvAaQI}} |
| + | |
| + | --- |
| + | |
| + | ## What to notice |
| + | |
| + | - **PSM stages as lanes.** Tasks are grouped into Analysis, Design, Development, Evaluation via the Status field — same structure your board should have. |
| + | - **Start and end dates on every task.** Roadmap View only renders bars for tasks that have both dates set. Empty tasks disappear from the timeline. |
| + | - **Milestones.** Watch how milestones are distinguished from regular tasks — without a label they look identical on the bar. |
| + | - **Where the gap appears.** Even on this complete board, the dependency arrows, critical path highlight, and slack times are not drawn — they have to be added on top of an exported screenshot. See [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) for how to close that gap. |
| + | |
| + | ## See also |
| + | |
| + | - [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) |
| + | - [Critical Path](/sd/C01/Critical%20Path) |
| + | - [Problem-Solving Methodology](/sd/C01/Problem-Solving%20Methodology) |
| + | |
| + | --- |
| + | |
| + | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
| sd/Critical Path.md .. /dev/null | |
| @@ 1,107 0,0 @@ | |
| - | # Critical Path |
| - | |
| - | Identifying the critical path is the difference between a level 9–10 project plan and a screenshot of a Gantt chart — it is the one concept the C1-3 interview tests hardest on planning. |
| - | |
| - | ## Start with a Gantt chart |
| - | |
| - | {{Video|src=https://www.youtube.com/watch?v=D9xNrD3APg4}} |
| - | |
| - | A Gantt chart shows tasks as horizontal bars on a timeline. The length of each bar = the task's duration. The position of each bar encodes dependencies: a successor task's bar can't start until its predecessor's bar ends. Your GitHub Projects **Roadmap View** is a Gantt chart — it just doesn't label the critical path for you. See [Roadmap View vs Gantt Chart](/sd/Roadmap%20View%20vs%20Gantt%20Chart) for how they compare. |
| - | |
| - | ## The critical path — the bottleneck |
| - | |
| - | Think of the critical path as the **bottleneck chain**: the longest sequence of dependent tasks from the very start of your project to the very end. It sets the **minimum possible finish date**. If any task on this chain slips by a day, the whole project finishes a day late — there is no buffer anywhere along it. |
| - | |
| - | ## Finding it by eyeball |
| - | |
| - | Here's a 15-day project with 10 tasks (A–J) and an explicit predecessor table: |
| - | |
| - | | Activity | Predecessor | Duration | |
| - | |----------|-------------|----------| |
| - | | A | — | 2 | |
| - | | B | — | 3 | |
| - | | C | — | 1 | |
| - | | D | A | 2 | |
| - | | E | B, C | 4 | |
| - | | F | D | 1 | |
| - | | G | D, E | 3 | |
| - | | H | F, G | 5 | |
| - | | I | G | 3 | |
| - | | J | E | 2 | |
| - | |
| - | ```mermaid |
| - | gantt |
| - | title Project Schedule |
| - | dateFormat YYYY-MM-DD |
| - | axisFormat %d |
| - | tickInterval 1day |
| - | |
| - | section Tasks |
| - | A :a, 2024-01-01, 2d |
| - | B :b, 2024-01-01, 3d |
| - | C :c, 2024-01-01, 1d |
| - | D :d, after a, 2d |
| - | E :e, after b c, 4d |
| - | F :f, after d, 1d |
| - | G :g, after d e, 3d |
| - | H :h, after f g, 5d |
| - | I :i, after g, 3d |
| - | J :j, after e, 2d |
| - | ``` |
| - | |
| - | > [!info] How to read the axis |
| - | > Each number on the axis is a working day. The project starts at the beginning of day 01 and finishes at the end of day 15. A bar labelled "days 01–03" means the task runs for the whole of days 1, 2, and 3 — a 3-day duration. |
| - | |
| - | Trace the chain where bars touch end-to-end with **no gap**: |
| - | |
| - | - **B** (days 01–03) — 3 days |
| - | - **E** (days 04–07) — 4 days, starts the instant B finishes |
| - | - **G** (days 08–10) — 3 days, starts the instant E finishes |
| - | - **H** (days 11–15) — 5 days, starts the instant G finishes |
| - | |
| - | **Critical path: B → E → G → H** (total 3 + 4 + 3 + 5 = 15 days). |
| - | |
| - | ### Why the other tasks aren't on it |
| - | |
| - | These tasks have **slack** — they can slip without delaying the project end date: |
| - | |
| - | - **A** runs days 01–02, and its successor D starts on day 03. No slack between A and D. But D finishes on day 04, while G (D's successor) doesn't start until day 08. So the A → D chain has **3 days of slack**. |
| - | - **C** finishes on day 01, but E doesn't start until day 04. C has **2 days of slack**. |
| - | - **F** finishes on day 05, but H doesn't start until day 11. F has **5 days of slack**. |
| - | - **I** finishes on day 13, but the project ends on day 15. I has **2 days of slack**. |
| - | - **J** finishes on day 09, but the project ends on day 15. J has **6 days of slack** — the most of any task. |
| - | |
| - | ### The rule |
| - | |
| - | Look for the chain where there's **zero breathing room** between the end of one bar and the start of the next. That's your critical path. |
| - | |
| - | A useful shortcut: the critical path always runs through whichever predecessor finishes **last** at each merge point. |
| - | |
| - | - At E's merge, B (ends day 03) finishes after C (ends day 01), so B is on the critical path, not C. |
| - | - At G's merge, E (ends day 07) finishes after D (ends day 04), so E wins. |
| - | - At H's merge, G (ends day 10) finishes after F (ends day 05), so G wins. |
| - | |
| - | Follow the "last to finish" predecessor backwards from the end and you've traced the critical path. |
| - | |
| - | ## Why it matters at validation |
| - | |
| - | The C1-3 interview rubric requires level 9–10 students to *document dependencies and the critical path* (`C012-Roadmap-vs-Gantt.md`). A Roadmap View screenshot with no annotations cannot evidence this — you must add dependency arrows, highlight the critical path, and label slack on non-critical tasks before your interview. |
| - | |
| - | "Trace your critical path" is a Tier 4 interview question. The expected response is to point to your annotated plan and explain: which tasks form the chain, why each dependency exists, what the minimum project duration is, and which tasks have slack. Saying "I think these tasks are the most important ones" is not an answer — the critical path is defined by **dependency chains and duration**, not importance (`C013-Milestones-and-Dependencies.md`). |
| - | |
| - | > Common mistake: confusing "important tasks" with "critical path tasks." Some important tasks have slack and are not on the critical path. Some critical path tasks are routine — they are critical because of where they sit in the dependency chain, not because they are difficult. |
| - | |
| - | ## Go deeper — the maths |
| - | |
| - | If you want to calculate critical path the formal way (EST, LST, EFT, LFT, float), watch this: |
| - | |
| - | {{Video|src=https://www.youtube.com/watch?v=Yzmpp49KKg0}} |
| - | |
| - | ## See also |
| - | |
| - | - [Problem-Solving Methodology](/sd/Problem-Solving%20Methodology) |
| - | - [Roadmap View vs Gantt Chart](/sd/Roadmap%20View%20vs%20Gantt%20Chart) |
| - | |
| - | --- |
| - | |
| - | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
| sd/VCE Software Development Hub.md .. | |
| @@ 8,20 8,7 @@ | |
| ## SAT (School-Assessed Task) — Checkpoints | |
| - | ### C01 — Design Brief & Project Management |
| - | |
| - | Key concepts — short explainers with diagrams and videos for the concepts you'll be quizzed on at validation: |
| - | |
| - | - [Problem-Solving Methodology](/sd/C01/Problem-Solving%20Methodology) — the four stages (Analysis, Design, Development, Evaluation) and their activities |
| - | - [Testing vs Validation vs Evaluation](/sd/C01/Testing%20vs%20Validation%20vs%20Evaluation) — three similar-sounding terms that mean different things |
| - | - [Critical Path](/sd/C01/Critical%20Path) — the longest chain of dependent tasks; how to find it and why it matters for C1-3 |
| - | - [TELOS Feasibility](/sd/C01/TELOS%20Feasibility) — Technical, Economic, Legal, Operational, Scheduling — the feasibility framework for your design brief |
| - | - [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) — what GitHub Projects renders, what it doesn't, and how to close the gap |
| - | - [AI Disclosure](/sd/C01/AI%20Disclosure) — how to log AI use so your work stays authentic |
| - | |
| - | Other C01 material: |
| - | |
| - | - [Overflow](/sd/C01/Overflow) |
| + | - [C01 — Design Brief & Project Management](/sd/C01/C01-home) |
| ## Resources | |