Today you show your CBA work, get feedback, fix one thing, and look back.
This is the final CBA checkpoint, run across two periods. Your project or portfolio is ready to show.
- Period 1: present and peer-test
- Period 2: one improvement from the feedback, a short course-wide look back, and a clear reflection
You will hear feedback from peers, act on one improvement, and reflect on how your learning and problem-solving grew across the three strands:
- Strand 1 Introducing computer science
- Strand 2 Let's get connected
- Strand 3 Coding at the next level
You are not finishing the whole CBA from scratch here. You are showing what you have built and thought through, then packaging the evidence.
This is the final teacher-led CBA checkpoint across two 40-minute periods (80 minutes in total). Students should arrive with their documented project or portfolio already packaged from the previous checkpoint.
Period shape: Period 1 covers Start, how presenting works, and the presentation / peer-testing rounds. Period 2 covers one improvement from feedback, Make sense, Reflect, and the save / package close.
Before the lesson: confirm the presentation order and small groups (prefer three or four; five only if needed), decide whether any external users (another class, a teacher, a parent helper) can try software projects, and display the class AI ground rules so students can name any AI use honestly if asked. Write the four presentation points and the two feedback rules on the board before students arrive.
Remind the class that the CBA is reported on the JCPA against the NCCA Features of Quality. Feedback today is formative peer feedback; the Features of Quality judgement sits with the teacher.
Each presentation is short and focused. Whether you chose the software project or the portfolio, you cover the same four points:
- What you made or collected, in plain language.
- Why it mattered, the problem, interest, or question behind it.
- One decision you changed along the way, and what prompted the change.
- How someone else can understand the work, pointing to your documentation, comments, or reflection notes.
Listeners give two things only: one strength and one clear question. Write both on a feedback slip or sticky note so the presenter can keep them. If you are in a project team of two or three, share the speaking so everyone is heard.
Keep this tight. Model a 60-second example of good feedback so students do not default to vague praise. Say something like: One strength: your three-step start instructions meant I could open the project and play without asking you anything. One question: what happens if the player enters a number outside the range you expected? Did anyone try that, and where is that noted in your documentation?
Write the four presentation points and the two feedback rules on the board and leave them up for both periods. Hand out simple feedback slips (or sticky notes) labelled Strength / Question before the round starts.
Look-fors in a strong presentation:
- The student can explain the work without reading slides word for word.
- Documentation is visible and used, not just claimed.
- Any AI help is named honestly and the student can still explain every part as their own thinking.
- Team projects share airtime fairly.
If no external users are available, peer testing still meets the spirit of LO 3.8 for this checkpoint: someone who did not build it tries it or reads it.
Present your documented project or portfolio to your small group. Run through the four points. Your teacher will set the timer for your group.
While you listen:
- On your feedback slip, note one strength that is specific (what worked, and why it helped).
- Write one question that would help the presenter improve clarity, testing, or documentation.
- If it is a software project, try it as a user when invited: follow the instructions without help first, then note where you got stuck on the same slip.
Hand the slip to the presenter at the end of their slot. Do not start rewriting your own work yet; that comes in Period 2.
Suggested timing in Period 1
Use most of this block for short presentation slots in small groups. Prefer groups of three or four. If you must use five, cut speaking to about 3 minutes and feedback to about 1 minute, and keep the timer visible. A workable pattern in a group of three is about 5 minutes speaking plus 2 minutes feedback per person or team. In a group of four or five, tighten to about 3 to 4 minutes speaking plus 1 to 2 minutes feedback. Project teams present once as a team. Portfolio students present individually. Run two named mini-rounds. Call the first Round A. After a 1-minute reset, run Round B. That keeps wait time short and energy high.
Teaching tips
- Keep a visible timer and a speaking order so the round does not stall. Optionally rotate one student as timekeeper per group.
- Between slots, keep listeners accountable: they must try the demo when invited and finish the strength-and-question slip before the next speaker starts.
- Circulate with a simple checklist against the Features of Quality in student-friendly language: is the work understandable, is the process evidenced, is testing or user reaction visible, is reflection honest.
- For external users, brief them to try the work silently first, then ask one question.
- If a student freezes, prompt with the four points on the board rather than taking over the explanation.
- At the period break, students keep their feedback slips with their CBA package. No rewriting yet.
Differentiation
Allow cue cards with the four headings only. For anxious presenters, start in a pair before the wider group. Stretch: invite one presenter to explain a tricky section of code or a design decision in more depth after the main slot.
Done looks like: feedback written down, one chosen action, and either the change made or a clear note of what you would change next if time has run out.
On your own or with your project team:
- Read the strength and question slips you received.
- Choose one piece of feedback you can act on before the work is finally submitted.
- Make that small improvement if time allows (clearer comment, sharper reflection sentence, fix a rough edge a user hit, tighten a label or heading).
- Note what you changed and why in your CBA evidence.
This opens Period 2. It is still part of the checkpoint, not a full rebuild. Steer students toward improvements that make the work clearer to judge: documentation, a user-facing instruction, a missing test note, or an honest AI-use line.
Watch for teams that only praised each other. If someone received no actionable feedback, supply one neutral question yourself, for example Where would a new user get stuck first?
With the longer block, expect most students to complete a small change and write the note, not only plan it.
Pull the thread across the whole course for a moment:
- Strand 1 Introducing computer science: you moved from first sequences and games into early problem-solving.
- Strand 2 Let's get connected: you worked with the internet, data, websites, physical computing and AI.
- Strand 3 Coding at the next level: you moved into text code and documented programs.
The four steps of computational thinking (decomposition, pattern recognition, abstraction, algorithms) and the habit of testing and fixing showed up whenever a build got hard.
Your CBA presentation is evidence of that growth: not only a finished product or a neat folder, but the story of how your problem-solving changed.
Keep this to a few minutes. Do not lecture. Invite two or three students to name one skill that transferred (for example debugging routine, planning before building, reading someone else's code), then move straight into the Reflect prompts. Link forward gently to Leaving Certificate Computer Science for those who want the next step, without pressure.
Unlock the full learning experience
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.