Project Guide

What a project is, and how NESA describes it

Project work Students apply computing skill domains to project(s) …

NESA's glossary defines a project as an individual or collaborative problem-solving activity undertaken by students that is planned to achieve an articulated aim. In plain words, you plan a project so that you can reach a clear goal and show that you did.

A project can be one activity or a series of activities, done alone or with others. Your teacher decides how big each project is, because your course is 100 or 200 hours long.

NESA's teaching advice for Life Skills lists four computing skill domains that project work can support. A domain is an area of skill:

• Technical knowledge and skills: using hardware, software, data and code well.
• Social awareness skills: thinking about the people your project affects, including people who are different from you.
• Project-management skills: planning, managing time and resources, teamwork and records.
• Thinking skills: computational thinking (breaking a problem into steps), design thinking (starting with what people need) and systems thinking (seeing how the parts connect).

The example is made up. Ava and Jin, a team of two, build a canteen order app so that students can order before they reach the front of the queue.

The design loop: a loop, not a line

Course outcome CT5-DPM-01 applies iterative processes to define problems and plan, design, develop and evaluate computing solutions

NESA's glossary calls the whole process the design and production process. It has four stages. In this guide, a stage is one part of that process, not Stage 4 or Stage 5 at school.

Real projects work better as a loop than as a straight line. You go round more than once, and each time the solution gets closer to what users need. The word iterative means repeated. Each cycle builds towards a better result.

Something has to send you back round. Common triggers are a failed test, a user who finds the solution hard to use, a missing requirement, or a better idea found while you build. A prototype, which NESA's glossary describes as a trial product or model built to test an idea or process, helps the loop start early. A paper sketch of an app screen counts.

Choosing a project idea

Combining focus areas Focus areas can be combined to enable substantial, engaging projects …

A good project starts with a problem you can explain in one sentence. Pick a problem that real people could use or try, and that you can test.

NESA's teaching advice says focus areas can be combined. The table shows four of the pairings it suggests. Each example is made up.

The advice also suggests analysing data with sensors, analysing data with an app, and a robot that is controlled remotely.

Ask four questions before you commit. Can I explain the problem in one sentence? Who will use it? Can I test it? Can I finish it in the time I have? Any project with hardware needs a teacher or adult to supervise it, and should use low-voltage or battery-powered parts, or a simulation.

Defining the problem and the users

Define a real-world problem or need … including breaking it down into manageable parts and describing the users of the solution

A problem statement is one or two sentences that say who has the problem, what it is and why it matters. "Students need a better canteen" is too vague. "Year 8 students at a made-up school queue for too long at recess, so they lose part of their break" can be tested.

A big problem is easier to solve in parts. Decomposition means breaking a complex problem into smaller parts that are easier to understand, design and build. For the canteen, the parts could be: choose items, confirm the order, record it, and show when it is ready.

List your stakeholders, which are anyone affected by the project or able to affect it. Users are one group; others include helpers, teachers and families.

A user profile describes one main group of users, such as Year 8 students who buy food at recess.

Requirements: what the solution must do

Specify the functional requirements … including stating the purpose of a solution, describing use cases and developing test cases of input and expected outputs

A requirement is something the solution must do, or something it must be like. Requirements are your checklist. You will check the finished solution against them, so write them early.

• Functional requirements say what the solution does. Example: "The order screen shows today's menu."
• Non-functional requirements say how well it works. Example: "A student can place an order in under one minute."

A use case describes one thing a user wants to do, and the steps they take. A test case sets out an input and the output you expect. Write it before you build, so you know what success looks like.

Research before you plan

Evaluate existing solutions to the problem or related problems

Research means finding out what you need to know before you design anything. Four common methods are:

• Interview: a short talk with one person. Ask open questions, such as "How do you order at recess now?", not "Do you like the canteen?"
• Survey: a short set of written questions for many people. Do not ask for personal details you do not need.
• Observation: watch someone use a current process, and note where they hesitate, get stuck or give up.
• Existing solutions: look at a product that already does part of the job. Write down what it does well and badly.

Record every source: who you asked or what you read, when, and what you learned. If you record someone's answers, ask their permission first, and do not use their name unless they agree.

Planning: task lists, timetables and boards

Plan and manage a project using an iterative approach

Start with a task list of every job, written in words a stranger would understand. "Interview the canteen manager" is clear. "Phase 1" is not. Then add a time estimate to each task, in lessons, and check the total against the time you have.

A Gantt chart shows each task as a bar along a timeline. A milestone is a point in time, such as "prototype approved", shown as a single marker. The table is a Gantt-style timetable for a made-up six-week project. A filled square means the task is being worked on that week. The milestone sits at the end of week 2.

A Kanban board shows the work in progress at a glance. Each task is a card that moves across three columns: To do, Doing and Done.

