Sparklabs Learning / Digital Technology
SS 3 Third Term
Week 6: Mock Examination 2: Practical
- School
- Creative Brains Academy
- Subject
- Digital Technology
- Pack
- Curriculum only
- Prepared
- 7 November 2026
Week index
- 01Revision: Hardware, Software and Data Representation
- 02Revision: Networks, Internet and Security
- 03Revision: Programming, Algorithms and Data Structures
- 04Revision: Databases and SQL
- 05Mock Examination 1: Theory
- 06Mock Examination 2: Practical
- 07Mock Review and Targeted Revision
- 08SSCE Past Questions Practice
- 09Final Revision and Examination Strategy
- 10SSCE / NECO Examinations
Week 6 / Third Term
Mock Examination 2: Practical
Curriculum outline
Lesson objectives
By the end of the lesson sequence, learners should be able to:
- Define the central concepts and use precise technical vocabulary.
- Explain the relevant components, models, processes or principles.
- Analyse, compare, calculate, design or justify solutions using appropriate criteria.
- Apply the concepts in a practical task and produce inspectable evidence.
- Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.
Key vocabulary
- Practical assessment: a hands-on task evaluating skills and procedures.
- Rubric: a scoring guide used to evaluate performance against criteria.
- Task interpretation: understanding what the examination question requires.
- Technical accuracy: correctness of the produced artefact or solution.
- File naming and saving: correct conventions for naming and storing practical files.
- Safe use: following health, safety and ethical guidelines during practical work.
Common misconceptions
- "Practical marks are easy to get." They require precise execution against criteria.
- "I can finish early and leave." Remaining time should be used for checking work.
- "The rubric only cares about the final result." Intermediate steps often carry significant marks.
Teacher activities
- Open with a diagnostic/retrieval task linked to prerequisite knowledge.
- Present objectives, technical vocabulary and the problem or use case.
- Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
- Model the expected reasoning or technical workflow, including common failure cases.
- Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
- Facilitate peer review, question learners on design decisions and consolidate the lesson.
Student activities
- Complete the starter and identify gaps in prerequisite knowledge.
- Annotate notes, diagrams, code, tables or process models.
- Explain a concept or predict the outcome of a worked example.
- Complete the practical/problem-solving task and document the steps taken.
- Test results with more than one example where appropriate; debug or revise errors.
- Present or submit the output and reflect on quality, limitations and responsible use.
Practical / learning evidence
Produce a topic-appropriate artefact such as a labelled architecture/network diagram, algorithm, flowchart, pseudocode, tested program, database schema/query, web page, spreadsheet, graphics design, security policy, project document or structured written analysis. The teacher must define the precise task, constraints and success criteria.
Resources and preparation
Computers/devices, required software or development environment, projector, sample datasets, notes and reliable power. Prepare test data and an offline route where possible. Use fictional or anonymised data; do not expose personal learner information in demonstrations.
Assessment for learning
Assess conceptual precision, reasoning, technical correctness, test coverage, safe/ethical practice, documentation and ability to justify decisions. Use questioning, code/output inspection, practical demonstration, short written analysis and peer review. Record misconceptions and reteaching needs.
Inclusion and extension
Provide scaffolded examples, reference sheets, accessible formats and structured roles for group tasks. Extend advanced learners with edge cases, larger datasets, performance/security considerations or alternative solution designs. Avoid assuming equal access to devices or connectivity outside school.