SS 3 Third Term

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Hardware: the physical components of a computer system.
• Software: the programs and data that run on hardware.
• Data representation: how numbers, text and other data are encoded for processing.
• Binary coded decimal (BCD): a binary code for decimal digits.
• Overflow: when a calculation exceeds the storage capacity.
• Underflow: when a calculation produces a value below the minimum representable.

Common misconceptions

• "More bits always mean faster processing." Additional bits increase range or precision, not speed.
• "Overflow cannot happen in modern systems." It can, if bounds are not checked.
• "Software has no impact on hardware performance." Inefficient code can bottleneck even powerful hardware.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Network: a connected system of two or more devices that can communicate.
• Internet: a global network of interconnected networks using the Internet Protocol (IP).
• Protocol: a set of rules governing data communication.
• TCP/IP: the foundational protocol suite for the Internet.
• DNS: Domain Name System, translating domain names to IP addresses.
• Firewall: a system that monitors and controls incoming and outgoing network traffic.

Common misconceptions

• "The internet and the World Wide Web are the same thing." The internet is the infrastructure; the web is one service on it.
• "Public Wi-Fi is safe if the website uses HTTPS." The connection to the access point is still exposed.
• "Firewalls block everything." Firewalls are configured with rules; misconfigured rules can leave gaps.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Algorithm: a step-by-step procedure for solving a problem.
• Program: an implementation of an algorithm in a programming language.
• Data structure: a way of organising data for efficient access and modification.
• Linked list: a linear collection of nodes where each points to the next.
• Stack: a LIFO (last-in, first-out) data structure.
• Queue: a FIFO (first-in, first-out) data structure.

Common misconceptions

• "An algorithm and a program are the same." An algorithm is the logic; a program is the code.
• "Stacks and queues are interchangeable." They have different access patterns (LIFO vs FIFO).
• "Arrays are the only data structure." Trees, graphs and hash tables are also essential.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Database: an organised collection of structured information, or data, typically stored electronically.
• SQL (Structured Query Language): the standard language for relational database operations.
• Schema: the structural definition of a database.
• Query: a request for data from a database.
• Normalisation: organising data to reduce redundancy.
• Primary key: a unique identifier for each row in a table.

Common misconceptions

• "SQL is only for large databases." It is used from small scripts to enterprise systems.
• "Normalisation always improves performance." Over-normalisation can add join overhead.
• "A primary key can contain NULL values." By definition, a primary key must be unique and not NULL.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Theory paper: a written examination assessing knowledge and understanding.
• Mark allocation: the marks assigned to each question or part.
• Distractor: a plausible but incorrect option in a multiple-choice question.
• Command word: the verb indicating what the answer must do (e.g., explain, calculate, compare).
• Exemplar answer: a model answer used as a reference for marking.

Common misconceptions

• "Theory questions carry fewer marks than practicals." Theory and practical have separate mark schemes.
• "Command words are optional." They define the expected answer format and depth.
• "All theory answers are essay-length." Many are short-answer or calculation.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. 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

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Review: a structured look at performance and identification of improvement areas.
• Targeted revision: focusing on specific weak topics rather than broad review.
• Action plan: specific steps to address identified gaps before the examination.
• Feedback: information from the teacher about what was done well and what needs work.
• Metacognition: thinking about one's own thinking and learning processes.

Common misconceptions

• "Mock results are final." They are diagnostic; improvement is always possible.
• "If the teacher didn't mention it, it won't be examined." Examination topics often build on classwork.
• "Revision should be passive." Active recall and practice questions are more effective.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete the practical/problem-solving task and document the steps taken.
5. Test results with more than one example where appropriate; debug or revise errors.
6. 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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Past question: a real examination question from a previous SSCE or NECO sitting.
• Examination pattern: the recurring format and style of questions in external exams.
• Time management: allocating the right amount of time to each question or section.
• Answer strategy: approaching different question types (objective, short-answer, essay).
• Examiner report: official commentary on how candidates performed on a question.

Common misconceptions

• "Past questions are repeated verbatim." They are adapted, not copied.
• "Only the latest syllabus is examined." SSCE questions often test foundational concepts.
• "If I know the topic, I will get full marks." Method and clarity of presentation also count.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Complete a past-question paper under timed conditions.
5. Mark their own answers using the official mark scheme.
6. 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 past-question papers, mark schemes and examiners' reports. Use fictional or anonymised data where real data is sensitive.

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.

Lesson objectives

By the end of the lesson sequence, learners should be able to:

