SS 1 Second Term

Lesson objectives

By the end of the week, learners should be able to:

1. Define a problem and state how to solve it step by step.
2. Distinguish a problem from a solution by separating steps into an algorithm.
3. Name three types of algorithm: sequential, selection and iteration.
4. State why an algorithm must be precise about inputs and outputs.
5. Trace a simple sequential algorithm on paper.

Key vocabulary

• Problem: a task requiring a clear path toward an answer.
• Algorithm: a finite sequence of precise instructions solving one problem.
• Sequential algorithm: a list of steps carried out in order.
• Selection algorithm: an algorithm containing if-then-else branches.
• Iteration algorithm: an algorithm repeating steps under a condition.
• Input: data entering an algorithm.
• Output: data leaving an algorithm as the result.
• Finite: an algorithm that stops after a fixed number of steps.

Common misconceptions

• "An algorithm is a finished answer." An algorithm is the procedure; the answer comes after running it.
• "Algorithms always use loops." Sequential algorithms solve problems without repetition.
• "An algorithm can change what it does halfway through." Algorithms are complete before execution begins.

Teacher activities

1. Starter: present the problem "calculate the average of five numbers" and ask how to start solving it.
2. Define algorithm and model writing the problem steps sequentially on the board.
3. Introduce selection and iteration by modifying the same problem with branches and loops.
4. Emphasise precision in input, output and control structures.
5. Trace the resulting three versions step by step on paper.
6. Close with the exit question about why precision matters.

Student activities

1. Read the starter problem and write the first step of an algorithm in their own words.
2. Write a full sequential algorithm for calculating an average.
3. Add a selection branch and an iteration loop to the same algorithm.
4. Trace each version step by step and compare them.
5. State why an algorithm must be precise about inputs and outputs.
6. Answer the exit question in one sentence about algorithm precision.

Practical / learning evidence

Three worked algorithms on paper, one sequential, one with selection and one with iteration, each showing the result clearly. Hand in all three for marking.

Resources and preparation

Blank algorithm worksheets, sample number lists and numbered step cards. Offline route: paper worksheets, no device needed. Display any worked examples carefully and never let learners modify them before tracing.

Assessment for learning

Inspect each algorithm for correct steps and termination. Mark the traces for matching the stated inputs and outputs. Flag any learner who leaves an algorithm unfinished mid-way.

Inclusion and homework

Provide the sequential template prefilled for learners who need scaffolding and allow oral completion of the selection and iteration additions. Extend confident learners with four problems and a problem-versus-solution distinction homework.

Lesson objectives

By the end of the week, learners should be able to:

1. Name the main flowchart symbols and state the role of each.
2. Draw a simple flowchart containing a start, process, decision and end.
3. Follow the flowchart by tracing both paths through a decision.
4. Explain why flowcharts help humans design algorithms.
5. Identify which step in a flowchart represents branching logic.

Key vocabulary

• Flowchart: a diagram showing algorithm steps symbol by symbol.
• Start symbol: the oval at the beginning of a flowchart.
• Process symbol: the rectangle describing a step or action.
• Decision symbol: the diamond asking whether to continue.
• End symbol: the oval marking termination.
• Branch: one of two paths taken by a decision.
• Path: the route through a flowchart following a single choice.
• Trace: predicting results by walking through a diagram.

Common misconceptions

• "Every flowchart needs a decision." Simple linear tasks use only start, process and end.
• "Flowcharts replace algorithms." Flowcharts visualise algorithms but do not execute them.
• "Tracing follows only one path." Tracing follows whichever path a decision sends you.

Teacher activities

1. Starter: display two algorithms side by side, one text and one drawn; ask which a developer would prefer reviewing.
2. Name the four main flowchart symbols and demonstrate each with a labelled diagram.
3. Model drawing a simple flowchart with start, process, decision and end.
4. Demonstrate tracing both paths through a decision by hand.
5. Give learners a small flowchart and ask them to trace it.
6. Close with the exit question about flowchart value for human review.