Agile methods plan work in short cycles called sprints, such as a block of two lessons. At the end of each sprint, the team reviews the work and decides what to change next. NESA's apps and web software dot points ask students to experiment with agile tools, and a Kanban board and sprints are both agile tools.

Design choices: alternatives and a decision table

Alternative designs Generate alternative designs and evaluate them against the requirements to select a preferred design

Do not settle on the first design you think of. Sketch at least three alternative designs for the same problem. Quick paper sketches are fine.

To compare them fairly, use your requirements as criteria. Give each criterion a weight from 1 (least important) to 3 (most important). Score each design from 1 (poor) to 5 (excellent). Multiply score by weight, then add up each design's results. This is a weighted decision table.

The example compares three made-up ways to take a canteen order. All the scores are made up. Each cell shows the score, with the weighted result in brackets.

Design B has the highest total, so it is the preferred design on these criteria. Check your choice by changing one weight. If the winner changes, say so, and explain why your choice still stands.

Working together: roles, files and feedback

Course outcome CT5-COL-01 manages, documents and explains individual and collaborative work practices

A team works well when everyone knows their job, how they will talk to each other and where the files are. Agree on these things at the start, and write them in a short group work contract that everyone agrees to.

Each person in a team has a role, which is the part of the work they look after. In a team of two, one person can take more than one role. The table is a made-up example for Ava and Jin.

Shared files live in one folder with the same layout for everyone. Numbers at the start keep the folders in order:

canteen-app/
  01-problem/     problem statement, user profiles
  02-research/    interview notes, survey results
  03-plan/        task list, timetable, Kanban board
  04-design/      sketches, decision table
  05-build/       the solution files
  06-testing/     test plan and results
  07-record/      project record

Version names tell you what a saved file is. A name such as order-screen_v03_jin means version 3 of the order screen, last saved by Jin. Never use names such as "final_FINAL_2".

Feedback should be respectful. Comment on the work, not the person. Say what works, name one thing to improve and suggest how: "The buttons are clear. The price is hard to read on a small phone. Could it be bigger?"

Keeping a project record

Create a record of project development demonstrating iterative design and evaluation

A project record is a diary of your work. NESA's dot points also call it a project notebook. Each entry says what you did, what happened, what you decided and why. It shows how the project grew, and it helps you remember why you made each choice.

Write an entry at the end of each work session. Five minutes is enough. Be honest. A record that shows a fault and how you fixed it is good evidence of an iterative process. Copy this template for each entry:

Responsibilities, ethics and cybersecurity checklist

Course outcome CT5-SAF-01 selects and applies safe, secure and responsible practices in the ethical use of data and computing technology

Every project affects people. Before you collect data or build anything, ask who could be affected and what could go wrong. Responsibilities are social (how people are treated), ethical (fair and honest) and legal (the laws that apply). Check the list at the start and before you finish.

The Privacy Act 1988 (Cth) and the Australian Privacy Principles are the main national rules for personal information. NSW public schools also follow NSW privacy law. Ask your teacher which rules apply to your school project.

Test plans: normal, boundary and erroneous data

Validate programs using test cases and debug a range of errors

A test plan is a list of tests written before you run them. For each one it gives the input, the expected output, the actual output and whether it passed. Use three kinds of data:

• Normal data is typical data that should work, such as a name with eight letters.
• Boundary data is data at the edge of what is allowed, such as the smallest and largest numbers accepted.
• Erroneous data is data that should be rejected, such as the word "two" typed into a box for a number.

Run each test exactly as written, and record the actual output even when it matches. If a test fails, fix the solution and run it again. Never change the expected output to make a test pass.

You can also desk check before you run anything. NESA's glossary describes this as a human checking the logic of a program on paper or with a diagram, by trying sample inputs.

Evaluating against the requirements

Evaluate their own project and that of their peers using predetermined functional and non-functional requirements

To evaluate means to judge how well something worked, using clear criteria and evidence. Your criteria are the requirements you wrote at the start. Turn each one into a row of a criteria table.

Every number and result in this table is made up.

Self evaluation means judging your own work with the same table: did I meet each requirement, what is my evidence, and what would I change? Peer evaluation means a classmate checks your work against the same requirements. Ask them to test the work, not only look at it.

• Met: keep it, and write down the evidence.
• Partly or not met: fix the solution and test again, or change the requirement and explain why in your record.
• Never hide a result that did not go well. An honest evaluation is worth more than a perfect one that is not true.

Presenting and communicating your project

Course outcome CT5-COM-01 communicates ideas, processes and solutions using appropriate media

Presenting means explaining your project to other people. A good presentation shows the problem, the solution, how you know it works and what you learned. You can present as a live demonstration, a poster, a short slide talk or a written report.

Before you plan, answer three questions. Audience: who is listening? Purpose: what should they know or do afterwards? Time: how long do you have?

Practise with a timer. Keep a screenshot or short video as a backup, in case the live demonstration does not work on the day. A poster works the same way, in panels: title and problem, design, solution, testing results, and reflection with next steps.