1. Define the central concepts and use precise technical vocabulary.
2. Explain the relevant components, models, processes or principles.
3. Analyse, compare, calculate, design or justify solutions using appropriate criteria.
4. Apply the concepts in a practical task and produce inspectable evidence.
5. Test or review their work, identify limitations and explain safe, ethical or secure practice where relevant.

Key vocabulary

• Examination strategy: a plan for approaching the examination paper and managing time.
• Section order: the recommended sequence for attempting different sections.
• Time allocation: minutes designated for each question or section.
• Final check: reviewing all answers before submitting the paper.
• Confidence building: reminding learners of the preparation they have completed.

Common misconceptions

• "I should start with the first section." Sometimes starting with the easiest section builds confidence.
• "More time on a question always means more marks." Quality and correctness matter more than time spent.
• "I can cram the night before." Spaced revision is far more effective.

Teacher activities

1. Open with a diagnostic/retrieval task linked to prerequisite knowledge.
2. Present objectives, technical vocabulary and the problem or use case.
3. Teach through concise explanation, annotated diagrams, worked examples and live demonstrations.
4. Model the expected reasoning or technical workflow, including common failure cases.
5. Set guided practice and then an independent or team task; monitor progress and provide targeted feedback.
6. Facilitate peer review, question learners on design decisions and consolidate the lesson.

Student activities

1. Complete the starter and identify gaps in prerequisite knowledge.
2. Annotate notes, diagrams, code, tables or process models.
3. Explain a concept or predict the outcome of a worked example.
4. Review all key topics using the revised grid.
5. Practise one past-question paper under timed conditions.
6. 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 revision grids, timed past papers and model answers. Use fictional or anonymised data where needed.

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.

Lesson objectives

At the close of the examination week, candidates should be able to:

1. Recall and apply the term's concepts under examination conditions.
2. Answer objective, short-answer and essay items.
3. Complete and save a practical task.
4. Explain a design decision to the examiner.
5. Submit every section on time.

Key vocabulary

• Examination week: the week when external SSCE or NECO papers are taken.
• Invigilator: the supervisor responsible for conducting the examination fairly.
• Timetable: the schedule showing when each paper takes place.
• Conduct: the rules and behaviour expected during an examination.
• Script: the answer booklet or paper submitted by a candidate.

Common misconceptions

• "Calculators are allowed in all papers." Only papers where stated may use calculators.
• "I can leave early if I finish." Remaining seated until the full duration is required.
• "Examiners want long answers." They want correct and concise answers matching the command word.

Teacher activities

1. Confirm the timetable, venue, seating and invigilators one week ahead.
2. Print Sections A to C and prepare one practical paper per candidate.
3. Check every machine and the power backup the day before.
4. Prepare offline equivalents at each station so that equipment failure does not cost marks.
5. Brief learners on the paper structure, the time for each section and the materials allowed.
6. Return scripts with the marked points visible and retain the practical files.

Student activities

1. Attend the briefing and note the time allowed per section.
2. Complete Section A, then Section B, allocating time as instructed.
3. Move through the practical stations in the assigned order.
4. Save work with the correct filename and confirm it opens before leaving the station.
5. Answer the examiner's question on their practical output.
6. Collect marked scripts and record the topics to revise in Term 1.

Practical / learning evidence

The completed examination script, the saved practical file for each candidate, and the practical rubric sheets. Retain scripts, marking guides, rubrics and representative learner work for moderation as required by the assessment framework.

Resources and preparation

Printed question papers and answer sheets, a marking guide and rubric per station, working computers with Word or LibreOffice Writer, a stopwatch, printed keyboard diagrams and device picture cards. Check every machine the day before, and prepare two spare machines where possible. Ensure power backup and an offline alternative for each station.

Assessment for learning

Mark Section C against the practical rubric: task interpretation, procedure, technical accuracy, safe use, file naming and explanation. Moderate a sample of scripts across all sections, and flag any question where more than a third of learners scored zero, so that the teaching of that item can be reviewed.

Inclusion and access

Provide large print, extra time and a quiet room where approved. Offer the paper equivalent at each station so that equipment failure does not cost marks. Keep the practical criteria identical across the digital and paper routes.

Teacher reflection

Record the topics that needed reteaching, the practical constraints and any approved change to pacing. Keep the error log summary with the marked scripts.

Assessment structure

Section A objective 20, Section B short answer 30, Section C essay 10 and Section D practical 20 give a total of 80 marks. The practical rubric covers task interpretation, procedure, accuracy, safe use, file naming and explanation.