Student activities

1. Choose the developer-preferred version from the starter and explain the reason.
2. Name the four main flowchart symbols in their own words.
3. Label a blank start, process, decision and end diagram.
4. Draw a simple flowchart for a basic calculator step.
5. Trace both paths through a decision in the given flowchart.
6. Answer the exit question in one sentence about why flowcharts help humans.

Practical / learning evidence

A labelled start-process-decision-end diagram, a drawn simple flowchart and a traced diagram with both paths recorded. Hand in all three for marking.

Resources and preparation

Blank flowchart templates, symbol name cards and sample algorithms. Offline route: paper templates and cards, no device needed. Supervise any physical component demo carefully.

Assessment for learning

Inspect the labelled diagram for all four symbols correctly placed. Check the drawn flowchart for sensible sequencing. Mark the traced diagram for both paths followed. Flag any learner who claims every flowchart needs a decision.

Inclusion and homework

Provide the blank template prelabelled for learners who need scaffolding and allow oral tracing. Extend confident learners with a flowchart containing three decisions and two branches. Homework: convert one sequential algorithm into a flowchart.

Lesson objectives

By the end of the week, learners should be able to:

1. Define pseudocode as an informal notation close to programming.
2. Distinguish the pseudocode keywords such as IF THEN ELSE.
3. Translate a simple verbal instruction into pseudocode.
4. Describe why pseudocode helps bridge human thought and code.
5. Explain the difference between pseudocode and code execution.

Key vocabulary

• Pseudocode: an informal notation closer to human speech than machine code.
• Notation: the symbols and keywords used in a language style.
• Keyword: a reserved word such as IF or ELSE in pseudocode.
• Bridge: the link between human thought and executable code.
• Verbal instruction: a spoken or written description of what to do.
• Informal notation: pseudocode looks like speech but reads like structured code.
• Translation: converting a verbal idea into structured notation.

Common misconceptions

• "Pseudocode is real code." Pseudocode executes in thought only, not on a computer directly.
• "Every keyword matters like real code." Pseudocode uses familiar keywords for clarity.
• "Pseudocode replaces a flowchart." Pseudocode often follows the flowchart structure.

Teacher activities

1. Starter: read a short verbal instruction aloud and ask learners to translate it into flowchart symbols.
2. Define pseudocode and name the most common pseudocode keywords.
3. Translate a verbal instruction step by step with IF THEN ELSE and a LOOP.
4. Show how pseudocode mirrors a flowchart visually.
5. Explain the bridge role in helping humans think in code.
6. Close with the translation task and exit question about execution.

Student activities

1. Listen to the starter and translate the verbal instruction into symbols.
2. Define pseudocode in their own words and list three common keywords.
3. Translate a verbal instruction into pseudocode using IF THEN ELSE.
4. Describe how pseudocode mirrors a flowchart visually.
5. Explain why pseudocode helps bridge human thought and code.
6. Answer the exit question in one sentence about execution.

Practical / learning evidence

Two translated pseudocode snippets compared against their source verbal instructions, plus a one-paragraph definition statement. Hand in both the snippets and the definition for marking.

Resources and preparation

Blank pseudocode templates, keyword cards and sample verbal instructions. Offline route: paper templates and cards, no device needed. Keep examples clean and avoid pseudocode that looks too much like real programming syntax.

Assessment for learning

Inspect the translated snippets for correct keyword usage. Compare each snippet with its source instruction for faithful translation. Ask a learner to explain the bridge role in their own words. Flag any learner who calls pseudocode executable code.

Inclusion and homework

Provide keyword cards preprinted for learners who need scaffolding and allow oral completion. Extend confident learners with three snippets and a bridge explanation homework. Homework: rewrite one verbal instruction without pseudocode keywords.

Lesson objectives

By the end of the week, learners should be able to:

1. Define high-level and low-level languages.
2. Name at least four languages grouped by level.
3. Explain why high-level languages are preferred in schools.
4. Compare assembly and machine code on closeness to hardware.
5. State one advantage and one disadvantage of each language type.

