Blame
|
1 | # C01 Overflow Activities |
||||||
| 2 | ||||||||
| 3 | Useful but non-essential activities for C01 (Design Brief and Project Management). These can be used as extension work, early finisher tasks, or alternative approaches. |
|||||||
| 4 | ||||||||
| 5 | ## Extension: Feasibility Deep Dive (T.E.L.O.S.) |
|||||||
| 6 | ||||||||
| 7 | For students who finish their design brief early and want to strengthen their feasibility argument. |
|||||||
| 8 | ||||||||
| 9 | **Activity:** Work through each T.E.L.O.S. dimension for your project: |
|||||||
| 10 | ||||||||
| 11 | | Dimension | Question to answer | |
|||||||
| 12 | |-----------|-------------------| |
|||||||
| 13 | | **Technical** | Do you have the skills and tools to build this? What will you need to learn? | |
|||||||
| 14 | | **Economic** | What resources does this need? Is it achievable with school resources? | |
|||||||
| 15 | | **Legal** | Any data privacy issues? Licensing concerns for libraries/assets? | |
|||||||
| 16 | | **Operational** | Will your target users actually use this? How does it fit into their routine? | |
|||||||
| 17 | | **Scheduling** | Can you build this in the available time? What would you cut if you run out of time? | |
|||||||
| 18 | ||||||||
| 19 | Write 2-3 sentences per dimension. This strengthens the feasibility section of the design brief and prepares students for probing questions in the C1-1 presentation. |
|||||||
| 20 | ||||||||
| 21 | **Time:** ~20 min |
|||||||
| 22 | ||||||||
| 23 | --- |
|||||||
| 24 | ||||||||
| 25 | ## Extension: Comparative Brief Analysis |
|||||||
| 26 | ||||||||
| 27 | For students who want to understand what separates a strong brief from a weak one. |
|||||||
| 28 | ||||||||
| 29 | **Activity:** Read the Adem's Gym example and the NiceQuiz example. Create a comparison table: |
|||||||
| 30 | ||||||||
| 31 | | Aspect | Brief A | Brief B | Which is stronger and why? | |
|||||||
| 32 | |--------|---------|---------|---------------------------| |
|||||||
| 33 | | Problem statement | | | | |
|||||||
| 34 | | User description | | | | |
|||||||
| 35 | | Language justification | | | | |
|||||||
| 36 | | Feasibility argument | | | | |
|||||||
| 37 | ||||||||
| 38 | Discuss with a partner. Could you improve the weaker brief? What would you change? |
|||||||
| 39 | ||||||||
| 40 | **Time:** ~15 min |
|||||||
| 41 | ||||||||
| 42 | --- |
|||||||
| 43 | ||||||||
| 44 | ## Extension: Mock Interview (Peer) |
|||||||
| 45 | ||||||||
| 46 | For students who finish Checkpoint C early and want to practice for the C1-3 interview. |
|||||||
| 47 | ||||||||
| 48 | **Activity:** Pair up. One student is the "teacher," one is the "student." The teacher uses this question progression: |
|||||||
| 49 | ||||||||
| 50 | 1. "Walk me through your project plan from start to finish." |
|||||||
| 51 | 2. "Why does [specific task] come before [other task]?" |
|||||||
| 52 | 3. "Show me a dependency. What happens if the first task is delayed by a week?" |
|||||||
| 53 | 4. "Where is your critical path? How did you identify it?" |
|||||||
| 54 | 5. "How will you know if your project is falling behind? What will you do about it?" |
|||||||
| 55 | ||||||||
| 56 | Swap roles after 10 minutes. Give each other feedback: what was convincing? Where did you hesitate? |
|||||||
| 57 | ||||||||
| 58 | **Time:** ~20 min (10 min each way) |
|||||||
| 59 | ||||||||
| 60 | --- |
|||||||
| 61 | ||||||||
| 62 | ## Extension: Risk Register |
|||||||
| 63 | ||||||||
| 64 | For students who want to push into high-level monitoring and planning. |
|||||||
| 65 | ||||||||
| 66 | **Activity:** Create a simple risk register for your project: |
|||||||
| 67 | ||||||||
| 68 | | Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation | |
|||||||
| 69 | |------|-------------------|-----------------|------------| |
|||||||
| 70 | | e.g., "Can't learn API in time" | M | H | "Start with simpler version, add complexity later" | |
|||||||
| 71 | ||||||||
| 72 | Identify 3-5 risks. For each, explain how your project plan accounts for it (or doesn't). This is excellent preparation for the C1-3 interview question about monitoring. |
|||||||
| 73 | ||||||||
| 74 | **Time:** ~15 min |
|||||||
| 75 | ||||||||
| 76 | --- |
|||||||
| 77 | ||||||||
| 78 | ## Alternative: Hand-Drawn Gantt Chart |
|||||||
| 79 | ||||||||
| 80 | If GitHub Projects is causing technical issues or a student works better on paper. |
|||||||
| 81 | ||||||||
| 82 | **Activity:** Draw a Gantt chart by hand on A3 paper: |
|||||||
| 83 | - X-axis: weeks (Term 2 and Term 3) |
|||||||
| 84 | - Y-axis: tasks grouped by PSM stage |
|||||||
| 85 | - Use coloured bars for each stage |
|||||||
| 86 | - Mark milestones with diamonds |
|||||||
| 87 | - Draw dependency arrows between tasks |
|||||||
| 88 | ||||||||
| 89 | Photograph and commit to GitHub. This satisfies the "using software" requirement if they then transfer it to GitHub Projects, or it can serve as their annotated plan for C1-3. |
|||||||
| 90 | ||||||||
| 91 | **Time:** ~25 min |
|||||||
| 92 | ||||||||
| 93 | --- |
|||||||
| 94 | ||||||||
| 95 | ## Alternative: Design Brief as a Pitch |
|||||||
| 96 | ||||||||
| 97 | Instead of a formal written brief, the student creates a 1-page "pitch document" — visual, concise, designed to convince someone to fund/support the project. They still need to cover all the same content (problem, solution, users, language, feasibility) but in a more visual format. |
|||||||
| 98 | ||||||||
| 99 | This can be done in addition to the formal brief as presentation preparation. The visual format forces students to distil their thinking. |
|||||||
| 100 | ||||||||
| 101 | **Time:** ~20 min |
|||||||
| 102 | ||||||||
| 103 | --- |
|||||||
| 104 | ||||||||
| 105 | ## Ongoing: AI Disclosure Log Prompts |
|||||||
| 106 | ||||||||
| 107 | Quick prompts students can use to update their AI disclosure log throughout C01: |
|||||||
| 108 | ||||||||
| 109 | - "I asked AI to..." — What was the prompt? |
|||||||
| 110 | - "AI produced..." — What did it generate? |
|||||||
| 111 | - "I kept / changed / rejected..." — What did you do with it? |
|||||||
| 112 | - "Because..." — Why? |
|||||||
| 113 | ||||||||
| 114 | Example entry: |
|||||||
| 115 | > I asked Claude to draft a feasibility section for my design brief. It produced a paragraph about technical feasibility using Python and fasthtml. I kept the structure but rewrote the specific details because Claude didn't know about Godot's limitations for my game project. I also added scheduling feasibility which Claude didn't mention. |
|||||||
| 116 | ||||||||
| 117 | Remind students: the log isn't assessed separately, but it's required evidence and strengthens their interview responses. |
|||||||
