Commit dfbf6b
2026-04-19 18:31:57 lisa: sd: remove obsolete C01-1/2/3 Checkpoint Proposal drafts; tidy Hub section| sd/C01-1-Checkpoint-Proposal.md .. /dev/null | |
| @@ 1,51 0,0 @@ | |
| - | # C01-1 Checkpoint Proposal: Design Brief Ready |
| - | |
| - | **Status:** Proposal (pending Jeremy's approval) |
| - | **Created:** 2026-04-12 |
| - | **Source:** TKT-004 — C1-1 Assessment Package |
| - | |
| - | --- |
| - | |
| - | ## Checkpoint A: Design Brief Ready |
| - | |
| - | This checkpoint gates C1-1 (Design Brief Presentation). A student who completes all items is ready to join the presentation queue. A student who hasn't completed the checkpoint uses class time to finish --- naturally reducing their validation time and depth. |
| - | |
| - | ### Student Self-Check Criteria |
| - | |
| - | Students can check each item themselves before the lesson: |
| - | |
| - | 1. **Problem/need/opportunity stated** --- Brief has a clear section naming a specific, concrete problem, need, or opportunity. |
| - | 2. **Solution described** --- Brief explains what the software does and how it addresses the problem. A reader unfamiliar with the project could understand the idea. |
| - | 3. **Users identified and described** --- Primary and secondary users are named with enough detail to picture them (not just "students" but specific types of users with context). |
| - | 4. **Programming language stated with reasons** --- Language or framework is named with an explanation of why it suits the project. |
| - | 5. **Feasibility and originality addressed** --- Brief includes a section on whether the project is achievable and what makes it different. |
| - | 6. **Artefact ready** --- Brief committed to GitHub, printed copy in hand, cue card prepared (quarter A4, key talking points only), practiced presenting at least once timed at ~5 minutes. |
| - | |
| - | ### Teacher Quick Check (circulating, <60 seconds per student) |
| - | |
| - | | Check | What to look for | |
| - | |-------|-----------------| |
| - | | Printed brief | Physical copy on desk, covers all 5 content sections. They exist and say something specific. | |
| - | | Cue card | Quarter A4 or smaller. Key words, not a script. | |
| - | | Quick verbal | "In one sentence, what problem does your project solve?" Clear + specific = ready. | |
| - | |
| - | ### Feedback Prompts (done to strong) |
| - | |
| - | | Area | Prompt | |
| - | |------|--------| |
| - | | Problem too vague | "Your problem is generic. Which specific people have this problem and when?" | |
| - | | Users generic | "You say 'teachers and students.' What does a teacher actually do with your app first?" | |
| - | | Language thin | "You chose Python. Why Python and not something else? What does it give you?" | |
| - | | Feasibility missing | "I see what you're building but not why you can build it. What's your argument?" | |
| - | | Originality unclear | "If I Googled this, what would I find? What's your twist?" | |
| - | | Ready for depth | "Now think about weaknesses. What could go wrong, and what would you do?" | |
| - | |
| - | --- |
| - | |
| - | ## Proposed Checklist Integration |
| - | |
| - | **Where:** C01-2026 checklist, before the C1-1 assessment tasks. |
| - | |
| - | **Suggestion:** Group learning tasks under "Checkpoint A tasks" heading so students can track their readiness. The checkpoint items above become the self-assessment criteria at the end of the learning sequence, before the presentation. |
| - | |
| - | **Note:** The full assessment package (teacher protocol, question bank, scoring guide) is in `SD26-Teachers/sat/C01-2026/C01-1-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist. |
| sd/C01-2-Checkpoint-Proposal.md .. /dev/null | |
| @@ 1,65 0,0 @@ | |
| - | # C01-2 Checkpoint Proposal: Gantt Chart / Project Board Ready |
| - | |
| - | **Status:** Proposal (pending Jeremy's approval) |
| - | **Created:** 2026-04-12 |
| - | **Source:** TKT-005 --- C1-2 Assessment Package |
| - | |
| - | --- |
| - | |
| - | ## Checkpoint B: Gantt Chart / Project Board Ready |
| - | |
| - | This checkpoint gates C1-2 (Writing Test). A student who completes all items has a solid project board and genuinely understands their tasks before the writing test. A student who hasn't completed the checkpoint sits the test with limited knowledge of their own plan --- naturally lower marks. |
| - | |
| - | ### Student Self-Check Criteria |
| - | |
| - | Students can check each item themselves before the lesson: |
| - | |
| - | 1. **Gantt chart format using software** --- Project plan is in Gantt chart format (GitHub Projects Roadmap View or equivalent). Each task shows as a bar with a start and end date on a timeline. Not just a task list. |
| - | |
| - | 2. **PSM stages for U3O2 covered** --- Chart includes tasks for Analysis (data collection, functional requirements, constraints, SRS) and Design (design ideas, evaluation criteria, detailed designs). |
| - | |
| - | 3. **PSM stages for U4O1 covered** --- Chart includes tasks for Development (setup, core features, GUI, documentation) and Evaluation (validation, testing, beta testing, evaluation against criteria). |
| - | |
| - | 4. **Reasonable task granularity** --- Each PSM stage has at least 2--3 specific activities. Not just 3--4 giant blocks. A teacher looking at the chart can see what the student is actually planning to do. |
| - | |
| - | ### Teacher Quick Check (circulating, <60 seconds per student) |
| - | |
| - | | Check | What to look for | |
| - | |-------|-----------------| |
| - | | Gantt format | Tasks display as bars on a timeline in Roadmap View. Not a plain list. | |
| - | | Both units | U3O2 tasks (analysis, design) AND U4O1 tasks (development, evaluation) are present. | |
| - | | Task granularity | 10+ tasks across stages, not just 3--4 giant blocks. | |
| - | | Quick verbal | "Point to one task and tell me why it matters for your project." Specific answer = ready. | |
| - | |
| - | ### Feedback Prompts (done to strong) |
| - | |
| - | | Area | Prompt | |
| - | |------|--------| |
| - | | Not Gantt format | "Switch to Roadmap View. Each task needs a start and end date so it shows as a bar." | |
| - | | Missing U4O1 | "Where is development and evaluation? Your chart needs both units." | |
| - | | Missing U3O2 | "Where are analysis and design? Those come first." | |
| - | | Tasks too coarse | "Break 'Development' down. What does development look like for your project?" | |
| - | | Tasks too vague | "'Do research' --- research what, specifically? What data are you collecting?" | |
| - | | Ready for depth | "In the writing test, you will need to explain why tasks matter to your project specifically." | |
| - | |
| - | --- |
| - | |
| - | ## Proposed Checklist Integration |
| - | |
| - | **Where:** C01-2026 checklist, under "Project Plan (C1-2)" section, before the assessment tasks. |
| - | |
| - | **Suggestion:** Group the existing learning tasks (PSM overview, set up GitHub Projects, add tasks, Gantt chart resources) under a "Checkpoint B tasks" heading. Add the self-check criteria above as the readiness gate before the writing test. |
| - | |
| - | **Additional learning task proposal:** Add "Task relevance drill" --- pick 3 tasks from your board, write 2--3 sentences each explaining why they matter for your project. This is direct practice for the writing test and can be done as homework or in-class warm-up. |
| - | |
| - | **Note:** The full assessment package (teacher protocol, marking guide, scoring guide) is in `SD26-Teachers/sat/C01-2026/C01-2-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist. |
| - | |
| - | --- |
| - | |
| - | ## Open Decision: Notes Policy |
| - | |
| - | The assessment package proposes **closed book** (no notes, no printed plan) for the writing test. This tests genuine understanding rather than ability to read a chart. |
| - | |
| - | **Alternative:** Allow printed Gantt chart as reference. Shifts test from "do you understand?" to "can you explain?" --- less discriminating for authenticity. |
| - | |
| - | Jeremy needs to decide before the test runs. |
| sd/C01-3-Checkpoint-Proposal.md .. /dev/null | |
| @@ 1,72 0,0 @@ | |
| - | # C01-3 Checkpoint Proposal: Annotated Plan Ready |
| - | |
| - | **Status:** Proposal (pending Jeremy's approval) |
| - | **Created:** 2026-04-12 |
| - | **Source:** TKT-006 --- C1-3 Assessment Package |
| - | |
| - | --- |
| - | |
| - | ## Checkpoint C: Annotated Plan Ready |
| - | |
| - | This checkpoint gates C1-3 (10-minute Interview). A student who completes all items has a genuine, annotated project plan and can walk the teacher through their planning decisions. A student who hasn't completed the checkpoint spends interview time trying to reconstruct their reasoning --- naturally lower marks. |
| - | |
| - | ### Student Self-Check Criteria |
| - | |
| - | Students can check each item themselves before the lesson: |
| - | |
| - | 1. **Milestones defined** --- Plan includes teacher-provided milestones (criterion due dates) AND at least 2 student-defined milestones (e.g., "Core features complete," "Beta-ready build"). Clearly marked on the Gantt chart. |
| - | |
| - | 2. **Task sequencing shown** --- Tasks are not a flat list. The order is intentional: tasks that depend on earlier tasks come after them. A reader can see why task X comes before task Y. |
| - | |
| - | 3. **Time allocations present** --- Every task has a start date and end date. Timeline is realistic --- not everything crammed into the last week. |
| - | |
| - | 4. **Dependencies identified** --- At least 2 dependencies are noted on the plan (annotated, colour-coded, or written next to tasks). A dependency means: "I cannot start task B until task A is finished." |
| - | |
| - | 5. **Annotations explaining choices** --- Plan has handwritten or digital annotations explaining _why_ things are structured this way. Not just labels --- reasoning. |
| - | |
| - | 6. **Artefact ready** --- Annotated plan is printed or saved on screen. Student can show it during the interview and point to specific parts. |
| - | |
| - | ### Teacher Quick Check (circulating, <60 seconds per student) |
| - | |
| - | | Check | What to look for | |
| - | |-------|-----------------| |
| - | | Milestones | At least 3 visible (teacher due dates + student-defined). Prompt: "Where are _your_ milestones?" | |
| - | | Sequencing | Tasks ordered, not random. Dependencies marked or implied. | |
| - | | Annotations | Handwritten notes, highlights, arrows explaining choices. Not blank. | |
| - | | Quick verbal | "Point to a dependency and tell me what happens if the first task is late." | |
| - | |
| - | ### Feedback Prompts (done to strong) |
| - | |
| - | | Area | Prompt | |
| - | |------|--------| |
| - | | No student milestones | "Where are _your_ milestones? What's a point where you'd stop and check progress?" | |
| - | | Flat task list | "Which task _must_ happen before which? Draw an arrow or write a note." | |
| - | | No annotations | "Why did you put data collection first? Write a note explaining your reasoning." | |
| - | | Unrealistic timeline | "3 days for development and 4 weeks for analysis --- does that match reality?" | |
| - | | No dependencies | "Which tasks can't start until another finishes? Find at least 2 and mark them." | |
| - | | Ready for depth | "Can you trace your critical path? That's what I'll ask about in the interview." | |
| - | |
| - | --- |
| - | |
| - | ## Proposed Checklist Integration |
| - | |
| - | **Where:** C01-2026 checklist, under "Planning Detail (C1-3)" section, before the assessment tasks. |
| - | |
| - | **Suggestion:** Group the existing learning tasks (add milestones/dependencies, "why monitor?" + peer review, annotate plan) under a "Checkpoint C tasks" heading. Add the self-check criteria above as the readiness gate before the interview. |
| - | |
| - | **Additional learning task proposals:** |
| - | - **"Interview rehearsal"** --- Walk a partner through your annotated plan while they ask questions from a provided question list. 10 min timed. Direct practice for the interview. |
| - | - **"Dependency mapping"** --- For each dependency on your plan, write what happens if the predecessor is delayed. Builds genuine understanding for interview. |
| - | |
| - | **Note:** The full assessment package (teacher protocol, question bank, scoring guide, worked examples) is in `SD26-Teachers/sat/C01-2026/C01-3-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist. |
| - | |
| - | --- |
| - | |
| - | ## Key VCAA Rubric Points for C1-3 |
| - | |
| - | The VCAA rubric (Indicator 3) has two important thresholds: |
| - | |
| - | - **7--8 threshold:** Student must explain _why_ the project needs to be monitored (project-specific, not generic) AND document student-provided milestones. |
| - | - **9--10 threshold:** Student must document dependencies and critical path AND _discuss how_ progress will be monitored and documented (tools, frequency, what they record). |
| - | |
| - | Monitoring is the key differentiator. Without monitoring reasoning, a student caps at 6. |
| sd/VCE Software Development Hub.md .. | |
| @@ 10,10 10,7 @@ | |
| The 4-checkpoint SAT structure for 2026: | |
| - | - **C01 — Proposal** |
| - | - [C01-1 Proposal](/sd/C01-1-Checkpoint-Proposal) |
| - | - [C01-2 Proposal](/sd/C01-2-Checkpoint-Proposal) |
| - | - [C01-3 Proposal](/sd/C01-3-Checkpoint-Proposal) |
| + | - **C01 — Design Brief & Project Management** |
| - [C01 Overflow](/sd/C01-Overflow) | |
| - [C01 Readiness Report](/sd/C01-Readiness-Report) | |