Key vocabulary

• High-level language: closer to human speech than machine code.
• Low-level language: very close to hardware instructions.
• Assembly: a low-level language mapping closely to machine code.
• Machine code: binary instructions executed directly by hardware.
• Prefer: choose a tool because of specific advantages.
• Advantage: a benefit offered by a particular approach.
• Disadvantage: a drawback of a particular approach.
• Closeness to hardware: how little abstraction separates the language from the processor.

Common misconceptions

• "All programming languages are equally suitable." High-level languages suit school work better than assembly.
• "Machine code is dead technology." Machine code still runs modern processors directly.
• "High-level always beats low-level everywhere." Low-level languages offer fine performance control that high-level cannot match.

Teacher activities

1. Starter: hold up a printed assembly listing and a high-level program and ask which students find easier to read.
2. Define high-level versus low-level languages and compare them.
3. Name four or more language families and give one example each.
4. Explain why high-level languages suit school teaching.
5. Give learners a high-level versus assembly comparison prompt.
6. Close with the exit question about when low-level programming is justified.

Student activities

1. Pick the easier-to-read language from the starter and explain the reason.
2. Define high-level and low-level languages in their own words.
3. Name four or more languages and give one example each.
4. Explain why high-level languages suit school teaching in one paragraph.
5. Compare assembly and machine code on closeness to hardware.
6. State one advantage and one disadvantage of each language type.

Practical / learning evidence

A high-level versus low-level comparison table with advantages and disadvantages for each, plus a one-paragraph justification statement. Hand in both for marking.

Resources and preparation

Printed comparison templates, blank tables and sample languages. Offline route: paper tables, no device needed. Display language families clearly and do not recommend commercial software without context.

Assessment for learning

Inspect the comparison table for at least two advantages and two disadvantages per type. Mark the justification for a sensible reason tied to school teaching. Flag any learner who claims all languages are equally useful.

Inclusion and homework

Provide the table prefilled with advantage labels and allow oral completion of disadvantages. Extend confident learners with five language families. Homework: name one real application written in assembly and one in a high-level language.

Lesson objectives

By the end of the week, learners should be able to:

1. Name three translator types: interpreter, compiler and hybrid.
2. Explain why an interpreter reports errors line by line.
3. State why a compiler produces a single executable file.
4. Describe hybrid translators combining compiler and interpreter strengths.
5. Match translator types to their characteristics.

Key vocabulary

• Translator: a programme converting one language into another.
• Interpreter: converts line by line and executes immediately.
• Compiler: converts the whole program into executable code at once.
• Hybrid translator: combines interpreter and compiler approaches.
• Line-by-line: processing one command at a time during execution.
• Executable file: a file ready to run without further translation.
• Characteristic: an attribute describing a translator.

Common misconceptions

• "Every translator behaves the same." Interpreters and compilers differ fundamentally in error reporting.
• "An interpreter cannot handle errors." An interpreter reports errors as it runs line by line.
• "Compilers run slower than interpreters." Compilers run faster after the one-time translation cost.

Teacher activities

1. Starter: run a broken interpreter program and show where the error appears; then show the same broken program through a compiler.
2. Name the three translator types and demonstrate the difference on a live system.
3. Explain why an interpreter reports errors line by line rather than batch.
4. Explain why a compiler produces a single executable file.
5. Introduce hybrid translators and compare them with pure interpreter and pure compiler.
6. Close with the characteristic-matching task and exit question.

Student activities

1. Observe the starter and explain how the interpreter found the error quickly.
2. Name the three translator types in their own words.
3. Explain why an interpreter reports errors line by line in one paragraph.
4. State why a compiler produces a single executable file in one sentence.
5. Describe hybrid translators in one sentence.
6. Match the three translators to their characteristic descriptions.

Practical / learning evidence

A three-translator chart comparing characteristics, plus a translated program through an interpreter and through a compiler with expected outputs. Hand in both for marking.

