THINK IN CODE.
& BUILD REAL SOLUTIONS.
Apply Python programming and computational thinking to real-world problems - design algorithms, analyse data, build programs, and explore cybersecurity and ethics. Two WACE modules, a full year, zero prior experience required.
Python fundamentals, algorithm design, data representation, and computing impacts. Four tasks across Semester 1.
Functions, data structures, applied algorithms, cybersecurity, and computing ethics. Four tasks across Semester 2.
| Task | Type | Title | Weight | Marks | Due |
|---|---|---|---|---|---|
| T1 | 📁 PROJECT | Python Foundations & File Handling | 15% | /40 | T1 W9 |
| T2 | 📝 SHORT ANSWER | Algorithms & Data Representation | 10% | /30 | T2 W3 |
| T3 | 📁 PROJECT | Problem Solving Program | 20% | /50 | T2 W7 |
| T4 | 🖊 EXTENDED ANSWER | Impacts of Computing in Society | 5% | /25 | T2 W8 ▲ |
| T5 | 📁 PROJECT | Data Analysis with Python | 15% | /40 | T3 W9 |
| T6 | 📝 SHORT ANSWER | Cybersecurity & Digital Systems | 10% | /30 | T4 W3 |
| T7 | 📁 PROJECT | Capstone Program | 20% | /60 | T4 W7 |
| T8 | 🖊 EXTENDED ANSWER | Ethics in Computing | 5% | /25 | T4 W8 ▲ |
| Grade | Percentage | Standard |
|---|---|---|
A |
80-100% | Exceeds standard - comprehensive, accurate, and well-presented work demonstrating thorough understanding of all content areas. |
B |
60-79% | Above standard - mostly correct and complete, demonstrating solid understanding with minor gaps or errors. |
C |
50-59% | At standard - meets the core requirements; some errors or incomplete elements but demonstrates foundational understanding. |
D |
30-49% | Below standard - partially meets requirements; significant gaps in understanding or incomplete work across key areas. |
E |
0-29% | Well below standard - does not meet requirements; most key elements missing or incorrect. Student support recommended. |
Write Python programs demonstrating core programming foundations: variables, data types, input/output, conditional statements, loops, and functions with return values. The final deliverable is a high-score file-handling program and a written reflection on coding challenges and solutions.
- A Python program using variables, data types, input(), and print()
- Selection and iteration - if/elif/else, for loops, while loops
- At least two functions with parameters and return values
- A file-handling feature - read/write a high-score or results file using open()
- A written reflection (5-8 sentences) on debugging challenges and solutions
- Code runs without errors in Replit or IDLE
- Program includes meaningful comments explaining key sections
- All functions have docstrings describing their purpose
- File handling reads AND writes - not just one direction
- File named using convention:
Smith_J_T1_main.py - Submitted via Connect with reflection before the due date
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Python Foundations /15 marks | Program uses variables, data types, input/output, conditionals, and loops correctly; all constructs work as intended with no errors; code is logical and well-structured. | Core Python constructs used correctly with minor logic issues or edge-case errors; overall program functions well. | Most constructs present but some produce incorrect output or contain logic errors; program partially functional. | Limited use of required constructs; program runs but produces incorrect or incomplete results. | Program does not run or contains fundamental Python errors throughout. |
| File Handling /15 marks | File read and write implemented correctly using open(); data persists between runs; error handling present (e.g. file not found); file handling integrates logically with program flow. | File read and write working correctly with minor integration issues; data persists between runs. | File handling attempted and partially working; either read or write missing or errors occur in some scenarios. | File handling code present but does not function correctly; data does not persist reliably. | No file handling implemented or file handling code is fundamentally broken. |
| Code Quality /6 marks | All functions have docstrings; meaningful comments throughout; consistent indentation; descriptive variable names; code follows Python style conventions. | Functions and most sections commented; style mostly consistent with minor lapses. | Some comments present; variable names mostly meaningful; style inconsistencies present but code is readable. | Minimal comments; some variable names cryptic; style inconsistencies make code difficult to follow. | No comments; cryptic variable names; code is difficult to read or follow. |
| Reflection /4 marks | Reflection clearly identifies at least two specific debugging challenges; explains solutions with correct programming terminology; connects experience to future improvement. | Reflection describes challenges and solutions adequately with some use of terminology. | Reflection present but vague; challenges described without specific detail or terminology. | Reflection very brief; minimal evidence of critical thinking about the coding process. | Reflection not submitted or does not address the task requirements. |
By the end of this lesson you can write a Python program that uses print(), a variable, and gets input from the user.
- Go to replit.com and sign in (or create a free account). Create a new Repl and choose Python. Name it
T1_Python_Foundations. - In main.py, type:
print("Hello, World!")then click Run. You should see the message appear in the console. This confirms Python is working. - Variables: type
name = "Alex"thenprint(name). Run it. A variable stores a value. The name on the left is the label; the value on the right is what it holds. - Data types: try four types in your program. String:
greeting = "Hello". Integer:age = 16. Float:score = 9.5. Boolean:is_logged_in = True. Print each one. - Input: type
user_name = input("What is your name? ")thenprint("Nice to meet you, " + user_name + "!"). Run it. Type your name when prompted. - Add a comment above each section using
# this is a comment. Comments explain your code for the reader. Add at least three comments before the end of the lesson.
print(type(age))
By the end of this lesson you can write an if/elif/else statement that responds differently based on user input.
- Open your T1 Replit. Comparison operators:
==equal to,!=not equal,>greater than,<less than,>=and<=. These return True or False. - Write a basic if statement:
score = int(input("Enter your score: "))
if score >= 50:
print("Pass")
else:
print("Not yet") - Extend to if/elif/else with three or more branches. Add grades: A (80+), B (60-79), C (50-59), Below (under 50). Test with different inputs.
- Indentation: Python uses 4 spaces (or 1 tab) to define code blocks. Every line inside an if/elif/else must be indented. Missing indentation is one of the most common Python errors.
- Build a mini password checker: ask the user to enter a password. If it equals a stored password, print "Access granted". Otherwise, print "Access denied". This models real selection logic.
By the end of this lesson you can write both a for loop and a while loop to repeat a block of code.
- For loop with range:
for i in range(5): print(i)- prints 0 to 4. Try range(1, 6) - prints 1 to 5. Try range(0, 20, 2) - prints even numbers. - For loop over a list:
scores = [85, 72, 91, 60]
for score in scores:
print(score) - While loop:
count = 0. Important: without
while count < 5:
print(count)
count += 1count += 1this runs forever (infinite loop). Always make sure your while condition can become False. - Input validation loop: keep asking the user for a number between 1 and 10 until they enter a valid one. Use a while loop with the condition
while num < 1 or num > 10: - Add a # comment above each loop explaining what it does and why you chose for vs while.
By the end of this lesson you can define and call a function with parameters that returns a calculated value.
- A function is a named block of reusable code. Define with
def:def greet(name):
return "Hello, " + name + "!"
Call it:print(greet("Alex")) - Parameters are the inputs to a function. Return sends a value back to the caller. A function without return gives back None.
- Write a function
calculate_grade(score)that returns "A", "B", "C", or "Below" based on the score. Call it with at least 3 different values. - Docstrings: the first line inside a function should be a triple-quoted description:
def greet(name):
"""Returns a greeting string for the given name."""
return "Hello, " + name - Write a second function
get_average(scores)that takes a list and returns the average. Test it with your list from L3.
By the end of this lesson you have designed your T1 program structure and built a working menu loop that stores scores in a list.
- Program design: your T1 program is a high-score tracker. Plan it first. Write in a comment block at the top: what it does, what inputs it needs, what it outputs, and which functions you will need.
- Create a new Python file
Smith_J_T1_main.py. Start with a list to store scores:scores = [] - Build a menu with a while loop:
while True:
print("1. Add score 2. View scores 3. Quit")
choice = input("Choose: ")
if choice == "1":
pass # we'll add this next
elif choice == "3":
break - Add score option: prompt for player name and score, validate the score is a number between 0 and 100 (use try/except or if/else), then append to scores list as a tuple:
scores.append((name, score)) - View scores: loop over the list and print each entry clearly. Use an f-string:
print(f"{name}: {score}")
By the end of this lesson you can write a Python program that saves data to a file and reads it back correctly.
- Writing to a file:
with open("scores.txt", "w") as f:. The "w" mode creates or overwrites. The "a" mode appends.
f.write("Alex,95 ")
f.write("Sam,82 ") - Reading from a file:
with open("scores.txt", "r") as f:. The with statement automatically closes the file when done.
for line in f:
print(line.strip()) - The
at the end of each write adds a newline. strip() removes whitespace and newline characters when reading. - Integrate into your T1 program: add a
save_scores(scores)function that writes all scores to a file, and aload_scores()function that reads them back. Call load_scores() at program start so scores persist between runs. - Test: add some scores, quit the program, run it again - the scores should still be there. This is the key requirement for the T1 rubric’s File Handling criterion.
By the end of this lesson you can use try/except to handle input errors so your program doesn’t crash when users enter unexpected data.
- Problem: if a user types "abc" when you call int(input(...)), Python raises a ValueError and crashes. Try it:
score = int(input("Enter score: "))- type "hello" and watch it crash. - Solution - try/except:
try:
score = int(input("Enter score: "))
except ValueError:
print("Please enter a number.")
score = 0 - Wrap the score entry in your T1 program with try/except. Also add a while loop so it keeps asking until valid input is received.
- Add file error handling: wrap your load_scores() in try/except FileNotFoundError so the program handles the case where the file doesn’t exist yet (first run).
- Add comments explaining what each try/except block protects against and why it’s needed.
By the end of this lesson your T1 program displays statistics (highest score, lowest score, average) and saves results to a file.
- Extract numeric scores from your list of tuples for statistics:
nums = [s[1] for s in scores] - Write a function
show_stats(scores)with docstring that prints: highest score (with name), lowest score (with name), and average. Use max(), min(), sum(), len(). - Add "Show stats" to your menu (option 3) and "Save and Quit" as option 4. Calling save_scores() before quitting is the key requirement.
- Test your complete program: add 5+ scores, view them, check stats, save and quit. Rerun - confirm scores reload correctly.
- Code quality check: every function has a docstring, every section has a comment. Variable names are meaningful (not x, y, a, b).
By the end of this lesson you have tested your program with at least 5 test cases and completed a peer code review.
- Create a test table (can be in a comment block or separate doc): list each test case, the input, the expected output, and the actual output. Test: valid score, invalid text input, score = 0, score = 100, empty file on load.
- Debugging: if something doesn’t work, add
print()statements to see what values variables hold at each step. This is called print debugging - a valid and widely-used technique. - Peer review: swap Replit links with a classmate. Read their code. Write 3 comments: (1) something that works well, (2) something unclear or that could be improved, (3) one specific suggestion. Share feedback in writing.
- Fix any bugs your peer found or that testing revealed. Keep a note of what you fixed - this feeds directly into your reflection.
By the end of this lesson you have completed the written reflection and your T1 code is submission-ready.
- Reflection (5-8 sentences): describe at least two specific debugging challenges and how you solved them. Use programming terminology (e.g. ValueError, indentation, scope, loop condition). Explain what you would do differently next time.
- Final code review: check every function has a docstring. Check every major section has a comment. Check all variable names are meaningful. Check your file is named correctly:
Smith_J_T1_main.py. - Check the rubric: Python Foundations /15 (variables, data types, input/output, conditionals, loops all present and correct), File Handling /15 (reads and writes, data persists), Code Quality /6 (comments, docstrings, naming), Reflection /4 (specific, uses terminology).
- Submit: upload your .py file and reflection document to Connect before the due date.
By the end of this lesson Task 1 is submitted to Connect and you understand what Task 2 involves.
- Download your main.py from Replit (three dots menu → Download). Verify the filename:
Smith_J_T1_main.py - Submit to Connect: go to your class page, find Task 1 assignment, upload both your .py file and your reflection document.
- Your teacher introduces Task 2: Algorithms & Data Representation. This is an in-class short answer test scheduled for Term 2 Weeks 1-3. Content: flowcharts, pseudocode, trace tables, binary numbers, data types. Begin noting down any terms you’re unsure of.
By the end of this lesson Task 1 is submitted and you have begun previewing Task 2 algorithm content.
- If Task 1 is not yet submitted: use this lesson to complete and submit. No further extensions after this lesson.
- Algorithm intro: an algorithm is a precise step-by-step set of instructions to solve a problem. Your Python programs ARE algorithms. The difference is that algorithms can be written in pseudocode or drawn as flowcharts - language-independent.
- Flowchart symbols: draw in your notes - oval (start/end), rectangle (process), diamond (decision/branch), parallelogram (input/output), arrows (flow). We’ll use these next term in Task 2.
- Begin answering from memory: "What are three things a variable must have?" (name, data type, value). Practise using correct terminology - Task 2 tests this.
In-class theory test on Socrative covering algorithm design (flowcharts, pseudocode, trace tables), binary number representation, data types, and problem-solving strategies. Lessons build from content through worked examples and practice. Lesson 11 is the formal Socrative assessment. Lesson 12 is return and review. No AI in L11.
- Completed Socrative quiz (in-class, on your device - L11)
- Algorithm notes - flowcharts, pseudocode, and trace tables from L1-10
- Practice test completed and self-marked (L9)
- Binary conversion reference sheet completed during lessons
- Test completed individually on Socrative - no notes, no internet, no AI
- Log in at b.socrative.com/student-v2/join using the Room Name given by your teacher
- All answers in full sentences unless otherwise instructed
- Test returned and reviewed in L12 - corrections submitted to teacher
- Content areas: flowcharts, pseudocode, binary, data types, problem-solving
- 1Open the link above (or the Socrative Student app on your device)
- 2Enter the Room Name your teacher gives you
- 3Type your First Name and Last Name when prompted
- 4Wait for your teacher to launch - do not click ahead
- 5Answer each question, then click Submit when done
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Algorithm Knowledge /12 marks | Accurately draws flowcharts and writes pseudocode; trace tables completed correctly; algorithm steps logical and unambiguous; correct symbols used throughout. | Flowcharts and pseudocode mostly correct; trace table mostly accurate; minor symbol or logic errors. | Algorithms generally correct with some missing steps or incorrect symbols; trace table partially complete. | Algorithms attempted but with significant logic errors or missing sections; trace table largely incorrect. | Minimal understanding of algorithm design demonstrated; flowcharts or pseudocode absent or fundamentally incorrect. |
| Data Representation /12 marks | Binary conversions accurate (denary↔binary); data types correctly identified and explained (integer, float, string, boolean); clear explanation of how data is stored. | Binary conversions mostly accurate; data types mostly correctly identified with minor errors. | Binary conversions partially correct; most common data types identified; some confusion evident. | Binary conversions largely incorrect; limited understanding of data types. | Minimal understanding of binary or data types demonstrated. |
| Communication /6 marks | Responses use correct CS terminology throughout; answers are clear, well-structured, and consistently address the question asked. | Terminology mostly correct; most answers clear and well-structured. | Some terminology used correctly; responses generally understandable. | Limited use of correct terminology; some responses unclear or incomplete. | Responses difficult to understand; terminology largely absent or incorrect. |
By the end of this lesson you can draw a correct flowchart for a simple algorithm using proper symbols.
- Flowchart symbols: draw and label each in your notes. Oval = start/end (terminator). Rectangle = process (action/calculation). Diamond = decision (yes/no question). Parallelogram = input/output. Arrows = flow direction. These are standard across all computing courses.
- Draw a flowchart for: "Ask user for a number. If number is greater than 0, print POSITIVE. If less than 0, print NEGATIVE. If zero, print ZERO. End." This requires a diamond with three paths - use nested decisions.
- Rules: every diamond must have exactly two exits labelled YES and NO (or True/False). Every path must reach the terminator (end oval). Arrows must not cross unless you use a connector circle.
- Draw a second flowchart: a loop that asks the user for a password, and keeps asking until they enter the correct one, then prints "Welcome". This introduces the loop construct in flowcharts.
By the end of this lesson you can write pseudocode for a simple algorithm using standard conventions.
- Pseudocode conventions: keywords in CAPITALS. INPUT variable. OUTPUT value. IF condition THEN ... ELSE ... ENDIF. WHILE condition DO ... ENDWHILE. FOR i FROM 1 TO 10 DO ... ENDFOR.
- Convert your flowchart from L1 (positive/negative/zero) to pseudocode. Compare - the logic must be identical.
- Write pseudocode for a grade calculator: INPUT a score, OUTPUT the grade letter (A/B/C/D). Use IF/ELIF/ELSE structure.
- Write pseudocode for a loop that reads 5 numbers and outputs their sum. Use a FOR loop and a running total variable.
- Key difference: pseudocode is language-independent. It shows the logic without Python/Java/C syntax. Use it in your exam answers - it’s what markers expect.
By the end of this lesson you can complete a trace table for a given algorithm by tracking variable values step by step.
- A trace table tracks the value of each variable at each step of an algorithm. Columns = variable names. Rows = each step/iteration. Fill in each cell as you mentally execute the code.
- Trace this algorithm with input 5:
x = INPUT
total = 0
FOR i FROM 1 TO x:
total = total + i
OUTPUT total
Create a table with columns: i, total, and fill in each row. - Trace a loop with a condition: x = 10, WHILE x > 0: x = x - 3, OUTPUT x. Trace until loop ends. What is the final value of x?
- Trace tables are your exam technique for algorithm questions. Practice on 3 different algorithms your teacher provides.
By the end of this lesson you can convert between binary and denary (decimal) numbers up to 8 bits.
- Binary is base-2: only 0s and 1s. Each position represents a power of 2. 8-bit positions (right to left): 128, 64, 32, 16, 8, 4, 2, 1. Draw this header row in your notes.
- Denary to binary: convert 45 to binary. 45 ÷ 2 = 22 r1, 22 ÷ 2 = 11 r0, 11 ÷ 2 = 5 r1, 5 ÷ 2 = 2 r1, 2 ÷ 2 = 1 r0, 1 ÷ 2 = 0 r1. Read remainders bottom to top: 101101. Pad to 8 bits: 00101101.
- Binary to denary: convert 10110101. Multiply each bit by its position value and add: 128+0+32+16+0+4+0+1 = 181.
- Bits and bytes: 1 bit = one binary digit. 8 bits = 1 byte. 1024 bytes = 1 kilobyte. Why binary? Computers use electrical signals that are either ON (1) or OFF (0) - two states are easiest to represent physically.
- Practise: convert 10 values denary to binary and 10 binary to denary. Use the 8-column header as your working tool.
By the end of this lesson you can identify the correct data type for a given piece of data and explain how it is stored.
- Data types table in your notes: Integer (whole numbers, stored as binary), Float (decimal numbers, uses floating-point representation), String (text, each character stored using ASCII/Unicode), Boolean (True/False, stored as 1 or 0), Character (single symbol, stored using ASCII code).
- ASCII: every character has a number. A=65, a=97, 0=48. The number 65 in binary is 01000001. So the letter "A" is stored as 01000001. Use an ASCII table (provided by teacher) to look up 5 characters.
- For each piece of data below, write the correct data type: age (int), price (float), first name (string), is_logged_in (bool), postcode like "6231" (string - not int because it may have leading zeros), phone number (string).
- Why does it matter? Using the wrong type causes bugs. If you store a price as int you lose the cents. If you store a postcode as int, 0231 becomes 231.
By the end of this lesson you can describe three computational problem-solving strategies and apply them to a given problem.
- Decomposition: break a complex problem into smaller sub-problems. Example: "build a quiz" → get question, display question, get answer, check answer, update score, show result. Each part is a function.
- Pattern recognition: identify similarities between problems or within a problem. Example: if you’ve solved a grade calculator, a tax calculator uses the same if/elif structure - recognise and reuse the pattern.
- Abstraction: hide unnecessary detail, focus on essentials. A function is abstraction - you call get_average() without knowing how it works internally. The user interface is abstracted from the file handling.
- Algorithm efficiency basics: a loop that runs once per item is fine for small lists. If you have two nested loops (loop inside a loop) for a large list, it slows significantly. At General level, note this awareness without formal complexity analysis.
- Apply all three to this problem: "Build a program that reads a list of student names and scores from a file, finds the top 3 scorers, and writes them to a separate file." Decompose, identify patterns, identify what to abstract.
By the end of this lesson you have completed mixed practice questions covering all T2 content areas.
- Worked examples: your teacher walks through 2-3 exam-style questions on the board - one flowchart, one trace table, one binary conversion. Copy the method, not just the answer.
- Timed practice: complete a set of 8 questions independently (10 minutes). Mark your own work. Note which areas need more revision.
- Binary relay: convert a series of numbers to binary and back. Focus on speed and accuracy - the test will have these questions.
- Create a revision cheat sheet (1 page, not for test use): all flowchart symbols, pseudocode keywords, binary position values, data type examples. This process of creating it is the revision.
By the end of this lesson you have identified your weakest areas and have a plan for what to review before the test.
- Class Kahoot: 20 questions covering all T2 content. Pay attention to which ones you get wrong - these are your revision targets.
- Common errors: forgetting to update the variable in a while loop (infinite loop), putting a terminator in the middle of a flowchart, confusing string "5" with integer 5 in data types, reading binary right-to-left (should be left-to-right for position values).
- Exam technique: read every question twice. For trace tables, work row by row - do not jump ahead. For pseudocode questions, write keywords in CAPITALS. Show your working for binary conversions (write out the position values).
- Partner quiz: test each other on definitions. Algorithm, flowchart, pseudocode, trace table, binary, bit, byte, integer, float, string, boolean. Each term in one sentence.
By the end of this lesson you have completed a full practice test and identified specific areas to revise before L11.
- Practice test (40 min, same format as L11 test): no notes, no devices. Covers flowcharts, pseudocode, trace table, binary conversion, data types, and problem-solving strategy. Work independently.
- Self-mark with the teacher’s marking guide. Add up your score. Identify which criterion you lost marks in.
- Targeted revision: spend 10 minutes specifically on your weakest area. If it was binary, do 10 more conversions. If it was trace tables, trace 2 more algorithms.
- Write a one-line revision plan for L10: "I need to practise _____ because _____."
By the end of this lesson you feel confident and prepared for the Task 2 test in the next lesson.
- Student-led: any student can request a topic to go over on the board. Teacher will answer up to 5 class questions.
- Targeted individual revision based on your plan from L9. Use the last 20 minutes to practise your specific weak area.
- Test conditions reminder: no notes, no devices, no AI. Complete the test on Socrative. Write in full sentences where answers require explanation. Label every diagram clearly.
- Rest and be ready for L11.
Complete the Task 2 short answer test to the best of your ability.
- Sit in your assigned seat with your device logged in to Socrative. Clear your desk of everything else.
- Read all questions before starting. Allocate time roughly proportional to marks.
- Show all working for binary conversions. Draw flowcharts with correct symbols. Write pseudocode using CAPITALS for keywords.
- If you finish early, review your answers. Check trace tables row by row.
By the end of this lesson you understand your test results and have been introduced to Task 3.
- Tests returned. Your teacher walks through the answers for each question. Write correct answers for any you got wrong - this is your corrections document to submit.
- Identify patterns in your errors: was it binary conversion, trace tables, or pseudocode conventions? Note what to focus on in Module 2 revision.
- T3 intro: Problem Solving Program. You will design and build a Python program solving a real-world problem of your choice. Options: quiz, calculator, simple game, or data validator. Starts next lesson. Begin thinking about your program idea.
Design and build a Python program that solves a real-world problem of your choice - a quiz, calculator, simple game, or data validator. The program must use functions, selection, and iteration. Students demonstrate a full design process: plan → code → test → evaluate. Peer code review is required.
- A working Python program solving a defined real-world problem
- A design document: problem statement, algorithm plan (pseudocode/flowchart)
- Test evidence: at least 5 test cases with expected vs actual results
- An evaluation: what works, what doesn't, what you'd improve
- Peer review: written feedback on a classmate's code
- Program uses at least two functions with parameters and return values
- Program uses both selection (if/elif/else) and iteration (for or while)
- Code is commented and readable
- Design document submitted alongside the program
- Submitted via Connect by due date
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Design Process /15 marks | Clear problem statement; pseudocode or flowchart fully maps the solution logic; design process evidence shows plan→code→test→evaluate cycle clearly executed. | Design process mostly complete; pseudocode/flowchart mostly maps the solution with minor gaps. | Design document present; plan partially maps solution; some gaps in test or evaluate phases. | Design document attempted but incomplete; limited evidence of planning before coding. | No design document or evidence of planning process. |
| Program Functionality /15 marks | Program runs without errors; solves the defined problem correctly; uses functions, selection, and iteration correctly; handles edge cases or invalid input. | Program runs and mostly solves the problem; minor logic errors or edge cases not handled. | Program partially functional; core logic present but some constructs missing or producing incorrect output. | Program runs but does not solve the problem correctly; significant logic or structural issues. | Program does not run or is fundamentally incomplete. |
| Code Quality /12 marks | Well-commented; descriptive variable and function names; consistent style; functions have docstrings; code is readable and follows Python conventions. | Code mostly commented and readable; minor style inconsistencies. | Some comments; variable names mostly meaningful; readable with some effort. | Minimal comments; cryptic naming; code difficult to follow. | No comments; code unreadable or poorly structured. |
| Peer Review /8 marks | Detailed, constructive peer review of a classmate's code; identifies specific issues with suggestions; own code shows evidence of acting on peer feedback received. | Useful peer feedback given; most key issues identified; some response to feedback received. | Peer review present but surface-level; feedback given and received noted. | Peer review very brief; limited engagement with classmate's code. | No peer review submitted or participated in. |
By the end of this lesson you have chosen your T3 program idea and completed a decomposition of the problem into sub-problems.
- Program options: Quiz (questions + scoring + high score file), Calculator (multi-operation with history file), Simple game (number guess/rock-paper-scissors with win tracker), Data Validator (checks formats, logs results). Any of these works. Your teacher must approve your choice by end of lesson.
- Decomposition: break your chosen program into 4-6 sub-problems. Each sub-problem becomes a function. Example for Quiz: get_question(), check_answer(), update_score(), show_results(), save_score(), load_scores().
- Create your T3 design document (Word doc or Google Doc): add a title, your name, the program name, a one-paragraph description, and your decomposition list.
- User story: write 3 "As a user, I want to..." statements. E.g. "As a user, I want to see my score at the end of the quiz." This defines what your program must do.
By the end of this lesson you have written pseudocode for your main program logic and drawn a flowchart for the most complex part.
- Pseudocode your main loop: what happens when the program starts? What choices does the user have? What repeats? Write it using standard pseudocode keywords (INPUT, OUTPUT, IF/ENDIF, WHILE/ENDWHILE, CALL function_name).
- Flowchart: draw the flowchart for the most complex function in your program (e.g. for a quiz: the question-and-answer loop). Use correct symbols.
- Add pseudocode and flowchart to your design document.
- Teacher check: show your design document to the teacher for sign-off before you start coding. This is required - no code before approved design.
By the end of this lesson you have a working program skeleton with all functions defined as stubs and a main menu loop running.
- Create your T3 file in Replit:
Smith_J_T3_program.py - Write stubs (empty functions) for every function in your decomposition. A stub has a docstring and returns a placeholder value:
def get_question():
"""Returns a question string."""
return "Placeholder" - Write a main() function that calls each stub in order. Run it - it should work without errors even with stubs.
- Implement the simplest function first (e.g. display menu, get choice). Test it works, then move to the next.
By the end of this lesson your core selection logic (if/elif/else) is implemented and working in at least two functions.
- Implement the functions that use selection (if/elif/else): e.g. check_answer(), calculate_grade(), validate_input(). Make sure each has a docstring.
- Test after implementing each function - don’t wait until everything is done to test. Small incremental testing catches bugs early.
- Add try/except for any user input that could cause a type error.
- Tick off each function from your decomposition list as you complete it.
By the end of this lesson your program has working loops for the main game/quiz/calculation cycle.
- Implement the main program loop: either a while True menu loop or a for loop over questions/rounds.
- Add input validation loops: if a user enters an invalid choice, keep asking until they enter a valid one.
- Run your program end-to-end. Does it do what your user stories described? If not, debug.
By the end of this lesson you have a completed test table with at least 5 test cases and have fixed the bugs found.
- Create a formal test table in your design document: columns = Test #, Input, Expected Output, Actual Output, Pass/Fail. Run at least 5 tests: normal case, edge case (0, empty, maximum), invalid input.
- For each FAIL: identify the bug, fix the code, re-test, and mark the outcome.
- Your test evidence is submitted alongside your program and is worth marks (Design Process criterion).
By the end of this lesson you have given and received written peer feedback and made at least one improvement to your program based on it.
- Swap Replit links with your assigned partner. Read their code for 10 minutes. Do not run it - just read it.
- Write feedback covering: (1) one thing that works well and why, (2) one thing that is unclear or could be improved, (3) one specific suggestion (e.g. "the function get_score() has no docstring - add one").
- Receive your partner’s feedback. Implement at least one suggestion. Note what you changed and why - this goes in your evaluation.
By the end of this lesson your T3 program is polished and submission-ready.
- Evaluation section of design doc: "What works well, what doesn’t, what would you improve with more time?" Write 5-8 sentences. Be specific.
- Final code quality check: every function has a docstring. Every logical section has a comment. All variable names are meaningful. Indentation is consistent throughout.
- Rubric self-assessment: mark yourself against each criterion using the rubric. Be honest - this helps you know where to focus final effort.
- Submit: upload your .py file and design document to Connect before the due date.
By the end of this lesson Task 3 is submitted and you understand what Task 4 involves.
- Final submission: verify your .py file runs without errors. Verify your design document includes problem statement, pseudocode/flowchart, test table, and evaluation. Upload both to Connect.
- T4 intro: Impacts of Computing in Society. This is a 4-lesson Extended Answer task. You will read a stimulus (article or case study) about how computing affects society and write a structured analytical response (400-500 words). Stimulus provided next lesson.
- Preview discussion: what are some ways computing has changed society? Think of both positive (medical diagnosis AI, digital communication) and negative (job automation, privacy issues, digital divide) examples.
By the end of this lesson T3 is submitted and you have read the T4 stimulus for the first time.
- If T3 not yet submitted: this is your last opportunity. Submit today.
- Read the T4 stimulus document from Connect. First read: no annotations, just read it all the way through to understand what it is about.
- Second read: annotate. Highlight or circle key claims, statistics, examples, and opinions. Note any computing impacts mentioned.
By the end of this lesson you have seen examples of strong T3 programs and understand the common errors to avoid in future tasks.
- Volunteer showcase: 2-3 students share their programs with the class. Class provides positive observations only.
- Teacher debrief: common errors seen across submissions - missing docstrings, cryptic variable names, no error handling, test table not completed. Note these for T7 (Capstone).
- T3 marks returned (if available). Review feedback and ask questions about any criterion you are unsure about.
By the end of this lesson you are ready to begin T4 with a clear understanding of the task requirements.
- Catch-up: any outstanding T3 items finalised.
- T4 framework: your teacher introduces the PEEL paragraph structure (Point, Evidence, Explain, Link) for extended answers. This is the expected writing structure for T4 and T8.
- Key concepts for T4: automation and employment, data privacy, digital inclusion, accessibility. Add definitions to your notes. You will use these in your response.
Stimulus-based written response on how computing affects society - covering automation and employment, data privacy, accessibility, and digital inclusion. Students analyse a provided article or case study and write an extended response. 4 lessons only: stimulus analysis → plan → draft → submit.
- A planning outline (annotated stimulus + dot-point plan)
- A written extended answer (400-500 words)
- Directly reference the stimulus at least twice
- Address at least two societal impacts (e.g. automation, privacy, inclusion)
- Use specific examples from the stimulus or your own knowledge
- Submitted via Connect by end of Week 8
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Stimulus Analysis /10 marks | Accurately interprets stimulus; makes insightful connections between stimulus and broader impacts | Correctly interprets stimulus; makes relevant connections | Mostly correct interpretation; some connections made | Partial interpretation; limited connections | Little evidence of stimulus analysis |
| Analytical Writing /10 marks | Response is well-structured, argues a clear position, addresses multiple societal impacts with specific examples from stimulus and own knowledge. | Response structured and addresses at least two societal impacts with examples. | Response addresses impacts but may be one-sided or lack specific examples. | Response is brief or lacks structure; examples are vague or absent. | Response does not meaningfully address computing impacts on society. |
| Planning Evidence /5 marks | Detailed annotated stimulus and outline clearly inform the final response | Annotated stimulus and outline present; mostly inform the response | Planning present; connection to final response is partial | Planning is minimal | No planning evidence submitted |
By the end of this lesson you have read and annotated the T4 stimulus and identified at least four computing impacts to discuss.
- Open the Task 4 stimulus on Connect. Read it all the way through without annotating first.
- Second read: annotate. Circle computing impacts (positive or negative). Underline evidence (statistics, examples, case studies). Note stakeholders affected (workers, consumers, government, community).
- Key concepts check: automation and employment (jobs replaced or created by technology), data privacy (right to control your personal data), digital inclusion (equal access to technology), accessibility (technology designed for people with disabilities).
- In your planning document, list at least 4 impacts from the stimulus. For each: who is affected, and how (positive or negative)?
By the end of this lesson you have a dot-point plan for your extended answer with two paragraphs planned in PEEL structure.
- Select your two strongest impacts to write about - pick ones with clear stimulus evidence you can reference.
- PEEL structure: Point (your claim about the impact), Evidence (quote/statistic from the stimulus - reference it), Explain (what it means, why it matters), Link (back to the question / broader implication).
- Write a dot-point PEEL plan for each of your two paragraphs. This planning is submitted alongside your response.
- Write an introduction sentence: "Computing has significantly impacted society in several ways, including [impact 1] and [impact 2]."
By the end of this lesson you have written a full 400-500 word draft extended answer response.
- Write your introduction (2-3 sentences), two body PEEL paragraphs, and a conclusion (2 sentences). Aim for 400-500 words.
- Reference the stimulus at least twice: "According to the article..." or "The stimulus states that..."
- Use domain vocabulary: automation, algorithm, data privacy, digital divide, accessibility, inclusion, stakeholder, ethical, impact.
- Peer swap: swap documents with a partner. Read their draft and write one specific improvement suggestion (not a general comment like "good job" - something specific like "your second paragraph needs a stimulus reference").
By the end of this lesson Task 4 is submitted and you have completed Semester 1.
- Implement peer feedback from L3. Make targeted improvements - do not rewrite everything, just address the specific gaps identified.
- Final proofread: read every sentence. Fix unclear phrasing. Check that each body paragraph has: a clear point, stimulus evidence, an explanation, and a link back to the question.
- Submission checklist: (a) extended answer document, (b) annotated stimulus, (c) dot-point planning outline. Submit all components to Connect.
- Submit all components to Connect. This is the final task of Semester 1 / Module 1. Well done.
Use Week 10 to consolidate Module 1 content, finalise any outstanding submissions, and prepare for Semester 2.
- Review feedback from Tasks 1-4 and identify areas to improve in Semester 2
- Finalise any late or incomplete submissions (check with your teacher for late work policy)
- Revisit Python fundamentals from Task 1 - functions, loops, and file handling are core to Module 2
- Review algorithm and data representation concepts from Task 2 using your notes or revision slides
- Use your T3 program as a base - read through the code and trace its logic step by step
- Preview Module 2 content: read the Task 5 brief on Connect before Semester 2 begins
Write Python programs to read CSV data, process it using lists and basic statistics (min, max, average, count), and output results clearly. Includes at least one sorting or searching algorithm applied to the data, and a written interpretation of findings.
- Python program that reads a provided CSV file using open()
- Calculates min, max, average, and count from the data using lists
- Applies at least one sort (bubble sort, selection sort, or sorted()) or search
- Outputs results clearly with labels
- A written interpretation of findings (150-200 words)
- Code runs without errors; CSV reading uses open() not third-party libraries
- At least one function used for statistical calculations
- Interpretation addresses what the data shows and notes any interesting findings
- Submitted via Connect by due date
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| File Processing /15 marks | CSV file read correctly using open(); data parsed into a list; all rows processed accurately; file handling integrated smoothly into program logic without errors. | CSV file read and mostly processed correctly; minor parsing issues. | CSV reading attempted; data partially parsed; some rows processed incorrectly. | File reading attempted but produces errors in some cases; data not fully accessible. | No CSV file handling implemented or fundamentally broken. |
| Algorithm Application /10 marks | Min, max, average, and count calculated correctly; at least one sort or search algorithm correctly implemented and applied to the data. | Three or more statistics correct; sort/search implemented with minor errors. | At least two statistics correct; sort or search attempted but may have logic errors. | One or two statistics attempted; sort/search missing or non-functional. | No statistical calculations or algorithm applied. |
| Output Quality /8 marks | Results clearly labelled and formatted; output is readable and meaningful; appropriate use of f-strings or format() for presentation. | Results labelled and mostly readable; minor formatting issues. | Results present but inconsistently labelled or formatted. | Results output but difficult to read or interpret without context. | No meaningful output or output not related to data processed. |
| Interpretation /7 marks | Written interpretation accurately summarises key findings from the data; identifies at least one interesting trend or anomaly; conclusion is clearly supported by results. | Interpretation summarises findings; trend or anomaly noted with some support. | Interpretation addresses data generally; findings partially supported. | Interpretation is brief or does not clearly reference the computed results. | No interpretation submitted. |
By the end of this lesson you can read a CSV file in Python and store its contents in a list.
- Your teacher provides the T5 dataset: a CSV file with at least 20 rows of real data (e.g. monthly sales figures, temperature readings, or student scores). Download it to your Replit or local machine.
- Python lists:
numbers = [45, 72, 88, 31, 95]- a list stores multiple values. Access by index:numbers[0]= 45. Append:numbers.append(60). - Read a CSV:
with open("data.csv","r") as f:
for line in f:
print(line.strip()) - Parse into a list:
data = []
with open("data.csv","r") as f:
next(f) # skip header row
for line in f:
parts = line.strip().split(",")
data.append(parts) - Print the first 5 rows and count total rows. Check your data looks correct.
By the end of this lesson you can extract a column of numeric data from a CSV file as a list of floats ready for calculation.
- Problem: CSV files store everything as strings. To calculate, you need numbers. Convert:
value = float(parts[1]) - Write a function
load_data(filename)with docstring that reads the CSV and returns a list of tuples: (label, value). E.g. [("January", 4500.0), ("February", 3820.0), ...] - Wrap the float() conversion in try/except ValueError to handle any non-numeric rows gracefully.
- Extract just the values into a separate list:
values = [row[1] for row in data]. This is a list comprehension - a concise way to create a list from another list.
By the end of this lesson you have a working calculate_stats() function that returns min, max, average, and count for your dataset.
- Write
calculate_stats(values)with docstring:def calculate_stats(values):
"""Returns min, max, average, count for a list of numbers."""
return min(values), max(values), sum(values)/len(values), len(values) - Call it and print results with labels using f-strings:
lo, hi, avg, count = calculate_stats(values)
print(f"Min: {lo:.2f} Max: {hi:.2f} Avg: {avg:.2f} Count: {count}") - Add a find_max_entry() function that returns the label and value of the highest entry in your dataset (not just the number, but which month/item it corresponds to).
- Test with your full dataset. Check the results make sense visually.
By the end of this lesson you have implemented at least one sorting algorithm and can output your data in sorted order.
- Bubble sort: repeatedly compare adjacent elements and swap if out of order. Implement it for your values list. Trace through 5 elements manually to see how it works.
- Python built-in:
sorted_data = sorted(data, key=lambda x: x[1])- sorts your list of tuples by the value column. Note this is NOT the same as implementing your own sort. - The rubric requires at least one sort algorithm "implemented and applied to the data." Use bubble sort (or selection sort) as your implementation, but you can also show sorted() as an alternative.
- Print your data sorted lowest-to-highest and highest-to-lowest. Format output clearly.
By the end of this lesson you can write a linear search function that finds a specific item in your dataset.
- Linear search: check each item in the list until you find the target (or reach the end). Write
find_item(data, target_label)that returns the row matching the label. - Binary search concept: only works on sorted data. Divide the list in half, check the middle, go left or right. Much faster than linear search for large datasets. At General level, describe and demonstrate - implementation is optional.
- Integrate search into your program: prompt the user to enter a label (e.g. a month name) and display that row’s data.
By the end of this lesson your program displays all results clearly with labels, units, and appropriate decimal places.
- F-strings with formatting:
f"{value:.2f}"= 2 decimal places.f"{label:<15}"= left-aligned in 15 chars.f"${value:,.2f}"= currency with comma separator. - Write a
display_results(data, stats)function that prints a formatted summary: header, all rows in columns, then the statistical summary. - Print a separator line between sections:
print("-" * 40) - Output Quality is worth 8 marks on the rubric. Clear, labelled output is essential.
By the end of this lesson your T5 program has been tested, peer-reviewed, and is code-quality ready.
- Test table: at least 5 tests - normal data, empty file, non-numeric row, single row, large dataset. Record expected vs actual output.
- Code quality pass: every function has a docstring. Every major section has a comment. Variable names are meaningful.
- Peer review: swap with a partner. They check: Does it run? Is the output clear? Are there docstrings? Write one improvement suggestion each.
By the end of this lesson you have written a clear 150-200 word interpretation of your data analysis findings.
- Look at your program output: what does the data show? Which month/item is highest? Lowest? Is there a trend (increasing over time, seasonal pattern)? Any anomaly (one unusual value)?
- Write your interpretation (150-200 words): (1) what the data set represents, (2) key statistical findings (highest, lowest, average), (3) any interesting trend or anomaly, (4) a conclusion about what the data tells you.
- Your interpretation should refer to specific numbers from your program output, not vague statements like "some values were high."
By the end of this lesson Task 5 is submitted to Connect.
- Run your complete program one final time. Verify all output is correct and clearly formatted.
- Check filename:
Smith_J_T5_main.pyand the CSV file included in submission. - Submit to Connect: Python file + CSV data file + written interpretation document.
- T6 preview: Cybersecurity & Digital Systems starts next lesson. This is an in-class test (same format as T2). Content: threats (malware, phishing, social engineering), protections (encryption, firewalls, 2FA), digital systems (networks, cloud). Begin reading your notes from last term if you covered any of this.
By the end of this lesson Task 5 is submitted and you understand Python dictionaries as a data structure.
- Late submissions: this is the last opportunity for T5. Submit now if not yet done.
- Dictionaries:
person = {"name": "Alex", "age": 16, "score": 88}. Access by key:person["name"]. Add:person["grade"] = "B". - Dictionaries vs lists: lists store items by index (position). Dictionaries store items by key (name). Use a dictionary when you want to look something up by name rather than by number.
- T7 Capstone preview: your Capstone program in T7 will use functions, file I/O, lists, dictionaries, error handling, and a sort/search. Start thinking about what kind of program you’d like to build.
By the end of this lesson you understand variable scope (local vs global) and can design a modular program structure.
- Scope: a variable defined inside a function is local - it only exists inside that function. A variable defined outside all functions is global - accessible everywhere. Avoid using global variables where possible; pass data as parameters instead.
- Demonstrate scope: define
x = 10at module level and inside a function. Show they are separate. - Modular design principle: each function does ONE thing. If a function is over 20 lines, it probably does too much and should be split. Apply this to your T7 Capstone planning.
By the end of this lesson you understand what T6 covers and have started your cybersecurity notes.
- T5 debrief: your teacher returns T5 marks (if available). Review feedback. Common issues: CSV not reading correctly, stats function missing edge case handling, output not clearly labelled.
- T6 preview: Cybersecurity & Digital Systems. Content: (1) Threats - malware (virus, ransomware, spyware), phishing, social engineering. (2) Protections - encryption, passwords & 2FA, firewalls, backups. (3) Digital systems - networks (LAN/WAN/cloud), hardware roles.
- Start your T6 notes file. Create a heading for each content area. Fill in what you already know from prior knowledge. We’ll build on this in T6 lessons.
Formal theory test on Socrative covering cybersecurity threats (malware, phishing, social engineering), protection strategies (encryption, passwords, firewalls), and digital systems (networks, hardware roles, cloud computing). Lessons 1-10 build content knowledge. Lesson 11 is the formal Socrative assessment. Lesson 12 is return and review. No AI in L11.
- Completed Socrative quiz (in-class, on your device - L11)
- Cybersecurity notes from Lessons 1-10
- Practice test completed and self-marked (L9)
- Threat/protection summary table (L5-L6)
- Test completed individually on Socrative - no notes, no internet, no AI
- Log in at b.socrative.com/student-v2/join using the Room Name given by your teacher
- All answers in full sentences unless otherwise instructed
- Test returned and reviewed in L12 - corrections submitted to teacher
- Content areas: malware, phishing, social engineering, encryption, firewalls, networks, cloud
- 1Open the link above (or the Socrative Student app on your device)
- 2Enter the Room Name your teacher gives you
- 3Type your First Name and Last Name when prompted
- 4Wait for your teacher to launch - do not click ahead
- 5Answer each question, then click Submit when done
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Cybersecurity Knowledge /12 marks | Accurately identifies and explains a range of cybersecurity threats (malware, phishing, social engineering, ransomware) with specific examples and consequences. | Mostly accurate threat explanations; most examples relevant. | Generally accurate; some threats confused or examples missing. | Partial understanding; limited examples; significant gaps. | Minimal understanding of cybersecurity threats demonstrated. |
| Digital Systems /12 marks | Accurately explains protection strategies (encryption, firewalls, 2FA, backups), network types, and cloud computing with clear distinctions between use cases. | Mostly accurate explanations; most protection strategies correctly described. | Generally accurate; some protection strategies or network concepts confused. | Partial accuracy; significant gaps in protection or network knowledge. | Little accurate understanding of digital systems or protection strategies demonstrated. |
| Communication /6 marks | Responses use correct CS and cybersecurity terminology throughout; clear, well-structured answers that directly address the question asked. | Terminology mostly correct; most answers clear and structured. | Some terminology used correctly; generally understandable. | Limited correct terminology; some responses unclear. | Responses difficult to understand; terminology largely absent or incorrect. |
By the end of this lesson you can define five types of malware and give a real-world example of each.
- Malware = malicious software. Types table in your notes: Virus (attaches to files, spreads when file opened), Worm (self-replicates across networks, no user action needed), Ransomware (encrypts files, demands payment), Spyware (secretly monitors activity, steals data), Trojan (disguised as legitimate software, opens backdoor).
- For each type: add a real-world example. Research: WannaCry (ransomware, 2017, NHS), ILOVEYOU (virus, 2000), Pegasus (spyware). Add date, target, and impact to your notes.
- How malware spreads: email attachments, infected downloads, removable media (USB), compromised websites, network vulnerabilities. Note at least two for each malware type.
- Impact categories: financial (ransom, theft), operational (systems down), reputational (loss of customer trust), legal (data breach fines under Australian Privacy Act).
By the end of this lesson you can identify social engineering tactics and explain why they are effective.
- Social engineering exploits human psychology, not technical vulnerabilities. Key types: Phishing (fake email/website to steal credentials), Spear phishing (targeted phishing using personal details), Pretexting (fake scenario to extract information), Baiting (infected USB left in public), Shoulder surfing (watching someone type their password).
- Phishing red flags: urgent language ("Your account will be closed in 24 hours!"), generic greeting ("Dear Customer"), misspelled domain (paypa1.com), requests for passwords or credit card numbers, suspicious sender address.
- Analyse three example phishing emails (provided by teacher). For each: identify the red flags, determine the likely target, and describe what would happen if the victim clicked the link.
- Why it works: attackers exploit urgency, fear, authority (impersonating bosses or banks), and curiosity. No technical skill is needed to be fooled. Note in your answers: "Social engineering is effective because it targets human emotions rather than technical systems."
By the end of this lesson you can explain how strong passwords, multi-factor authentication, and encryption protect against cyberthreats.
- Strong passwords: minimum 12 characters, mix of uppercase, lowercase, numbers, symbols. Never reuse passwords. Use a passphrase: "Coffee!Sunrise2026" is stronger than "p@ssw0rd". Password managers store unique passwords per site.
- Multi-Factor Authentication (MFA/2FA): combines something you KNOW (password) + something you HAVE (phone/token) + something you ARE (fingerprint/face). Even if a password is stolen, the attacker still can't log in without the second factor.
- Encryption: converts readable data (plaintext) to unreadable data (ciphertext) using a key. Symmetric encryption uses the same key to encrypt and decrypt (fast, used for bulk data). Asymmetric uses a public key to encrypt and a private key to decrypt (used for secure communication). HTTPS uses asymmetric to exchange a symmetric key.
- End-to-end encryption: only sender and recipient can read messages. Even the service provider can't read them. Used by Signal, WhatsApp (in part). Important for privacy.
- Note the link to T7: your Capstone program might handle user data. What ethical responsibility do you have to protect that data?
By the end of this lesson you can explain how firewalls, antivirus software, and backup strategies protect systems.
- Firewall: monitors incoming and outgoing network traffic and blocks unauthorised connections based on rules. Hardware firewall (device, protects the whole network) vs software firewall (installed on a device, protects that device only). Analogy: a security guard at the network's door.
- Antivirus/anti-malware: scans files and memory for known malware signatures, and uses heuristic analysis to detect suspicious behaviour (zero-day threats). Must be kept up to date - outdated antivirus can't detect new malware.
- Backup strategies: 3-2-1 rule - keep 3 copies of data, on 2 different media types, with 1 offsite. Types: full backup (everything, slow, large), incremental (only changes since last backup, fast), differential (changes since last full backup). Recovery time matters: after ransomware, how quickly can you restore?
- Scenario: a school is hit by ransomware. Their firewall failed to block the phishing email, antivirus didn't detect the payload, and their last backup is 3 weeks old. Describe the impact and what they should have done differently.
By the end of this lesson you can describe common network types and the hardware used to build them.
- Network types: LAN (Local Area Network - covers a building or campus), WAN (Wide Area Network - connects geographically separate LANs, the internet is a WAN), Cloud network (services hosted remotely, accessed via internet).
- Network hardware: Router (directs data between networks, connects LAN to internet), Switch (connects devices within a LAN, smarter than a hub), Access Point (provides Wi-Fi, wireless connection to the network), Modem (converts digital signal to/from the ISP's signal).
- Wired vs wireless: wired (Ethernet/Cat6) is faster and more secure. Wireless (Wi-Fi 802.11) is more flexible but susceptible to eavesdropping if unencrypted.
- Draw a simple network diagram for a school: internet → modem → router → switch → wired computers AND access point → student laptops/phones. Label each device and its function.
By the end of this lesson you can explain the three cloud service models and evaluate cloud computing for a given context.
- Cloud models: SaaS (Software as a Service - use software via browser, e.g. Gmail, GitHub, Replit), PaaS (Platform as a Service - develop and deploy apps without managing infrastructure, e.g. Heroku, Replit), IaaS (Infrastructure as a Service - rent virtual servers and storage, e.g. AWS EC2, Azure VMs).
- Benefits: no upfront hardware cost, scales up/down on demand, accessible from anywhere, automatic updates, disaster recovery built in.
- Risks: internet dependency (no internet = no access), data privacy (where is your data stored?), vendor lock-in (hard to migrate), ongoing subscription cost.
- Data sovereignty: Australian data may be stored on servers overseas. The Privacy Act 1988 has implications for organisations storing personal data overseas. Note this connects to T8 ethics content.
By the end of this lesson you can match cyberthreats to appropriate countermeasures and apply them to real scenarios.
- Threat/protection table: create a two-column table. Left: each threat type. Right: the best countermeasure(s). E.g. Phishing → security awareness training, email filtering, 2FA. Ransomware → regular backups, antivirus, patched OS.
- Scenario 1: A hospital employee receives an email saying "Your IT password expires in 2 hours - click here to reset." They click and enter their credentials. Two days later, all patient records are encrypted. Identify: (a) the attack type, (b) how it succeeded, (c) what should have stopped it.
- Scenario 2: A small business stores all files on a single computer with no backup. Identify three risks and three improvements.
- Kahoot: 15 questions covering all T6 content so far. Note which answers you got wrong.
By the end of this lesson you can explain how operating system updates and hardware features contribute to system security.
- Why update software? Security patches fix known vulnerabilities. WannaCry ransomware (2017) exploited a Windows vulnerability Microsoft had already patched - systems that hadn't updated were infected. Unpatched software = known open door for attackers.
- Operating system security features: user account control (UAC), file permissions, sandboxing (isolating apps), secure boot (only trusted OS loads at startup).
- Hardware security: biometric authentication (fingerprint, face ID) - harder to steal than a password. Trusted Platform Module (TPM) - a chip that stores encryption keys securely. Physical security: screen locks, cable locks for laptops.
- Principle of least privilege: users should only have the access they need for their role. A teacher doesn't need admin rights to the school network. Limits the damage if their account is compromised.
By the end of this lesson you have completed a full practice test and know exactly what to revise before L11.
- Practice test (40 min, same format as L11): no notes, no devices. Covers: malware types, social engineering, protection strategies, networks, cloud, digital system security.
- Self-mark with teacher's marking guide. Calculate your score for each criterion (Cybersecurity Knowledge /12, Digital Systems /12, Communication /6).
- Targeted revision: 10 minutes on your weakest area. If you lost marks on Digital Systems, re-read your network and cloud notes. If Communication, practise writing full-sentence answers.
By the end of this lesson you feel confident and ready for the T6 test in L11.
- Open-floor questions: any student can ask the teacher to clarify a concept. Maximum 5 class questions.
- Partner quiz: alternate asking each other definitions. Use your revision card. Cover: all malware types, all protection strategies, network hardware, cloud models.
- Reminder: no notes, no devices, no AI in L11. Write full sentences. Show reasoning. Use technical terminology - it’s worth marks in the Communication criterion.
Complete the Task 6 short answer test to the best of your ability.
- Sit in your assigned seat. Clear your desk. Pen only.
- Read all questions before starting. Allocate time proportionally to marks.
- For definition questions: define + give an example + explain the impact. Three elements for full marks.
By the end of this lesson you understand your test results and have been introduced to Task 7: Capstone Program.
- Tests returned. Teacher walks through answers. Write corrections for any wrong answers and submit corrections document.
- Your teacher introduces Task 7: Capstone Program. This is the largest task of Module 2 (20%, /60). You will design and build a complete Python program demonstrating all Unit 2 skills. Think about your program idea before next lesson. Starting next lesson (Task 7, Term 4 Week 4).
- Capstone ideas: inventory management system, student grade tracker, simple quiz app with topic categories, personal budget calculator, word frequency counter. What problem would YOU like to solve with Python?
Design and build a complete Python program demonstrating all Unit 2 skills: functions, file I/O, lists, error handling, and at least one sorting or searching algorithm. Must include a design document, test evidence, and a reflection. Peer review required.
- A working Python program using functions, file I/O, and lists
- Design document: problem statement, pseudocode/flowchart algorithm plan
- Test evidence: at least 6 test cases with expected vs actual results
- Reflection (5-8 sentences) on the design and development process
- Peer review: written feedback on a classmate's capstone program
- At least three functions with parameters and return values
- File I/O: reads and writes a data file (CSV or text)
- At least one sort or search algorithm implemented
- Error handling using try/except for file operations
- Submitted via Connect by due date with all documentation
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Design & Planning /18 marks | Clear problem statement; pseudocode or flowchart fully maps all major program components; design shows complete plan→code→test→evaluate cycle; test plan with 6+ cases present before coding. | Design document mostly complete; plan maps most components; test plan mostly developed before coding. | Design document present; plan partially maps program; test plan partially developed. | Design document attempted but incomplete; limited evidence of upfront planning. | No design document or planning evidence submitted. |
| Program Functionality /18 marks | Program runs without errors; all required features work correctly (functions, file I/O, lists, sort/search, error handling); handles edge cases and invalid input gracefully. | Program runs; most features work; minor edge-case issues or one feature incomplete. | Program partially functional; core features mostly present but some produce incorrect output. | Program runs but significant features non-functional or missing; logic errors throughout. | Program does not run or is fundamentally incomplete. |
| Code Quality /12 marks | All functions documented; meaningful comments throughout; descriptive variable names; consistent Python style; code is readable and well-structured. | Functions mostly documented; most sections commented; style mostly consistent. | Some documentation and comments; variable names mostly meaningful; readable with effort. | Minimal comments or documentation; variable names cryptic; style inconsistent. | No comments or documentation; code unreadable or very poorly structured. |
| Reflection /12 marks | Reflection clearly identifies challenges and solutions; connects design decisions to outcomes; evaluates program limitations; incorporates peer review feedback received with specific changes made. | Reflection addresses challenges and peer feedback; most areas covered with good detail. | Reflection present; addresses some challenges and peer feedback; coverage uneven. | Reflection brief; limited critical thinking; peer feedback not clearly addressed. | Reflection not submitted or does not address the program development process. |
By the end of this lesson you have a teacher-approved Capstone program idea and a completed decomposition of its sub-problems.
- Capstone requirements (non-negotiable): at least three functions with parameters and return values, file I/O reading AND writing a data file (CSV or text), at least one sort or search algorithm, error handling using try/except, and a design document with test evidence.
- Program options: inventory management system (add/remove/search/sort items, save to CSV), student grade manager (add students, calculate stats, save/load), quiz application with topic categories (load questions from file, score and save results), personal budget tracker (income/expense categories, totals, save to file). Or propose your own - must meet all requirements.
- Decompose your chosen program into at least 6 sub-problems. Each should map to a function. Add to design document.
- Teacher sign-off: show your idea and decomposition. No coding until approved.
By the end of this lesson your design document includes pseudocode for the main program, a flowchart for the core logic, and a test plan skeleton.
- Pseudocode: write the main program flow from start to end. Include: how it starts (load file), main menu loop, what each option calls, how it ends (save file). Use CALL function_name for each sub-task.
- Flowchart: draw the flowchart for your most complex function (typically the add/search/sort operation). Use correct symbols.
- Test plan skeleton (fill in before coding): create a table with columns: Test #, What is being tested, Input, Expected Output, Actual Output, Pass/Fail. Add at least 6 rows with the Test # and What is being tested filled in now. You’ll fill Expected and Actual during testing.
- Design document structure: Title, your name, program description, decomposition list, pseudocode, flowchart, test plan. Submit or show teacher today.
By the end of this lesson you have a working program skeleton with file I/O loading and saving correctly.
- Create your Capstone file:
Smith_J_T7_capstone.py. Add a header comment block with your name, task, and a description. - Write all function stubs first. Every function has a docstring and returns a placeholder. Run it - it should work with no errors before you add real logic.
- Implement
load_data(filename)andsave_data(data, filename)first - these are the foundation. Wrap both in try/except: load handles FileNotFoundError (first run), save handles IOError. - Test file I/O immediately: create some dummy data, save it, reload it, print it. Confirm data survives the save/load cycle before building on top of it.
By the end of this lesson your main menu loop is running and at least two core functions are implemented and tested.
- Implement the main menu: a while True loop that displays options, gets the user’s choice (with validation), and calls the appropriate function. Break on the quit/save option.
- Implement your add/create function. Use input validation: check required fields are not empty, check numeric fields are actually numbers (try/except), check ranges where relevant.
- Implement your display/list function: loop over the data list and print each item using a consistent f-string format.
- Test after each function - do not wait until all functions are done. Incremental testing catches bugs early when they are easier to fix.
By the end of this lesson your Capstone program has a working sort and search function integrated into the menu.
- Sort: implement
sort_data(data, field)using bubble sort or selection sort (must implement, not just use sorted()). Optionally also offer a sorted() shortcut. Let the user choose ascending or descending. - Search: implement
search_data(data, query)using linear search. Return all matching rows (not just the first). Print results clearly. - Add sort and search as menu options. Test with: normal data, search term that has no match, sort on empty list.
- Add test cases for sort and search to your test plan and fill in Expected Output.
By the end of this lesson your program handles all foreseeable error conditions gracefully without crashing.
- Error audit: go through every input() call and every file operation. Ask: what happens if the user enters the wrong type? What if the file doesn’t exist? What if the list is empty? Add try/except for each risk.
- Empty list guard: before sort, search, or display - check if the list is empty and print a friendly message rather than crashing.
- Run all your test cases. Record Actual Output. Mark Pass/Fail. Fix any FAILs. Re-test until all pass.
- Count your try/except blocks - you need at least two: one for file load, one for numeric input.
By the end of this lesson every function has a docstring, every major section has a comment, and all variable names are meaningful.
- Docstring check: search for "def " in your code. Every occurrence must have a triple-quoted docstring on the next line describing what the function does, its parameters, and what it returns.
- Comment check: every logical section (file loading, menu, each major function block) should have a # comment above it. Comments explain WHY, not just what. "# load existing data from file, or start with empty list if first run" is a good comment.
- Variable names: rename any single-letter or cryptic names.
x→user_choice.d→inventory_data. - Code Quality is worth 12 marks on the T7 rubric. This lesson directly improves your mark.
By the end of this lesson you have given detailed written peer feedback and made at least one improvement based on the feedback you received.
- Swap Replit links with your assigned partner. Read their full program - run it too if possible.
- Write feedback (minimum 150 words): (1) what works well and why, (2) something that is unclear or could be improved - be specific (which line or function?), (3) one concrete suggestion. Include at least one comment about code quality (docstrings, naming, comments).
- Receive feedback. Implement at least one specific suggestion. Document what you changed and why in your reflection section of the design doc.
- Peer review is worth marks under the Reflection criterion (12 marks). A good response to feedback is as important as the feedback you give.
By the end of this lesson you have written a reflective evaluation of your Capstone program development process.
- Reflection structure (add to design document): (a) What does your program do? (2-3 sentences), (b) What challenges did you encounter during development and how did you solve them? (Describe at least 2, use technical terminology), (c) What does your program do well? (Link to rubric criteria), (d) What doesn’t work perfectly or is limited? Be honest, (e) What would you add or improve with more time? (At least 2 ideas), (f) How did peer review change your program? (Specific change you made).
- Minimum 200 words. Use programming terminology: function scope, exception handling, file persistence, data structure, algorithm.
- Also add a brief evaluation of your design document: did your pseudocode match what you built? What changed from your plan and why?
By the end of this lesson your Capstone is fully tested, your design document is complete, and you are ready to submit.
- Final run: execute your full program from start to finish - add data, display, sort, search, save, quit. Reload - confirm data persists. This is your final functional test.
- Complete your test table: fill in all Actual Output fields. Mark all Pass/Fail. Fix any remaining FAILs.
- Rubric self-assessment: go through each criterion (Design & Planning /18, Program Functionality /18, Code Quality /12, Reflection /12). Give yourself an honest rating. Is there anything you can still improve?
- File check:
Smith_J_T7_capstone.pyand design document (PDF or Google Doc link). Submission includes: Python file, any data files needed, design document.
By the end of this lesson Task 7 is submitted and you understand what Task 8 involves.
- Submit to Connect: upload .py file, design document, and any required data files. Confirm submission received.
- T8 intro: Ethics in Computing. Same format as T4: 4 lessons, stimulus-based extended answer (400-500 words). Topics: AI bias, intellectual property and open source, data collection practices, responsible technology use. You must connect at least one issue to your T7 Capstone program context.
- Stimulus preview: read the T8 stimulus from Connect. First read only - no annotation yet. What is the main issue being discussed?
By the end of this lesson you have seen examples of strong Capstone programs and started your T8 stimulus annotation.
- Volunteer showcase: 2-3 students run their Capstone programs for the class. Class notes one thing they like about each program’s design.
- Late submissions: if T7 is not yet submitted, this is your last chance. Submit today. No further extensions.
- T8 annotation: read the stimulus a second time and annotate. Circle computing ethics issues. Underline evidence. Note which issues connect to your T7 Capstone context (e.g. if your program handles user data, data privacy is directly relevant).
Stimulus-based response on ethics in computing - AI bias, intellectual property and open source software, data collection practices, and responsible technology use. Connects Unit 2 impacts to the T7 program design context. Same format as Task 4: 4 lessons only.
- Extended answer (400-500 words)
- Planning outline with annotated stimulus
- At least 2 direct stimulus references
- Address at least two computing ethics issues (e.g. AI bias, IP, data privacy)
- Connect at least one issue to your T7 program design context
- Submitted via Connect by end of Week 8
| Criterion | A - Exc | B - High | C - Sat | D - Ltd | E - Min |
|---|---|---|---|---|---|
| Stimulus Analysis /10 marks | Accurately interprets stimulus; makes insightful connections between stimulus content and broader ethical issues. | Correctly interprets stimulus; makes relevant connections. | Mostly correct interpretation; some connections made. | Partial interpretation; limited connections to ethical issues. | Little evidence of stimulus analysis. |
| Ethical Reasoning /10 marks | Clearly articulates at least two computing ethics issues; evaluates competing interests; connects at least one issue to own T7 program context; proposes reasoned positions with specific examples. | Two ethics issues identified and addressed; T7 connection present; examples included. | Ethics issues addressed; T7 connection attempted; examples partially developed. | Ethics issues briefly mentioned; limited reasoning; T7 connection absent or very vague. | Little ethical reasoning evident; no connection to program context. |
| Planning Evidence /5 marks | Detailed annotated stimulus and dot-point outline clearly inform and connect to the final response. | Annotated stimulus and outline present; mostly inform the response. | Planning present; connection to final response is partial. | Planning is minimal or superficial. | No planning evidence submitted. |
By the end of this lesson you have read and annotated the T8 stimulus and identified at least four computing ethics issues.
- Open the Task 8 stimulus on Connect. Read it all the way through without annotating first.
- Second read: annotate. Circle ethics issues. Underline evidence. Note which issues connect directly to your T7 Capstone context.
- Computing ethics framework - key concepts for your notes: Algorithmic bias (AI systems making unfair decisions due to biased training data - e.g. facial recognition failing for dark-skinned faces), Intellectual Property (copyright, open-source licensing - MIT, GPL, Apache), Data collection ethics (informed consent, data minimisation, right to erasure, GDPR/Australian Privacy Act), Responsible technology use (digital addiction, surveillance, environmental impact of computing).
- In your planning document, list at least 4 ethics issues from the stimulus. For each: (a) what is the issue, (b) who is affected, (c) is it relevant to your T7 program - why or why not?
By the end of this lesson you have a dot-point plan for two PEEL paragraphs and a clear T7 program connection identified.
- Select your two strongest ethics issues - pick ones where you have stimulus evidence AND can make a T7 connection for at least one.
- PEEL plan for each paragraph: Point (the ethics issue), Evidence (from stimulus - quote or paraphrase with reference), Explain (why this is an ethical problem, who is harmed, what values are violated), Link (to broader computing context or T7 program).
- T7 connection example: "My Capstone program stores user data in a CSV file. An ethical concern raised in the stimulus - data minimisation - applies here: I should only collect the data my program needs, not additional fields. Users should also be informed what data is stored."
- Write your introduction sentence: a clear statement of the two ethics issues you will discuss.
By the end of this lesson you have a complete 400-500 word draft extended answer response.
- Write your full response: introduction (2-3 sentences), two PEEL body paragraphs, conclusion (2 sentences). Aim for 400-500 words.
- Reference the stimulus at least twice: "The stimulus highlights..." or "According to the article,..."
- Connect to T7: at least one reference to your Capstone program. "When developing my T7 inventory management program, I considered..." or "This is relevant to programmers like myself who..."
- Use ethics vocabulary: algorithmic bias, informed consent, data minimisation, intellectual property, open source, digital rights, privacy, accountability, transparency, stakeholder.
- Peer swap: swap drafts with a partner. Write one specific improvement suggestion: which paragraph needs a stronger T7 connection? Where is evidence missing?
By the end of this lesson your Task 8 extended answer and planning evidence are submitted, completing Year 11 CS General.
- Implement peer feedback from L3. Make targeted improvements - address the specific gaps, not a full rewrite.
- Final proofread: read every sentence. Check each paragraph has: a clear ethics Point, stimulus Evidence referenced, an Explanation, and a Link to computing or T7 context.
- Submission checklist: (a) extended answer (400-500 words) on Google Doc or Word, (b) annotated stimulus, (c) dot-point planning outline. Submit all to Connect.
- Submit all components to Connect before the end of this lesson.
Use Week 10 to consolidate Module 2 content, finalise any outstanding submissions, and reflect on the full year.
- Review feedback from Tasks 5-8 and identify skills to develop further
- Finalise any late or incomplete submissions before the final cutoff
- Revisit cybersecurity concepts from Task 6 - can you explain five threat types and their mitigations from memory?
- Review your T5 Python code - trace through the CSV processing logic and the sort/search algorithm step by step
- Reflect on your T7 Capstone Program: what would you add or improve with more time?
- Use AI Copilot to quiz yourself: ask it to generate 5 short-answer questions on GECS Unit 2 content