An Eduspace Wiki
Changelog
Documentation
Toggle dark mode
Login
Home
A - Z
Page Index
Home
dt7
2026 Digital Technologies - Year 7 - Term 2
Cable and Interface Quick Guide
Crash Course - Binary
FreeCAD Extension
GPU vs CPU
Raspberry Pi - Setting Up
Raspberry Pi Foundation - What Is A Raspberry Pi
Robot Marathon
Tom Scott - Fetch Execute Cycle
Vibe Coding Music with Strudel
Vox - Undersea Cables
Workshop 1 Hardware and Networks
Year 7 Hub
sd
C01
AI Disclosure
C01-home
Critical Path
Essential Terms
Mr Chen's SAT GitHub Projects
Overflow
Problem-Solving Methodology
Roadmap View vs Gantt Chart
TELOS Feasibility
Testing vs Validation vs Evaluation
C02
Building Your C2-1 Poster
C02-home
Context Diagram
Context Diagram vs Data Flow Diagram
Data Collection Methods
Data Flow Diagram
Essential Terms
Excalidraw Diagram Starters
Explaining vs Describing Your Data Collection
Hand-Drawing Cheat-Sheet
Use Case Diagram
User Stories and MoSCoW
What Is an Entity
C03
Analytical Tools Template Guide
C03-home
Essential Terms
Evaluating Your Own Questions
Functional vs Non-Functional Requirements
Scope vs Constraints
Technical Environment — Five Categories
C04
Activity - Hot Cross Bun Matrix
Brainstorming
C04-home
C4-1 Checkpoint - Design Pack
C4-2 Checkpoint - Evaluation Matrix
CHOICE Headphones - Spotting Efficiency and Effectiveness
Design Sketches
Designing an Evaluation Matrix
Efficiency vs Effectiveness
Essential Terms
Evaluation Criteria and the SRS
Evaluation vs Testing
Mind Mapping
Mood Boards
C05
Annotated Mock-up in Excalidraw
C04 to C05 - Choose then Detail
C05-home
Connect the Dots
Creative Thinking for Your Godot Project
Data Dictionary
Design Principles
Design Principles vs UX Characteristics
Essential Terms
From SRS to Detailed Designs - Data and Logic
From SRS to Detailed Designs - Mock-ups
IPO Charts - Process Means Steps
Object Descriptions and Class Diagrams
Plan B Contingency Table
Plan B Ready
Shoulders of Giants
Sketch vs Mock-up
The Annotation Verb Ladder
UX Characteristics
VCAA Pseudocode Not Python
C06
C06-home
Control Structures
Data Sources
Data Structures
Data Type Characteristics
Data Types
Essential Terms
Functions and Methods
GUI and Controls
Instructions and Operators
Local and Global Variables
OOP Concepts
C07
C07-home
Essential Terms
Internal Documentation
Naming Conventions
Validation Techniques
C08
C08-home
Contingency Planning
Debugging with Breakpoints in Godot
Debugging with Tetris
Essential Terms
Godot Debugging Tools
Modifying Designs with Annotations
Software Testing Hierarchy
Testing Tables and Corrections
Types of Test Data
Updating Evaluation Criteria
C09
Beta Test Execution
Beta Testing Case Study Pocket Prep
Beta Testing Plan Example Godot Tetris
Beta Testing Plan Template
Beta Testing Plan Three Levels
Beta Testing Report Examples
Beta Testing Report Guide
C09-home
Data Collection Examples
Data Collection Methods
Data Collection Template
Essential Terms
Priority Matrix
Software Modifications Mindmap
Test Scenario FitTrack
Test Scenario Template
The Four-Step Beta Testing Journey
Timeline and Resource Considerations
C10
C10-home
Development Process Portfolio
Essential Terms
Future Evaluation Strategy
Project Plan Effectiveness
Reading a Git Log
Recording Project Progress
Tracking Plan Changes
C2 and C3 Assessment Explained
C4 Design Ideas and Evaluation Explained
Resources
C01-Resources
C02-Resources
C03-Resources
C04-Resources
C05-Resources
C06-Resources
C07-Resources
C08-Resources
C09-Resources
C10-Resources
SAT-Tools
Test-Excalidraw-Embed
U4O2 Cyber Security — Booklet 1 Videos
VCE Software Development Hub
An Otter Wiki
sd
Page Index - sd
Toggle page headings
C
C01
AI Disclosure
Why disclose?
What to log
The AI-first workflow
At validation: where authenticity is tested
Common mistakes
See also
C01-home
Foundations
Key concepts
Other C01 material
Resources
Critical Path
Start with a Gantt chart
The critical path — the bottleneck
Finding it by eyeball
Why the other tasks aren't on it
The rule
Why it matters at validation
Go deeper — the maths
See also
Essential Terms
Problem-solving methodology
Design brief
Project management
Gantt chart
See also
Mr Chen's SAT GitHub Projects
Watch (≈ video)
What to notice
See also
Overflow
Extension: Feasibility Deep Dive (T.E.L.O.S.)
Extension: Comparative Brief Analysis
Extension: Mock Interview (Peer)
Extension: Risk Register
Alternative: Hand-Drawn Gantt Chart
Alternative: Design Brief as a Pitch
Ongoing: AI Disclosure Log Prompts
Problem-Solving Methodology
The four stages
Analysis
Design
Development
Evaluation
Why this matters at validation
See also
Roadmap View vs Gantt Chart
Watch first (3 min)
Side-by-side: what you get vs what you still need to add
What Roadmap View gives you automatically
What Roadmap View does NOT render
Why VCAA cares
How to close the gap
See also
TELOS Feasibility
What T.E.L.O.S. means
Technical
Economic
Legal
Operational
Scheduling
How to write it in your brief
Common mistakes
Further viewing
See also
Testing vs Validation vs Evaluation
The three at a glance
Testing
Validation
Evaluation
Why it matters at validation
See also
C02
Building Your C2-1 Poster
1. Poster structure — the five required sections
2. What labelling actually looks like
3. Findings → SRS mapping
4. Station defence — what the teacher is listening for
Check Your Understanding
See also
C02-home
Start here
Topics — Data collection (C2-1)
Topics — Analytical diagrams (C2-2)
Resources
Context Diagram vs Data Flow Diagram
Watch first (≈8 min)
Side-by-side: the two diagrams compared
The most common mistakes
A mental check before you submit
See also
Context Diagram
Watch first (≈5 min total)
Why a context diagram
The three elements
Worked example: Sales Order System
How to draw one
Check Your Understanding
See also
Data Collection Methods
The big picture
The four methods at a glance
1. Interview
2. Survey
3. Observation
4. Reports / existing data
Qualitative or quantitative?
Choosing your mix
Check Your Understanding
See also
Data Flow Diagram
Watch first (≈10 min total)
Why a DFD / what it shows
The four elements
Worked example: Sales Order System
How to draw one
Check Your Understanding
See also
Essential Terms
Data collection
Context diagrams and DFDs
Use case diagrams (UML)
See also
Excalidraw Diagram Starters
Watch first (≈3 min)
Why consistent notation matters
Getting started in Excalidraw
Skeleton: Context Diagram
Skeleton: Level-1 Data Flow Diagram
Skeleton: Use Case Diagram
Practice check — before the hand-drawn validation
See also
Explaining vs Describing Your Data Collection
The rubric in plain language
Side-by-side: same plan, two different bands
7–8 version (describing)
9–10 version (explaining)
The formula for an "explaining" sentence
See also
Hand-Drawing Cheat-Sheet
Context Diagram — Symbol Reference
Shape key
Right vs Wrong — Context Diagram
Canonical shape — mermaid
Level-1 DFD — Symbol Reference
Shape key
Right vs Wrong — Level-1 DFD
Canonical shape — mermaid
Use Case Diagram — Symbol Reference
Shape key
Right vs Wrong — Use Case Diagram
Canonical shape — mermaid
Arrow Direction Memory Aid
Before You Flip the Paper — Final Check
Check Your Understanding
See also
Use Case Diagram
What it shows
The three building blocks
Worked example: simplest possible UCD
Worked example: a multi-actor system
The four relationships
1. Association (actor ↔ use case)
2. Generalisation (actor → actor, or use case → use case)
3. Include (use case → use case, always required)
4. Extend (use case → use case, optional)
How to draw one (the reliable order)
Check Your Understanding
See also
User Stories and MoSCoW
Watch first (≈3 min)
The three-part formula
Breaking down each part
The role
The goal
The benefit
Common mistakes
Acceptance criteria
MoSCoW priority matrix
Must Have
Should Have
Could Have
Won't Have
A worked example
From user stories to data collection
User stories in your SRS
MoSCoW and your SRS scope statement
Check Your Understanding
See also
What Is an Entity
The VCAA definition
Types of entity — with examples
A quick test: is it an entity?
User stories → entities: the reliable method
Going further: Gherkin scenarios (optional but excellent)
See also
C03
Analytical Tools Template Guide
Don't redraw — refresh and reference
The four-part documentation pattern
Per-tool descriptive tables
Use Case Diagram (UCD)
Context Diagram (CD)
Data Flow Diagram (DFD)
Traceability Matrix
Common mistakes at this checkpoint
Why VCAA cares
See also
C03-home
Foundations
Start here
Key concepts
Resources
Essential Terms
The SRS
Requirements
Constraints
Solution boundaries and scope
Quality words used in non-functional requirements
See also
Evaluating Your Own Questions
What the table looks like
Worked evaluation table — one High, one Medium, one Low
Why these ratings?
What viva examiners look for (verb-laddered categories)
The most common mistakes
Why VCAA cares
See also
Functional vs Non-Functional Requirements
Watch first (≈5 min)
The one-sentence rule
Side-by-side: same project, both types
Functional requirements (what it does)
Non-functional requirements (how well it does it)
The most common mistakes
Mistake 1: Performance targets under functional requirements
Mistake 2: Features buried under non-functional requirements
Mistake 3: Vague non-functional requirements
The categories of non-functional requirements
Why VCAA cares
See also
Scope vs Constraints
The one-sentence rule
The key distinction
Side-by-side: same project, two tables
Scope table (MoSCoW)
Constraints table
The test: budget as constraint, not scope
MoSCoW and constraints work together
Why VCAA cares
See also
Technical Environment — Five Categories
The five categories
One-word entry vs complete entry
Hardware — example
Software — example
Network — example
Data — example
Security — example
Rubric language at each band
Common mistakes
Why VCAA cares
See also
C04
Activity - Hot Cross Bun Matrix
The challenge
Step 1 — Read CHOICE's matrix
Check Your Understanding
Step 2 — What is your matrix built for? (your SRS)
Step 3 — Taste blind, score independently (Validation)
Step 4 — Crown the winner (Validation)
Step 5 — Decide what to develop further (Validation)
Your scoring sheet
Why this matters
See also
Brainstorming
What makes a good brainstorm
How to run yours
StudyStreak example
Common mistakes
Your turn
Check Your Understanding
See also
C04-home
Foundations
🎬 Walkthrough videos
Checkpoints
Key concepts
Resources
C4-1 Checkpoint - Design Pack
What you submit
Annotations are what move you up the bands
What 100% looks like
Am I ready? — checkpoint self-check
See also
C4-2 Checkpoint - Evaluation Matrix
What you submit
A good criterion = name + link + measure
Building the matrix
What 100% looks like
Am I ready? — checkpoint self-check
See also
CHOICE Headphones - Spotting Efficiency and Effectiveness
Quick recap
CHOICE's six criteria, re-tagged
The teaching point — and the warning
Check Your Understanding
Where this leads
Design Sketches
What is a design sketch?
Keep it low-fi
Annotations are what earn the marks
Tools
Your turn
Check Your Understanding
See also
Designing an Evaluation Matrix
Start by taking a great matrix apart
The seven design decisions
Watch: CHOICE evaluates hot cross buns (1 min)
Worked example — choosing a Python IDE
Stress-test your matrix
The quality factors are a menu, not a matrix
Connection to your SAT
Practise
See also
Efficiency vs Effectiveness
The one-sentence rule
Side-by-side scenario
Check Your Understanding
The evaluation matrix — where this matters
Why VCAA cares
See also
Essential Terms
Ideation techniques
Design ideas
Convergent and divergent thinking
Evaluation criteria
See also
Evaluation Criteria and the SRS
The rule
A concrete counter-example
Floating criteria (wrong)
SRS-anchored criteria (right)
How to derive criteria from your SRS
Why VCAA cares
Checklist before submitting your evaluation matrix
See also
Evaluation vs Testing
The one-sentence rule
A concrete example
The most common mistakes
Mistake 1: Treating testing as evaluation
Mistake 2: Writing evaluation criteria that are just test cases
Mistake 3: Inventing criteria that float free of the SRS
Why VCAA cares
See also
Mind Mapping
What it is, and why
How to build one
StudyStreak example
Your turn
Check Your Understanding
See also
Mood Boards
What is a mood board?
Why bother?
Watch and build alongside (10 min)
⏸ Pause and build
Check Your Understanding
Worked example — "StudyStreak"
What we deliberately avoided — and why
Your turn
Credits — this page's example board
See also
C05
Annotated Mock-up in Excalidraw
What an annotated mock-up needs
Setting up the template in Excalidraw
Step 1 — Open a new file
Step 2 — Draw the screen frame
Step 3 — Place UI components
Step 4 — Add the annotation zone
Step 5 — Add callout arrows
Step 6 — Write annotation text
Standard annotation structure (copy and fill in)
Saving your template
Common mistakes
See also
C04 to C05 - Choose then Detail
The one-sentence rule
One picture
Side-by-side
The trap
Check Your Understanding
See also
C05-home
Foundations
C5-1 — Design tools
C5-2 — Design principles & UX
C5-3 — Critical & creative thinking
Templates and scaffolds
Resources
Connect the Dots
Level 1 — Annotate your designs
Level 2 — Link to your SRS requirements
Level 3 — Trace through to detailed designs
Performance ladder
Quick checklist
Check Your Understanding
See also
Creative Thinking for Your Godot Project
Move 1 — Diverge before you converge
Move 2 — Grey-box prototype to test a design idea
Move 3 — Remix and combine
Move 4 — Use a constraint as a creativity engine
Move 5 — Design the "game feel"
Move 6 — Stand on the Godot ecosystem's shoulders — creatively
Move 7 — Document your pivots
Capture it for your folio
Check Your Understanding
See also
Data Dictionary
When do you use a data dictionary?
Video 1 — What is a data dictionary?
The headings to include
A worked example
"Data format" is not "data type"
Video 2 — Data dictionaries in code
The VCAA levels
Activity — your turn
Common mistakes
Mistake 1: Format = Type
Mistake 2: Missing data sources at Level 7
Mistake 3: Vague sizes
Check Your Understanding
Extension — a data dictionary you can play with
Credits
See also
Design Principles vs UX Characteristics
The two lists, side by side
What VCAA asks for at each band
The slot-five validation trap
Common mistakes
Mistake 1: "UX" as a catch-all
Mistake 2: Listing design principles under UX and vice versa
Mistake 3: Describing usability once and assuming you have covered both lists
See also
Design Principles
The seven principles at a glance
How to apply each principle
🎬 Watch — the principles in action
Check Your Understanding
See also
Essential Terms
Design tools
Design principles
UX characteristics
Usability and accessibility
Evaluation words
Thinking styles
See also
From SRS to Detailed Designs - Data and Logic
The four tools are one design
Fully worked: "computed, never stored", through all four tools
Tool 1 — Data dictionary: a separate section for what is not stored
1. Criteria (CRITERIA)
2. Band scale (BANDS, BAND_LABELS)
4. Student record (MOCK_STUDENTS → one markdown file per student in Sprint 2)
5. Derived values (computed, never stored)
Tool 2 — Object descriptions: stored is an attribute, derived is a method
The same class as an object description table
Tool 3 — Pseudocode: how the derived value is actually computed
Tool 4 — IPO charts: it can recompute live because nothing is stored
Each tool, anchored to a requirement (your turn to finish each)
Data dictionary ← FR2 + SRS §7
IPO charts ← the context diagram
Pseudocode ← FR5 + corrections 06/07
Object descriptions ← the problem domain
Your turn — trace validation_gap through three tools
The real files
Check Your Understanding
See also
From SRS to Detailed Designs - Mock-ups
The chain in one picture
Trace 1 — FR3, fully worked
Trace 2 — FR9, with the guidance faded
Trace 3 — FR6, your turn
The real files
Check Your Understanding
See also
IPO Charts - Process Means Steps
The core rule
Video 1 — What is an IPO chart?
Check Your Understanding
The big idea: from DFD to IPO
(template) Name of the process
DFD process: Get Input
DFD process: Initialise Stored Credentials
DFD process: Validate User
Wrong vs Right
Common mistakes
Mistake 1: Process that copies the Output
Mistake 2: Missing the decision branches
Mistake 3: Inputs not traced to the DFD
Mistake 4: One IPO chart for everything
Check Your Understanding
Credits
See also
Object Descriptions and Class Diagrams
Reading a class diagram
The notation you need
Object descriptions — the written form
Example 1 — Animal and Dog
Example 2 — a Skill made of effects ("object descriptions about skills")
Properties, methods — and events
How it connects to your other design tools
Common mistakes
Mistake 1: An object description with no methods
Mistake 2: No visibility or data types
Mistake 3: Classes drawn with no relationships
Mistake 4 (Level 9): A class diagram but no method pseudocode
Check Your Understanding
Credits
See also
Plan B Contingency Table
The template
How to fill it in
What makes a good Contingency / Backup design entry
What makes a good Impact if triggered entry
Completed example (ClubTracker project)
Adding your own risks
See also
Plan B Ready
Identify design risks
Document contingency plans
Show the backup designs
Performance levels
Quick checklist
Check Your Understanding
See also
Shoulders of Giants
Why look at existing solutions?
What counts as an existing solution?
Analyse each solution in a table
Connect findings to your design
Performance levels
Quick checklist
Check Your Understanding
See also
Sketch vs Mock-up
What each one is
The progression: sketch → mock-up
🎬 Watch
Video 1 — Wireframe vs Mockup vs Prototype
Video 2 — Excalidraw in practice
For Level 9: completeness matters
Common mistakes
Mistake 1: Submitting a sketch and labelling it a mock-up
Mistake 2: A polished screen with no annotations
Mistake 3: Only the main screen
Mistake 4: Annotations that only describe
Check Your Understanding
See also
The Annotation Verb Ladder
The four rungs
The same entry, rewritten four times
The 6-slot structure
Build the design log NOW
Common mistakes
Mistake 1: Notes that stay at "identify"
Mistake 2: No journal entry reference
Mistake 3: Describing the feature instead of the principle
🎬 Watch
Check Your Understanding
See also
UX Characteristics
Affordance
Interoperability
Security
Three ways security is getting more usable
Usability
Everyday example — the ketchup bottle
Check Your Understanding
See also
VCAA Pseudocode Not Python
🎬 What is pseudocode?
The two rules that actually matter
Pseudocode ↔ Python comparison
Program structure and basics
Selection
Iteration
Operators
Subprograms (methods / functions / procedures)
Worked example 1 — a method inside a class
Worked example 2 — one algorithm, any machine
Common mistakes
Mistake 1 — Using = or == for assignment
Mistake 2 — Using != for not-equals
Mistake 3 — Python-only constructs leaking in
Mistake 4 — Forgetting closing keywords
Mistake 5 — Inconsistent block keywords
Check Your Understanding
Credits
See also
C06
C06-home
Foundations
Using these pages for your checkpoint
How the codes work
Reasoning-verb ladder (internal documentation codes)
Code → page lookup
Example code
Control Structures
C625 — Sequence
C626 — Selection
If
If … Then … Else (chained selection)
Switch or Case (match)
Myki example
C632 — Iteration / repetition
While …
Do … While
Repeat … Until
For … Next
For … In
Myki example
Check Your Understanding
Data Sources
The three sources
TXT in Godot
CSV in Godot
XML in Godot
C644 — Uses appropriate types, structures and sources
C645 — Why these data sources
C657 and C658 — Range, and the full explanation
Check Your Understanding
Data Structures
C635 — Arrays
C636 — Records
C638 — Why these types and structures
Check Your Understanding
Data Type Characteristics
Data Types
C613 — Text data
Character
String
C614 — Numeric data
Integer
Floating point
C615 — Boolean data
Spot them in a studied project
Date/time
C629 — Why these data types
Check Your Understanding
Essential Terms
Language and execution
Operators
Control structures
Variables and constants
Data types
Data structures
Data sources
Functions and methods
OOP features
See also
Functions and Methods
C641 — Functions
C642 — Methods
Check Your Understanding
GUI and Controls
C627 — Graphical user interfaces
C633 — Relevant GUI controls
Check Your Understanding
Instructions and Operators
C611 — Instructions
C612 — Arithmetic operators
C623 — Logical operators
C624 — Conditional operators
Check Your Understanding
Local and Global Variables
C621 — Local variables
C631 — Global variables
C622 — Constants
C628 and C634 — choosing the right data type
Check Your Understanding
OOP Concepts
C651 — Classes and C652 — Objects
C653 — Abstraction
C654 — Encapsulation
C643 — Access modifiers
C655 — Generalisation
C656 — Inheritance
Check Your Understanding
C07
C07-home
Foundations
Using these pages for your checkpoint
How the codes work
Quality qualifiers decide the band
Code → page lookup
C6 → C7 synergy
Example code
Essential Terms
Naming conventions
Internal documentation
Validation techniques
See also
Internal Documentation
C712 — Identify the functioning
C722 — Outline the functioning (header comment)
C732 — Describe the functionality
C733 — Describe the use of data
C734 — Evidence of code maintenance
C742 / C743 / C744 — Explain (the why)
C752 — Explain everything, clear and concise
Check Your Understanding
Naming Conventions
The Godot house convention
C711 — Identify your convention
C721 — Variables
C731 — Interface controls
C741 — Code structures
C751 — All solution elements
Check Your Understanding
Validation Techniques
C713 — Identify the inputs
C723 — Existence check
C724 — Type check
C725 — Range check
C735 and C745 — The checks working together
C753 — All inputs, plus reasonableness and completeness ✍️
Check Your Understanding
C08
C08-home
Foundations
Pages
Rubric at a glance
Contingency Planning
What a contingency table looks like
The 4-step analysis
Success tips
Debugging with Breakpoints in Godot
What a breakpoint does
The workflow
Check the Locals window (most important)
The detective loop
Try this now (5 minutes)
Debugging with Tetris
Setup (once)
The three exercises
The loop these exercises teach
Essential Terms
Debugging techniques
Alpha testing
Test cases, test data, expected results
Error types
Design modifications
See also
Godot Debugging Tools
Print debugging — the "debugging statements"
The Debugger panel
Breakpoints
Two more worth knowing
Watch
Modifying Designs with Annotations
Ideation vs representation
The five design representations you can modify
What a good annotation shows
The change log
The causal chain (where 7–8 lives)
Software Testing Hierarchy
The hierarchy
Alpha vs beta
Check Your Understanding
Testing Tables and Corrections
The structure
A worked slice
Rules that keep the table honest
Going further — automated tests
Types of Test Data
The six types
Story 1 — the age checker
Story 2 — the GPA calculator (practice)
Updating Evaluation Criteria
The factors (VCAA)
Three steps
Four levels of evaluation matrix
C09
Beta Test Execution
Running Your Beta Test Session
Before the Session
During the Session
Collecting Data As You Go
After Each Session
Scaling Up: What the Criteria Expect
Quick Evidence Checklist
Beta Testing Case Study Pocket Prep
About Pocket Prep (Real Company)
Their Beta Testing Approach (Source: Usersnap case study)
Who Tests Their Apps?
How Do They Collect Feedback?
How Long Does Beta Testing Take?
Types of Feedback They Get (Source: Usersnap case study)
Real Examples from Their Testing:
Real Results from Their Beta Testing (Multiple sources)
Verified Success Metrics:
Their Approach Results:
How They Know Beta Testing Is Complete (Pocket Prep β-test case study, Usersnap)
Lessons for Student Projects (Practical Applications)
What Pocket Prep's Success Shows:
Adaptations for Student SATs:
References
Beta Testing Plan Example Godot Tetris
Beta Testing Plan For:
1. Objective
2. Test Scenarios
Scenario 1 — Appearance Testing: "Can you read the board?"
Scenario 2 — Functionality Testing: "Do the mechanics do what players expect?"
Scenario 3 — User Experience Testing: "A full versus match, cold"
3. Potential Users
4. Methodology
User Recruitment:
Data Collection Methods:
How Results Will Be Collected:
Data Validation Methods:
5. Timeline
6. Resources
Hardware/Software Requirements:
Support Materials for Users:
7. Success Criteria
Primary Success Measures:
User Satisfaction Targets:
Decision Framework:
Quality Checklist
Beta Testing Plan Template
1. Objective
2. Test Scenarios
Scenario 1 - Appearance Testing:
Scenario 2 - Functionality Testing:
Scenario 3 - User Experience Testing:
3. Potential Users
4. Methodology
User Recruitment:
Data Collection Methods:
How Results Will Be Collected:
Data Validation Methods:
5. Timeline
6. Resources
Hardware/Software Requirements:
Support Materials for Users:
7. Success Criteria
Primary Success Measures:
User Satisfaction Targets:
Decision Framework:
Quality Checklist
Next Steps After Planning:
Beta Testing Plan Three Levels
Learning Focus: Creating professional beta testing plans at your skill level
Quick Start Guide: Choose Your Path
🎯 What Am I Doing?
📋 Which Level Should I Choose?
🟢 Level 1: Simplified Plan (20-30 minutes)
🟡 Level 2: Analyse an Expert Plan (40-50 minutes)
🔴 Level 3: Create Professional Plan (50+ minutes)
🚀 Ready to Start?
🟢 Level 1: Simplified Beta Testing Plan
🟡 Level 2: Exemplar Analysis
Expert Beta Testing Plan for EasyRetail:
Analysis Questions: (Answer all questions)
🔴 Level 3: Independent Professional Plan
Learning Reflection Questions
After completing your beta testing plan:
Differentiated Assessment Options
🟢 Foundation Achievement:
🟡 Developing Achievement:
🔴 Advanced Achievement:
Key Knowledge Development
By Priority:
Success Indicators
Students demonstrate learning when they:
Beta Testing Report Examples
Understanding Beta Testing Results
Beta Test Results Framework
1. 🪲 Bug Reports
2. 💡 Feature Requests
3. 🔍 Usability Feedback
4. ⚡ Performance Issues
5. 💬 User Satisfaction
Priority Ranking for Modifications
Student Template for Each Category
Remember for Your SAT:
Beta Testing Report Guide
📋 How to Use This Guide
The 5-Category Results Framework
Use Only the Categories Relevant to Your Testing
Basic Report Template
Beta Test Results for: [Your Software Name]
🪲 Bug Reports
💡 Feature Requests
🔍 Usability Results
⚡ Performance Results
💬 User Satisfaction Summary
Summary of Key Findings
🧾 Evidence Reminder
Success Checklist
Before You Submit:
Good vs. Poor Examples
✅ Good Example:
❌ Poor Example:
C09-home
How C9 runs
Foundations
Stage 1 — Plan (C9-1)
Stage 2 — Conduct (C9-2)
Stages 3 & 4 — Analyse and Recommend (C9-3, C9-4)
Data Collection Examples
CodeCenter
Formuiz
Zonka
Data Collection Methods
Understanding Data Types for Beta Testing
Four Main Data Collection Methods
1. Surveys/Questionnaires
2. Observation
3. Interviews
4. Reports/Documentation
Data Analysis Strategy
Mixing Methods for Comprehensive Results
Data Collection Template
Beta Testing Feedback Forms
1. Bugs / Issues / Problems
Summary
Which feature are you experiencing an issue with?
Steps to Reproduce
Issue Related Files
Severity
Status (For internal use - not filled by testers)
Is this issue stopping you from testing this feature?
2. Ideas / Feature Requests
Summary
Which feature is this idea related to?
Description
Priority
Related Files
Status (For internal use - not filled by testers)
3. Praise
Summary
Which feature is this idea related to?
Tell us about the specific experience you feel is praise-worthy
Praise Significance
Status (For internal use - not filled by testers)
Beta Tester Information
Essential Terms
Priority Matrix
📊 Performance Level Matrix
📈 Beta Testing Progression Pathway
📅 Sequential Focus Strategy
✅ Evidence Checklist by Topic
C-9-1 (Beta Testing Plan)
C-9-2 (Testing Execution)
C-9-3 (Results Documentation)
C-9-4 (Recommendations)
🎯 User Engagement Strategy
User Selection Criteria:
Data Collection Methods (Choose 3+):
📋 Flexible Checkpoint Questions
End of Phase 1:
End of Phase 2:
End of Phase 3:
🔄 Risk Mitigation Strategies
Software Modifications Mindmap
Test Scenario FitTrack
Fitness App Beta Testing Scenario
Background Context
The FitTrack Pro App
Recent Development
Target Users
Beta Testing Plan Overview
Objective
Key Features to Test
Test Scenario: Tracking a Morning Jog
Pre-Test Setup
Phase 1: Preparation
Phase 2: Starting the Activity
Phase 3: During the Jog
Phase 4: Ending the Activity
Phase 5: Post-Exercise Review
Expected Outcomes
Quantitative Success Measures
Qualitative Success Measures
User Experience Targets
Feedback Collection Framework
Real-Time Feedback (During Exercise)
Immediate Post-Exercise Feedback (5 minutes post)
Detailed Analysis Feedback (15 minutes post)
Follow-Up Feedback (24 hours later)
Critical Evaluation Points
Technical Performance
User Experience Quality
Competitive Analysis
Risk Factors and Mitigation
Environmental Risks
Technical Risks
User Experience Risks
Success Indicators for Beta Testing
Immediate Success (Test Day)
Short-Term Success (1 week)
Long-Term Success (1 month)
Learning Applications for Students
C9-1 Planning Skills
C9-2 Execution Skills
C9-3 Documentation Skills
C9-4 Recommendation Skills
Extended Activities for Students
Activity 1: Scenario Adaptation
Activity 2: Data Collection Design
Activity 3: User Selection Rationale
Activity 4: Modification Recommendations
Assessment Connections
C9-1 Preparation Excellence
Professional Standards
Real-World Application
Test Scenario Template
Scenario Objective
Primary Goal:
User Context
Beta Tester Profile:
Pre-Scenario Setup:
Detailed User Journey
Step 1: Preparation Phase
Step 2: Starting Activity
Step 3: During Activity
Step 4: Ending Activity
Step 5: Post-Activity Review
Data Collection Plan
Real-Time Data Collection:
Post-Scenario Data Collection:
Specific Feedback Questions
Targeted Questions for This Scenario:
Comparison/Validation Methods:
Success Criteria
Scenario Success Indicators:
Failure Indicators:
Expected Outcomes
What Should Happen:
Potential Issues:
Integration with Main Beta Testing Plan
Connection to Overall Testing:
Documentation Integration:
The Four-Step Beta Testing Journey
STEP 1: Planning and Preparation
STEP 2: Conducting Beta Testing
STEP 3: Results Documentation
STEP 4: Recommendations and Evaluation
External User Engagement Strategy
User Selection and Recruitment:
Engagement Approaches:
Data Collection Methods (Multiple Required):
Critical Success Factors
Organisation and Planning:
Timeline and Resource Considerations
Pre-Testing Phase (2-3 weeks):
Testing Phase (1-2 weeks):
Post-Testing Phase (1 week):
Key Progression Indicators
C10
C10-home
How C10 runs
Foundations
C10-1 — Evaluating the solution
C10-2 — Evaluating the analysis, design and development stages
C10-3 — Documenting the modifications to your project plan
C10-4 — Assessing the effectiveness of your project plan
Development Process Portfolio
What is this?
📖 Write Your Development Story
Think Case Study, Not Checklist
🎯 Story Structure (C10-2)
Stage 1: Analysis - "What I discovered about the problem"
Stage 2: Design - "How I planned the solution"
Stage 3: Development - "How I built the solution"
Stage 4: Evaluation - "How PSM helped me succeed"
📁 Portfolio Format Ideas
Timeline-Based Story:
Visual Case Study:
Problem-Solution Journey:
Decision Tree Format:
📊 Evidence + Reflection Template
✨ Pro-tips:
🎯 Remember:
Check Your Understanding
Essential Terms
Topics:
Future Evaluation Strategy
🎯 Required Components (C10-1)
1. Time Frame - When will the evaluation happen?
2. Evaluation Criteria - What will be measured?
3. Individuals - Who will do the evaluation?
4. Responsibilities - Who does what?
📝 Simple Template
Future Evaluation Strategy for [Your Software Name]
✨ Pro-tip:
🚫 Don't Overthink It
Check Your Understanding
Project Plan Effectiveness
What is this?
🎯 Reflection Framework (C10-4)
Optional: Build on milestone mini-retrospectives
Your final reflection should answer:
💭 Use Simple Reflective Thinking:
📝 Reflection Structure
1. Overall Plan Assessment - "How effective was my plan?"
2. Effectiveness Factors Analysis - "What worked and what didn't?"
✅ What Made the Plan Effective:
❌ What Made the Plan Less Effective:
3. Change Impact Analysis - "How did modifications affect completion?"
4. Planning Approach Evaluation - "What does this reveal about my planning effectiveness?"
📋 Simple Reflection Template
Project Plan Effectiveness Reflection
✨ Pro-tips:
🎯 Remember:
Check Your Understanding
Reading a Git Log
The two commands
What the shape of a log tells a marker
Log A — six commits
Log B — seventeen commits
Log C — forty-three commits
Check Your Understanding
Recording Project Progress
Task Overview
Scenario
Your Task
1. Annotations to Project Plans
2. Adjustments to Tasks
3. Monitoring Progress Using Logs/Journals
Deliverables
Success Criteria
Reflection Questions
Real-World Connection
Tracking Plan Changes
What is this?
🎯 Choose Your Tracking Method
Option 1: Traditional Approach
Option 2: GitHub Approach
📊 Annotated Gantt Chart Guide
What to Show:
How to Annotate:
Traditional Method (GanttProject/Excel):
GitHub Projects Method:
📝 Project Logs Guide
What to Track:
Log Categories:
💭 Add Reflection Checkpoints:
📸 Include Evidence Annotations:
Option 1: Traditional Log File
Simple Log Template:
Option 2: GitHub Issues Method
Issue Structure:
GitHub Projects Benefits:
⚠️ Don't Forget the Meta Log:
📋 Documentation Checklist
Check Your Understanding
C2 and C3 Assessment Explained
1. Data Collection — C2-1
2. Analytical Diagrams — C2-2
3. SRS (Software Requirements Specification) — C3-1
4. Think Data — C3-2
Related pages
C4 Design Ideas and Evaluation Explained
1. Design Ideas — C4-1
2. Evaluation Criteria — C4-2
Related pages
R
Resources
C01-Resources
C1-1: Design Brief
Existing Materials (CriterionXX/)
External Resources
Gaps — C1-1
C1-2 & C1-3: Project Plan (Gantt Chart) & Planning Detail
Existing Materials (CriterionXX/)
External Resources
Gaps — C1-2 & C1-3
Recommended Actions
C02-Resources
C2-0: General Foundations
External Resources
C2-1: Data Collection
Existing Materials (CriterionXX/)
External Resources
Gaps — C2-1
C2-2: Analytical Diagrams
Existing Materials (CriterionXX/)
External Resources
Wiki pages for C2-2
Gaps — C2-2
Recommended Actions
C03-Resources
C3-1: SRS Document
Existing Materials (CriterionXX/)
External Resources
Wiki pages for C3-1
Gaps — C3-1
C3-2: Critical Thinking
Existing Materials (CriterionXX/)
External Resources
Gaps — C3-2
Recommended Actions
C04-Resources
C4-1: Design Ideas & Annotations
Existing Materials (CriterionXX/)
External Resources
Gaps — C4-1
C4-2: Evaluation Criteria
Existing Materials (CriterionXX/)
External Resources
Wiki pages for C4-2
Gaps — C4-2
Recommended Actions
C05-Resources
C5-1: Design Tools
Existing Materials (CriterionXX/)
External Resources
Gaps — C5-1
C5-2: Design Principles & UX
Existing Materials (CriterionXX/)
External Resources
Wiki pages for C5-2
Gaps — C5-2
C5-3: Critical & Creative Thinking
Existing Materials (CriterionXX/)
External Resources
Gaps — C5-3
Recommended Actions
C06-Resources
C6-1: Programming Language Features
Existing Materials (CriterionXX/)
External Resources
Gaps — C6-1
C6-2: Data Types, Structures & Sources
Existing Materials (CriterionXX/)
External Resources
Gaps — C6-2
Recommended Actions
C07-Resources
C7-1: Naming Conventions
Existing Materials (CriterionXX/)
External Resources
Gaps — C7-1
C7-2: Internal Documentation
Existing Materials (CriterionXX/)
External Resources
Gaps — C7-2
C7-3: Validation Techniques
Existing Materials (CriterionXX/)
External Resources
Gaps — C7-3
Recommended Actions
C08-Resources
C8-1: Testing & Debugging
Existing Materials (CriterionXX/)
External Resources
Gaps — C8-1
C8-2: Design Modifications & Contingencies
Existing Materials (CriterionXX/)
External Resources
Gaps — C8-2
Recommended Actions
C09-Resources
C9-1 to C9-4: Beta Testing (Plan, Conduct, Results, Modifications)
Existing Materials (CriterionXX/)
External Resources
Gaps
Recommended Actions
C10-Resources
C10-1 to C10-4: Evaluation & Project Plan Assessment
Existing Materials (CriterionXX/)
External Resources
Gaps
Note
Recommended Actions
SAT-Tools
Markdown — for all written work in your repo
See also
T
Test-Excalidraw-Embed
Approach 1 — Plain markdown link
Approach 2 — Raw HTML <iframe>
Approach 3 — <iframe> inside a fenced HTML block
Approach 4 — <embed> tag
Approach 5 — <object> tag
Notes
U
U4O2 Cyber Security — Booklet 1 Videos
1. How You're Marked: The Verb Ladder
2. The PixelForge Case: A Guided First Read
3. Part A — Goals, Objectives & Sourcing
4. Part B — The Six Security Controls
5. Parts C & D — Ten Risks & a Band-5 Paragraph
What's next
Related pages
V
VCE Software Development Hub
🎬 Assessment videos
🔒 Unit 4 Outcome 2 — Cyber security
SAT (School-Assessed Task) — Checkpoints
Tools
Resources
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