Resources and preparation

Computers with a BASIC interpreter and a compiler installed, blank windows and sample broken programs. Disable Caps Lock before typing. Preload both translators in read-only folders for learners lacking installation.

Assessment for learning

Inspect the characteristic chart for three distinct descriptions. Compare the interpreter and compiler outputs for matching behaviour. Ask a learner to describe the hybrid approach. Flag any learner who claims translators behave identically.

Inclusion and homework

Provide the chart prefilled for learners who need scaffolding and allow oral matching. Extend confident learners with four translators and a second hybrid example. Homework: name one advantage and one disadvantage of interpreting versus compiling.

Lesson objectives

By the end of the week, learners should be able to:

1. Plan a simple program using pseudocode or a flowchart.
2. Write a BASIC program with LET, PRINT, INPUT and IF THEN.
3. Debug the program if errors appear and confirm the output.
4. Save the runnable program under a clear filename.
5. Compare the planned pseudocode with the final program.

Key vocabulary

• Plan: the pseudocode or flowchart outline before coding.
• Pseudocode: informal notation guiding code creation.
• Flowchart: a diagram visualising the plan.
• Runnable program: code that executes without fatal errors.
• Debug: finding and fixing mistakes in a program.
• Confirm: verifying output matches expectations.
• Filename: the name identifying a saved file.
• Comparison: checking a plan against the final code.

Common misconceptions

• "The plan must exactly match the final code." Plans guide structure but wording can change.
• "A working program does not need debugging." Working programs are products of debugging.
• ""The plan is optional fluff."" A plan keeps development focused and readable.

Teacher activities

1. Starter: display a pseudocode plan and a final program and ask which differs most.
2. Explain the planning requirement and model pseudocode planning on paper.
3. Demonstrate writing a BASIC program from the plan.
4. Model debugging one broken program and confirm the corrected output.
5. Save the final program and reopen it to confirm.
6. Set the creation task and collect materials for submission.

Student activities

1. Choose the plan from the starter and explain how the program changed.
2. Plan a small program on paper using pseudocode or a flowchart.
3. Write a BASIC program using LET, PRINT, INPUT and IF THEN.
4. Debug the program if errors appear and confirm the corrected output.
5. Save the final program under a clear filename and reopen to confirm.
6. Compare the planned pseudocode with the final program.

Practical / learning evidence

A completed plan, a saved runnable BASIC program and a confirmed expected output, plus the comparison between plan and program. Hand in all three for marking.

Resources and preparation

Computers with the BASIC interpreter, blank templates, sample plans and a broken-program sample. Prebuild the interpreter in a read-only folder. Disable Caps Lock before typing. Confirm the computer starts reliably.

Assessment for learning

Inspect the plan for sensible structure. Check the saved program for correct LET, PRINT, INPUT and IF THEN syntax. Compare the plan with the program for meaningful alignment. Flag any learner who ignores the plan requirement.

Inclusion and access

Provide the sample plan prebuilt so learners focus on the program itself. Allow extra time for debugging. Extend confident learners with two programs and a second plan comparison homework. Homework: turn one planned program into two variants differing only in operators.

Lesson objectives

By the end of the week, learners should be able to:

1. Recall the full term's key terms without notes in ten minutes.
2. Test objective knowledge with a short recall quiz.
3. Practise flowchart, pseudocode and program skills under timed conditions.
4. Prepare three practical stations ready for the examination week.
5. Organise their materials for examinations.

Key vocabulary

• Full summary: a one-page recap of the entire term's vocabulary.
• Recall quiz: a short test of definitions and concepts from memory.
• Timed conditions: a restricted time allowance for practice.
• Practical station: a setup point for examination practical tasks.
• Materials organisation: keeping tools ready before an examination.

Common misconceptions

• "Revision is just reading notes again." Revision means testing and practising, not passive reading.
• "Tomorrow is the exam so today is fine." A full day before leaves almost no preparation time.
• "Better to be relaxed than busy preparing." Preparation reduces anxiety and improves performance.

Teacher activities

1. Starter: ten rapid-fire recall questions from the full term, no notes allowed.
2. Run a timed objective quiz and mark it as a class, explaining distractors.
3. Demonstrate the three practical stations and remind learners of the materials checklist.
4. Walk through a morning materials organisation checklist.
5. Confirm that every learner can reach the exam room and has stationery.
6. Close with a brief announcement of the Third Term starting Monday.

Student activities

1. Answer the ten recall questions and note any slips.
2. Mark their own quiz answers and record scores for review.
3. Prepare the three practical stations and run through the materials checklist.
4. Practise flowchart, pseudocode and program tasks for ten minutes each.
5. Pack stationery, identification and any permitted materials for examination day.
6. Write one sentence on what revision helped you feel ready for Monday.

Practical / learning evidence

A scored objective quiz, a completed revision grid covering all terms and an materials-organisation checklist signed by the learner. All three handed to the teacher for marking.

Resources and preparation

Quiz sheet, revision grid and materials checklist. Confirm the examination room, three machines and one invigilator per station are booked before the week.

Assessment for learning

Use the quiz scores to plan the Third-Term reteach if class averages are below target. Check the revision grid for completeness. Verify the materials checklist is signed and ready for examination day.

Inclusion and access

Provide the quiz in large print and allow extra time where approved. Pair learners for the practical rehearsal so a confident partner can model the steps. Homework: pack everything needed for the examination week and store it safely.

Lesson objectives

By the end of the examination week, learners should be able to:

1. Demonstrate recall of the term's concepts under examination conditions.
2. Apply knowledge to unfamiliar examples in objective and short-answer questions.
3. Complete a practical task within the time allowance using correct procedure.
4. Name, save and submit files correctly.
5. Explain their practical output when questioned by the examiner.

Examination design

For Senior Secondary 1 the totals are: Section A objective 20 marks, Section B short answer 30 marks, Section C essay 10 marks, Section D practical 20 marks, total 80. Section A samples recall and terminology. Section B samples explanation, comparison and classification. Section D samples practical program and flowchart skills.

Section	Format	Marks
A	Objective (20 four-option items)	20
B	Short answer (definitions / diagrams / classification / conversions)	30
C	Essay (definition / comparison / application)	10
D	Practical (programming / flowchart construction)	20
Total	80

Teacher activities

1. Confirm the approved timetable, venue, seating and invigilation before the week begins.
2. Brief learners on the paper structure, the time for each section and the materials allowed.
3. Set out three practical stations: programming, flowchart construction and OS interaction, with one invigilator per station where possible.
4. Prepare offline equivalents for learners without device access: printed sketchbook, paper program tracing task and OS scenario card.
5. Mark using the agreed scheme, moderate a sample of scripts and record scores.
6. Return scripts with feedback and hand over to Third Term.

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 Third Term.

Practical / learning evidence

The completed examination script, the saved practical file for each candidate and the practical rubric sheets. Retain scripts, marking guides 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 Writer, a BASIC interpreter and a graphics package and stopwatch, printed sketchbooks and scenario 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 D against the practical rubric: task interpretation, procedure, technical accuracy, program structure, file naming and saving, organisation and explanation. Moderate a sample of scripts across all sections, and flag any question where more than a third of learners scored zero for review of the teaching rather than the learners.

Inclusion and access

Provide extra time and large-print papers where approved, seat learners with visual or hearing needs appropriately, and allow the offline equivalent for any learner without device access so that no candidate loses practical marks because of equipment. Keep the practical criteria identical across the digital and paper routes.

After the examination

Record scores against the class list, return scripts with brief feedback, and hand over to Third Term: communication systems, internet benefits and abuse, computer ethics and viruses, applications of ICT, word processing advanced, World Wide Web and web browsers, revision and project work. Note any topic where the class average fell below the school's threshold and schedule it as a Third-Term retrieval starter.