The Four Stages at a Glance
Design and production process Identifying and defining, researching and planning, producing and implementing, testing and evaluating
The stages and what each one leaves behind
The four stage names are NESA’s subheadings for the Year 12 Enterprise Project. Each stage ends with something you can point to. If you cannot point to it, the stage is not finished, however busy you have been. The theory for each stage is on the Enterprise Project page; this guide is about doing the work.
Concept diagram
The project life cycle, with tools and evidence
Four stages, the tools you will use in each, and the evidence each one should leave behind.
What to notice
- The arrows run forwards, but the dashed arrow runs back: test results and client feedback send you to earlier stages.
- Every stage produces documents as well as work. The process diary runs through all four.
Try thisChoose one tool from stage 2 and say which stage 4 activity would show whether it worked.
Stage summary table
| Stage | The question it answers | Main tools | Typical evidence |
|---|---|---|---|
| 1. Identifying and defining | What is the problem, for whom, and how will we know it is solved? | Problem definition, interview or survey, success criteria | Signed-off problem definition, interview notes, list of stakeholders |
| 2. Researching and planning | What will we build, in what order, with what time, money and risks? | Gantt chart, action plan, budget, DFD, system flowchart, storyboard, risk register | Dated plan, design documents, requirements list, feasibility notes |
| 3. Producing and implementing | Are we building what we planned, and how will the client start using it? | Development approach, prototype, implementation plan, process diary | Working versions, diary entries, version history, training and documentation |
| 4. Testing and evaluating | Does it work, and does it meet the criteria we set? | Test plan, test data, client feedback, evaluation table | Test results, evaluation against criteria, maintenance notes, reflection |
Why the cycle repeats
NESA lists an iterative approach as part of managing a project. In practice that means you do not finish stage 1 and never look at it again. A client interview in stage 1 gives you a problem definition; a prototype in stage 3 shows the client something new; they change their mind; and you go back to update the requirements and the plan. This is normal, and a record of it in your process diary is strong evidence that you managed the project rather than just built it.
One-Page Checklists for Each Stage
Use as you go What to produce, which tool to use and what evidence to keep
Tick items as you complete them. The ticks are saved in your own browser (nothing is sent anywhere), so you can come back to this page during the project. Tool names link to the Course Toolkit for NESA’s notation. Your teacher or your school’s task notification decides what is actually required, so treat this as a thorough starting list rather than a rule.
Stage 1: Identifying and defining
| Done | Produce | Tool | Typical evidence |
|---|---|---|---|
| A problem definition: who has the problem, what it is, why it matters and what is out of scope | Problem definition statement | One paragraph that the client has read and agreed | |
| A list of the people involved: client, users, team members, anyone affected | Stakeholder table (roles) | Names, roles and how you will contact each one | |
| Success criteria you can measure, such as “staff can enter an order in under a minute” | Criteria list | A numbered list you will use again in stage 4 | |
| First research into the problem and existing solutions | Interview or survey (templates) | Questions, notes or responses, and what you learned | |
| Constraints: time, money, skills, hardware, software, privacy | Constraints list | A short table that feeds the feasibility check | |
| A chosen development approach with reasons | Approach chooser | Two or three sentences justifying the choice | |
| The first process diary entry | Process diary template | A dated entry, made before you start building |
Stage 2: Researching and planning
| Done | Produce | Tool | Typical evidence |
|---|---|---|---|
| A prioritised requirements list separating needs from wants | MoSCoW table | Requirements the client has seen and agreed | |
| A dated schedule with dependencies and milestones | Gantt chart | The chart, updated as work is done | |
| A time/task action plan for the next few weeks | Action plan template | Tasks, owners, due dates and status | |
| A budget of time, money and resources | Budget template | Itemised costs with a stated contingency | |
| Design documents for the parts of the system that need them | DFD, system flowchart, decision tree, storyboard, data dictionary | Diagrams drawn in NESA notation | |
| A risk register with a response for each serious risk | Risk register template | Risks rated by likelihood and consequence | |
| A feasibility check that the plan can really be delivered | Feasibility checklist | A yes, no or “with changes” for each check, with reasons |
Stage 3: Producing and implementing
| Done | Produce | Tool | Typical evidence |
|---|---|---|---|
| Working versions of the solution, built in planned steps | Your development approach; a prototype where it helps | Dated versions with a version history | |
| Regular check-ins with the client | Meeting notes, feedback log | What the client said and what you changed | |
| Process diary entries at regular intervals | Process diary | Entries covering all eight items NESA lists | |
| An implementation plan with a preferred changeover method | Implementation plan template | Method, dates, responsibilities and a fallback | |
| Training and documentation for the people who will use and maintain it | Training and documentation checklist | A user guide, a quick reference and a training outline | |
| An updated Gantt chart and risk register | Gantt chart (percentage complete), risk register | Actual times beside estimated times |
Stage 4: Testing and evaluating
| Done | Produce | Tool | Typical evidence |
|---|---|---|---|
| A test plan written before testing starts | Test plan template | Tests with expected results worked out in advance | |
| Test results, with failures fixed and retested | Normal, boundary and erroneous data; NESA’s testing methods | A results table with the actual result and a pass or fail | |
| A client trial and their sign-off or list of changes | Acceptance testing | Client comments and your response | |
| An evaluation of the solution and of your own process against the success criteria | Evaluation table | Each criterion judged, with evidence and a next step | |
| Notes on how the system will be maintained and improved | Maintenance notes | Who does what, how often and how a fault is reported | |
| A final reflective entry in the process diary | Process diary | What went well, what you would change, what you learned |
Approach Chooser
Explore and apply Answer five questions about your project to see which approaches fit, and why
This chooser turns the usual rules of thumb into a score. Answer the five questions about your project. Each answer adds points to each approach, and the result explains which of your answers pointed towards the top choice and which ones are a risk you would need to manage. It is a thinking aid built on common project-management advice, not a NESA rule, and real projects often mix approaches. The theory behind each approach is on the Enterprise Project page.
Answer all five questions to see a recommendation.
The Five Approaches Compared
Explore and apply How each approach works, when it fits and when it goes wrong
Side by side
| Approach | How it works | Fits best when | Goes wrong when |
|---|---|---|---|
| Waterfall (structured) | Stages are completed in order: requirements, design, development, testing, installation, maintenance. Each is documented and signed off before the next begins. | Requirements are clear and stable, the client is hard to reach, and a fixed date and scope must be met. | The client changes their mind late. A working system may appear only near the end, so misunderstandings are found late too. |
| Agile | Short cycles (sprints in Scrum) each plan, build, test and review a small working piece. The client gives feedback every cycle and work is taken from a prioritised backlog. | Requirements will evolve, the client can give frequent feedback and the team can adapt the plan. | The client is rarely available, the scope and price must be fixed in advance, or the team drops the planning and records altogether. |
| Prototyping | A quick, cut-down version is built early so users can react to it, then refined or replaced. | Nobody can describe what they want until they see something, especially for screens and workflows. | The prototype is mistaken for the finished product, or the client keeps asking for “one more version” and the project never ends. |
| End-user development | The people who will use the system build or adapt it themselves, using accessible tools such as spreadsheets or simple app builders. | The need is small and specific, the users know their own process best and the budget is tight. | The system grows beyond what the tool can safely do, the builder leaves and nobody understands it, or data security and backups are ignored. |
| Outsourcing | Another organisation, sometimes in another country, is paid to build part or all of the system to an agreed specification. | You lack a key skill, there is budget, and the requirements can be written down clearly. | The specification is vague, communication is slow, or the client loses control of quality, data and the schedule. |
Waterfall and agile in motion
Animated diagram
Waterfall and agile: when does the client get a working system?
The same project delivered two ways, with the amount of working system the client can use shown week by week.
What to notice
- Waterfall delivers everything at the end; agile delivers usable parts along the way.
- A late change is expensive in waterfall and is just the next backlog item in agile.
Choose Waterfall or Agile with the tabs. Step with the arrow buttons or keys, play or pause with Space.
Try thisWhich approach would you want for a system that must be signed off against a written specification? Which for one where the client says “I’ll know it when I see it”?
Process diagram
An agile sprint cycle
A prioritised backlog feeds a short sprint that ends in a working increment, a review with the client and a retrospective.
What to notice
- The client sees working software at every sprint review.
- The retrospective improves how the team works, not only what it builds.
Try thisWrite the first five backlog items for a club booking app, in priority order.
Combining approaches
Real projects rarely use one approach in pure form. A common pattern is a short waterfall-style start (define the problem and agree the scope), agile sprints for the build, and prototyping inside the sprints to test screens with the client. A school project might be end-user built (the club secretary’s spreadsheet) with outsourced help for one difficult feature. Whatever you choose, name it, give the reasons drawn from your own project and state the drawback you are accepting and how you will manage it.
Gantt Chart Walkthrough
Time and resource management Dependencies, milestones, the critical path and percentage complete
Start from the tasks, not the chart
The chart is the last step. First list the tasks in words a stranger would understand (“Interview the canteen manager”, not “Phase 1”), estimate each in days, and ask of every task: what must be finished before this can start? The answers are your dependencies. NESA’s required elements are on the Toolkit Gantt page: self-explanatory task names, estimated times, clearly shown dependencies, a dated time scale and marked milestones. The example below groups a library booking app project under NESA’s four stage names.
Gantt chart
A project plan grouped by stage
Seven weeks of work, in the four stages, with two milestones.
What to notice
- Each task starts when the one before it finishes, shown by the elbow arrows.
- The two milestones (specifications signed off, client evaluation) are points in time, not tasks.
Try thisWhich task would you split into smaller pieces if you wanted to track progress week by week?
The critical path, explained simply
Some tasks can run at the same time; some cannot. Follow the dependencies from the first task to the last and add up the days along each route. The longest route decides the earliest possible finish date. That route is called the critical path: a delay to any task on it delays the whole project. Tasks off the path have float, spare days they can slip without moving the end date. (The critical path is a common project-management technique. NESA’s Course Specifications do not name it, but it explains why some delays matter and others do not.)
Gantt chart
The critical path of a canteen ordering app
Five tasks and a milestone, with the longest chain of dependent tasks in red and one task that has float.
What to notice
- Designing the database (B) takes 3 days and designing the screens (C) takes 5. The build (D) needs both, so it waits for C.
- A, C, D and E add up to 16 days: that is the critical path. B has 2 days of float.
- If B slips by 2 days nothing changes. If C slips by 1 day, the handover moves by 1 day.
Try thisTesting (E) is cut from 3 days to 2. What is the new finish date? Then suppose C grows from 5 to 8 days. Which task is now off the critical path?
Answers
Cutting E to 2 days gives 2 + 5 + 6 + 2 = 15 days. If C grows to 8 days, the route A, C, D, E becomes 2 + 8 + 6 + 3 = 19 days and is still critical, while B (3 days) gets even more float. B never becomes critical unless it grows past the length of C.
Try it
Critical path explorer
Change task lengths and see which tasks are critical and which have float. Enable JavaScript to use this tool. In short: add up the days along each route from the first task to the last, and the longest route is the critical path.
Milestones and percentage complete
- Milestones are decision or delivery points: “Requirements approved”, “Prototype shown to client”, “Testing complete”. Add one at the end of each stage and treat it as a checkpoint: are we really done?
- Percentage complete shows how much of a task is finished. Be honest: count finished work, not time spent. A task is 80% complete when 80% of the work is done, not when 80% of the days have passed.
- Actual versus estimated: NESA says the chart should be updated during development. Keep the original plan and note the actual dates beside it. The differences are the material for your diary reflections and your evaluation.
Keeping the chart alive
- Update the chart at the same time each week, and note the date of the update.
- Move any task that has slipped, then check whether the critical path changed.
- If the end date moves, decide what to do: drop a low-priority requirement (see MoSCoW), add time, or ask the client.
- Record the reason in your process diary.
Time/Task Action Plans
Researching and planning Turning the Gantt chart into what each person does this week
A Gantt chart shows the whole project. An action plan is the short-range view: the tasks for the next week or two, who owns each, when it is due and whether it is done. Keep it beside your Gantt chart, and rewrite it each week from the chart. One task, one owner, one date: if two people own a task, nobody does.
| Task | Owner | Due | Depends on | Status | Notes |
|---|---|---|---|---|---|
| Draw Level 0 DFD for canteen ordering | Ana | Tue 4 Aug | Interview notes | In progress | Check flow labels with the manager |
| Build the Menu and Orders tables | Ben | Thu 6 Aug | Data dictionary | Not started | |
Process Diary: Templates and Good vs Weak Entries
Documenting progress NESA’s eight items, a copyable template and what separates a strong entry from a weak one
The Toolkit lists the eight items NESA says a process diary entry should include. Here is a template you can copy, then a weak and a strong entry for the same afternoon of work. The diary is also your best evidence that the work is yours (see Part 7), so make each entry specific enough that only the person who did the work could have written it.
| Item | Prompt | Your entry |
|---|---|---|
| Date | The day you write it, and the session it covers | |
| Person | Your name (in a team, each member writes their own) | |
| Progress since the last entry | What is different now? | |
| Tasks achieved | Which tasks from the action plan are finished? | |
| Stumbling blocks and how they were managed | What went wrong, how did you find out, what did you do, did it work? | |
| Possible approaches for upcoming tasks | Options for the next step and which you lean towards | |
| Reflective comments | What did you learn? What would you do differently? | |
| Resources used | Software, data, people, websites, tools (including any AI tool and what you used it for) |
Weak entry
Thursday. Worked on the project. Did the database. Had some problems but fixed them. Will do the screens next.
- No name, no session detail, no task named.
- “Some problems” hides the evidence of managing them.
- No options, no reflection, no resources.
Strong entry
Thu 6 August, period 5 – Ben Tran. Since Tuesday I built the Menu and Orders tables and entered five test records (action plan tasks 4 and 5). Prices displayed as 5.5 instead of $5.50, so I changed the field format to $#.## from the data dictionary and re-entered the data. Next I have to choose between a drop-down and option buttons for picking items; I lean towards a drop-down because the manager has 40 items. If I had tested one record before entering five, I would have found the format problem sooner. Used: database software, Ana’s data dictionary, the manager’s menu list.
- Every one of NESA’s eight items is present.
- The problem, the fix and the result are all stated.
- The reflection leads to a change in how the work is done.
Budgets
Researching and planning Costing time, hardware, software, training and ongoing use
A budget is a list of what the project will cost, added up, with a reserve for surprises. For a school project the main cost is time, and it is still worth pricing it, because a real client would be charged for it. Include the costs that come after the build: licences renew, cloud storage is billed monthly and people need training. A budget with only the build cost is a common weakness.
| Item | Type | Basis | Cost ($) |
|---|---|---|---|
| Design and build time | Labour (one-off) | 60 hours at $30 per hour | 1800 |
| Testing and training time | Labour (one-off) | 20 hours at $30 per hour | 600 |
| Tablet for the canteen counter | Hardware (one-off) | Quote from supplier | 450 |
| Database hosting | Ongoing (per year) | $12 per month | 144 |
| Contingency | Reserve | 10% of one-off costs (assumed) | 285 |
| Total for the first year | 3279 | ||
The figures are invented to show the layout. Use real quotes and rates for your own project, and state your assumptions.
In a spreadsheet, use SUM for the total and a formula such as =0.1*SUM(D2:D4) for the contingency so the total updates when a cost changes (see the spreadsheet functions in the Toolkit). A contingency is money or time set aside for things you cannot predict; choose an allowance, say why, and use your risk register to justify it.
Gathering Requirements: Interview and Survey Templates
Applying tools Interviews and surveys to find out what the system must do and what limits it
A requirement is something the system must do or a limit it must respect. Interviews suit a small number of people whose answers you need in depth (the client, a key user). Surveys suit many people and simple answers. The syllabus lists both, with analytical reports, prototypes and presentations of research results (see the Enterprise Project page). Whichever you use, plan the questions in advance and keep a record.
Interview template
| Topic | Open question to ask | What you are trying to learn | Answer and notes |
|---|---|---|---|
| The problem | What is not working now? Can you walk me through the last time it went wrong? | The real problem, in the client’s own words | |
| The users | Who will use it, how often and on what devices? | Users, skills, accessibility needs | |
| The process | What happens from start to finish, and where does data come from and go? | Inputs for a DFD or system flowchart | |
| Must-haves | If it could only do three things, what would they be? | Priorities for the MoSCoW table | |
| Limits | What are the deadline, budget, existing systems and rules we must respect? | Constraints for the feasibility check | |
| Success | How will you know it has worked? | Measurable success criteria | |
| Close | Is there anything I have not asked that I should have? | Missed needs |
Ask open questions (“How do you take an order now?”) rather than leading ones (“You would like an app, wouldn’t you?”). Write your notes up the same day and send a short summary back to the client to confirm you understood.
Survey template
| # | Question | Answer type | Why you are asking |
|---|---|---|---|
| 1 | How often do you buy food from the canteen? | Choose one: never, weekly, most days, every day | Estimate how busy the system will be |
| 2 | How do you usually pay? | Choose one: cash, card, phone, other | Decide which payment options to support |
| 3 | How easy is it to order at recess now? | Rating from 1 (very hard) to 5 (very easy) | Baseline to compare with after the change |
| 4 | What is the one thing you would change? | Short written answer | Ideas you did not think of |
Mix closed questions (easy to count, giving quantitative data) with one or two open ones (richer, qualitative data). Keep it short, test it on two people before sending it out, and record how many people you asked, because a summary is only as good as the sample behind it.
Negotiating Needs and Wants (MoSCoW)
Collaborating and managing criteria Sorting a long wish list into what the system must, should and could do
Clients usually want more than the time and money allow. NESA asks you to negotiate user and client needs and wants. A common technique for doing this is MoSCoW prioritisation. It is a widely used project-management method, not something NESA specifies, and the capital letters spell out the four categories (the lower-case o’s are just there to make a word).
| Category | Meaning | Test |
|---|---|---|
| Must have | The project fails without it | If we deliver everything else but not this, is the system useless? |
| Should have | Important, but there is a workaround for now | Would the client be unhappy but still able to operate? |
| Could have | Nice to have if time and money allow | Would it improve things a little? |
| Won’t have (this time) | Agreed as out of scope for now | Written down, so it is not forgotten or promised by accident |
| Requirement | Who asked | Priority | Reason |
|---|---|---|---|
| Students can order and pay before recess | Canteen manager | Must | The whole point of the system |
| Orders print in the kitchen | Canteen manager | Must | Staff cannot fill orders without it |
| Allergy warnings on menu items | Parent survey | Should | Safety-related; a printed sign is a stop-gap |
| Loyalty points | Student survey | Could | Popular, but not needed to run the canteen |
| Mobile app for iPhone and Android | Student survey | Won’t | Out of scope for the budget; a mobile-friendly web page is enough |
How to negotiate
- Ask “what problem would this solve?” for each request. A want often has a simpler need behind it.
- Show the client the cost of each item in time and money, using your Gantt chart and budget.
- Offer options: “We can add loyalty points if we drop the print-out, or keep the print-out and add loyalty points next term.”
- Get the agreed list confirmed in writing (an email is enough) and record it in your diary.
- Treat changes after agreement as changes to the plan: what will move, and who agreed?
Uncontrolled additions during a project are known as scope creep. A signed-off priority list gives you a polite, factual way to say “yes, and this is what it will displace”.
Collaboration, Version History and Roles
Working collaboratively Online collaboration tools, keeping track of versions and agreeing who does what
Online collaboration tools
Online collaboration is on NESA’s list of tools that support design and development. What matters is what the tool lets you do, not its brand:
| Need | What to look for | Good practice |
|---|---|---|
| Shared documents and files | Cloud storage where several people can edit, with comments and suggestions | One shared folder with an agreed structure and file-naming pattern |
| Version history | The tool records who changed what and when, and lets you restore an earlier version | Name major versions (for example booking-form_v0.3_2026-08-06) and note what changed |
| Task tracking | A board or list showing tasks, owners and status | Match it to your action plan so you keep one source of truth |
| Communication | A place to talk that keeps a searchable record | Agree how quickly people should reply, and summarise decisions in writing |
Cloud document platforms such as Google Workspace and Microsoft 365 keep a version history, and it can support your process diary: the timestamps show when work happened and who did it. Take regular backups anyway, and make sure your team has the right to use each shared file (a client’s data should go only where they have agreed).
Roles
NESA asks you to outline the role of the participants in a system, and a team needs roles too. Small teams share roles, but every task should still have one accountable person.
| Role | Responsible for | Name |
|---|---|---|
| Client (or client representative) | Explaining the problem, answering questions, giving feedback and approving requirements and the final system | Canteen manager |
| Project manager | The plan, the Gantt chart, the action plan, chasing progress and reporting to the client | |
| Analyst or designer | Requirements, diagrams, data dictionary, storyboards | |
| Developer | Building the solution | |
| Tester | The test plan and running the tests | |
| Documenter and trainer | User guide, training and the maintenance notes |
In Scrum, one common agile framework, the client’s voice is a product owner who orders the backlog, and a scrum master helps the team follow the process. Those role names belong to Scrum, not to every project. If you work alone, you still play every role: say so, and note in your diary which hat you are wearing.
Risk Register
Risk analysis Listing what could go wrong, rating it and deciding what to do
A risk register is a table of things that might go wrong. It is a common project-management tool, not one that NESA specifies. For each risk you rate how likely it is and how serious the consequence would be, then decide on a response. Rating each on a 1 to 3 or 1 to 5 scale and multiplying them gives a score for ranking; the Cybersecurity page shows a full 5 by 5 risk matrix used in the same way. Whatever scale you choose, say what the numbers mean.
| # | Risk | Likelihood | Consequence | Score | Response | Owner |
|---|---|---|---|---|---|---|
| 1 | Client is unavailable for feedback for two weeks | 2 | 3 | 6 | Reduce: agree fixed meeting times now; keep a prototype ready to show | Project manager |
| 2 | Team member absent during the build | 2 | 2 | 4 | Reduce: share files and notes so another person can continue | Everyone |
| 3 | Database file is lost or corrupted | 1 | 3 | 3 | Reduce: automatic cloud backup plus a weekly copy | Developer |
| 4 | Requirements grow after sign-off (scope creep) | 3 | 2 | 6 | Avoid: signed MoSCoW list; changes go through the client meeting | Project manager |
| 5 | Testing finds a serious fault two days before handover | 2 | 3 | 6 | Reduce: test early and often; keep a contingency of time | Tester |
Choosing a response
- Avoid the risk by changing the plan (drop a feature that depends on a tool nobody has used).
- Reduce its likelihood or its consequence (backups, early testing, a second person who knows the task).
- Transfer it to someone better placed to carry it (a supplier who guarantees their part).
- Accept it and set aside time or money for it (your contingency), when the cost of a response is more than the risk.
Review the register whenever you update the Gantt chart. Add new risks as you find them, and mark risks that have passed. Note the ones that actually happened and how you handled them: that is diary material.
Feasibility Checklist
Testing the plan Checking that the project can be done before you commit to it
NESA asks you to “develop an implementation plan and test its feasibility”. A feasibility check asks whether a plan can be delivered. A common way to organise it is to look at four areas (some frameworks add a fifth, legal). This is a common framework, not a NESA list.
| Area | Question | Evidence | Yes, no or with changes |
|---|---|---|---|
| Technical | Do we have, or can we get, the hardware, software and skills? Will it work with the systems already in use? | Skills audit; tool trial; compatibility check | |
| Economic | Do the benefits justify the costs, including ongoing costs? | Budget; expected savings or benefits | |
| Schedule | Can it be finished by the deadline with the people available? | Gantt chart; critical path; risk register | |
| Operational | Will the people who need it actually use it? Does it suit how they work? | Interviews, prototype feedback, training plan |
A “no” is not a failure: it is what the check is for. It tells you to change the plan, for example by reducing the scope, choosing a simpler tool, or asking for more time, before the work is done rather than after. Write down what you changed as a result and keep it in your diary.
Model answer
Technical and economic feasibility are the main concerns: the volunteer lacks the skills and payment handling usually has a cost and a security responsibility. The plan could be changed by using an existing registration service or a simple form instead of building payments, moving to end-user development with a tool the volunteer already knows, and putting online payment in the “won’t have this time” column.
Implementation Plan and Method
Developing an implementation plan How the new system goes live, and which changeover method to use
An implementation plan says how the new system will replace the old one (or be used for the first time): what happens, in what order, who does it and what if it goes wrong. NESA names four changeover methods, direct, parallel, pilot and phased. Their definitions and a scenario table are on the Toolkit page, and the Enterprise Project page covers the theory. The animation below is a quick way to compare them.
Animated diagram
Implementation methods: switching from the old system to the new
Watch the steps, or step through with the arrow keys.
What to notice
- Direct switches every office at once, so a fault hits everyone. Parallel keeps the old system running as a fallback.
- Pilot moves one office first. Phased moves one module at a time across all offices.
Try thisUse the tabs to compare how each method behaves when the new system has a fault.
Choosing a method quickly
| If… | Lean towards |
|---|---|
| Failure would be costly or dangerous, and the extra cost of double work is acceptable | Parallel |
| There are many sites or groups of users, and a small trial would reveal problems | Pilot |
| The system splits into independent modules and training must be spread out | Phased |
| The system is small, low-risk and the old data can be kept as a backup | Direct |
| Heading | What to write | Your plan |
|---|---|---|
| Preferred method | Direct, parallel, pilot or phased, and one or two reasons from your project | |
| Steps and dates | Numbered steps with dates and who is responsible (link to your Gantt chart) | |
| Hardware and software integration | What has to be installed, configured or connected, and how it links to existing systems and data | |
| Data migration | How existing data will be moved, checked and backed up | |
| Training | Who is trained, by whom, when, and how you will know it worked | |
| Risks and fallback | The top risks during changeover and how you would go back to the old way | |
| Success check | How you will know the changeover worked, and who signs it off |
Training and Documentation
Designing for ease of operation and maintenance Making sure people can use the system, and keep it running
A system nobody knows how to use has failed, however well it was built. NESA lists designing for ease of operation and maintenance, and asks you to trial the operation and maintenance documentation during testing. Plan training and documentation in stage 2 and produce them in stage 3, not in the last hour.
| Item | Audience | What it contains |
|---|---|---|
| Quick reference card | Everyday users | The five most common tasks, one screenshot each, in a page |
| User guide | All users | Step-by-step instructions, with screenshots, for every task, plus what to do when an error message appears |
| Training session or video | Users, new staff | A guided walk through the tasks, with practice on test data rather than live data |
| Operation and maintenance documentation | Whoever keeps the system running | How to back up and restore, add or remove users, update the data, fix common faults, and who to contact |
| Technical documentation | Future developers | Diagrams (DFD, system flowchart), the data dictionary, the design decisions and the version history |
Test Plan Template: Normal, Boundary and Erroneous Data
Methodology for testing the system Planning tests before you run them, with test data that covers the edges
Write the test plan before you test, and work out the expected result before you run each test. Otherwise you are only checking that the system does what it does. NESA names six testing methods (functional, acceptance, live data, simulated data, beta and volume), described on the Toolkit page. A common way to choose test data for each function is three groups:
- Normal data: typical values the system should accept.
- Boundary data: values at the edge of what is allowed, and just either side of it. Most faults hide here.
- Erroneous data: values that should be rejected, such as text where a number is expected, a blank, a negative or an impossible date.
| Test | Function | Test data | Type | Expected result | Actual result | Pass or fail |
|---|---|---|---|---|---|---|
| 1 | Enter quantity | 5 | Normal | Accepted | ||
| 2 | Enter quantity | 1 | Boundary (lowest allowed) | Accepted | ||
| 3 | Enter quantity | 20 | Boundary (highest allowed) | Accepted | ||
| 4 | Enter quantity | 0 | Boundary (just below) | Rejected with a clear message | ||
| 5 | Enter quantity | 21 | Boundary (just above) | Rejected with a clear message | ||
| 6 | Enter quantity | abc | Erroneous | Rejected, no crash | ||
| 7 | Enter quantity | (left blank) | Erroneous | Rejected, asks for a value | ||
| 8 | Enter quantity | 2.5 | Erroneous | Rejected: whole numbers only |
Running and recording the tests
- Fill in the expected column for every test before you run any of them.
- Run each test and record exactly what happened, including error messages. Take screenshots for the failures.
- Fix each fault, then re-run the failed test and the tests near it, because a fix can break something else. Record the retest.
- Finish with acceptance testing by the client against your success criteria, and a trial of the user guide.
Model answer
Normal: 9 (accepted) and 11 (accepted). Boundary: 7 (accepted, lowest) and 12 (accepted, highest); you could add 6 and 13 (both rejected) as the values just outside. Erroneous: “nine” (rejected, text) and a blank (rejected, value required). 9.5 is another good erroneous value.
Verification and Validation in Practice
Verify and validate Did we build it correctly, and did we build the right thing?
The syllabus asks you to verify and validate an enterprise computing system. Applied to a whole project, the two words ask different questions. The theory is on the Enterprise Project page.
| Verification | Validation | |
|---|---|---|
| Question | Did we build the system correctly? | Did we build the right system? |
| Compared against | The design and the requirements you wrote | The client’s real need and your success criteria |
| Typical activities | Functional tests, checking calculations and results against expected values, reviewing your diagrams against the build | Acceptance testing, a client trial, beta testing with real users, trialling the documentation |
| Example | The order total equals the sum of the item prices in every test | The canteen manager can actually run recess with it |
A system can pass verification and fail validation: it meets the specification exactly, and the specification was wrong. That is why you go back to the client. You will also meet these words for data in the glossary: validation checks that a value is reasonable and allowed (for example a range check), and verification checks that it was entered or transferred correctly (for example double entry). Both ideas belong in a well-tested system.
Evaluating Against Criteria, and Maintenance
Evaluating and maintaining Judging the solution and the process against your own criteria, and planning its future
To evaluate is to make a judgement based on criteria (NESA’s glossary meaning). So your evaluation must go back to the success criteria you wrote in stage 1. Judge the product and the process: the product is the system; the process is how you managed the project.
| Success criterion | Evidence | Met? | Judgement and reason | Improvement |
|---|---|---|---|---|
| Staff can enter an order in under a minute | Timed trial with the manager, three orders (test 12) | Mostly | Two of three orders met the target; the third was slowed by the item search | Add a search box or shortcut buttons |
| No data is lost if the tablet is restarted | Restart tests 14 and 15 | Yes | Data saved after every order | Add a daily backup |
Evaluating the process
Compare your actual times with your planned times on the Gantt chart. Which tasks took longer, and why? Which risks happened? What did the client feedback change? What would you do differently with the same project again? Your process diary already holds this evidence: quote it. An evaluation that only says “it went well” is a claim; one that names a task, a number and a decision is evidence.
Maintenance
Systems need looking after after they go live. Plan for it. Maintenance commonly includes fixing faults found in use, adapting the system when something around it changes (a new device, a new rule, a new supplier) and improving it in response to new requests. In your notes, say who is responsible, how a fault is reported, how often data is backed up and how updates will be tested before they go live. The requests you placed in the “could” and “won’t” rows of your MoSCoW table are the start of the future improvements list. NESA also lists modifying designs to improve functionality: record what you would change in the design and why.
How Enterprise Computing Is Assessed
Facts from NESA School-based assessment, the take-home task limit and the HSC examination
School-based assessment
- Components and weightings. For both Year 11 and Year 12, NESA sets two mandatory course components, each worth 50%: knowledge and understanding of course content, and knowledge and skills in the practical application of the content.
- Number and type of tasks. Schools decide the number, type and weighting of assessment tasks, within the limit below. NESA’s guidance (not a rule) is to use a variety of tasks and to weight each task between 10% and 40%.
- Project work. On the pages we checked, NESA does not publish a mandatory Enterprise Project task, a project weighting, a length or a word limit. Whether and how your project work is assessed is your school’s decision, so ask your teacher.
- Notice. Under NESA’s assessment rules, schools give students written notice of a task, typically 14 calendar days, with its weighting, the outcomes assessed and the marking criteria where appropriate.
The take-home task limit
NESA has announced that school-based assessment programs can have no more than one take-home task, worth no more than 15%. A take-home task is one completed outside a classroom, a formal examination or teacher-approved monitoring conditions. The limit starts in Term 4 2026 for HSC courses and Term 1 2027 for Year 11 (Preliminary) courses. It does not apply to courses with a major project or an HSC practical exam. Enterprise Computing has neither (the HSC is a written online examination), and it is not on the list of exempt courses NESA published, so as we read that notice the limit applies to it. Your school can tell you how it affects your tasks. Schools still decide the number, type and weighting of tasks completed in class or under supervision.
The HSC examination
The HSC examination is a single written paper done on a computer: 80 marks, 2 hours 30 minutes including 10 minutes reading time, with objective-response items (about 20 marks) and short-answer items (about 60 marks). There is no separate practical examination or submitted major work. Project skills still appear in the exam: the 2025 marker feedback included questions on project management tools (Question 22) and on offshore development and freelance work (Question 24).
| Source | What it covers |
|---|---|
| NESA: school-based assessment ↗ | Components, weightings and the one take-home task rule for Year 11 and Year 12 |
| NESA 29/26: new take-home assessment rules ↗ | The 15% limit, start dates and exempt courses |
| NESA 34/26: ACE rule changes ↗ | Take-home tasks and generative AI |
| ACE rules: assessment programs ↗ | Assessment schedules, notice and school policies |
| NESA: HSC examination specifications ↗ | Exam format, online tools and sample materials |
Academic Integrity and Generative AI
Your own work What NESA requires of schools and how to keep evidence that the work is yours
NESA’s ACE rules require schools to design formal assessment tasks so that marks reflect a student’s own knowledge, skills and understanding, and not the use of generative artificial intelligence. NESA has also said that schools should not rely on AI detection tools as the main safeguard against malpractice. The emphasis is on how schools design tasks and gather evidence of a student’s own work.
In practice that puts the responsibility on you to be able to show how your work was made. Your school will explain what is allowed for each task. Ask before you use any AI tool for any part of a task, and follow the answer.
Keep evidence of your own work
- A process diary with regular, dated, specific entries (see the template and examples). It records your decisions, problems and reflections, which are hard to fake later.
- Version history in your files, showing the project growing in steps over real dates.
- Drafts, sketches and earlier versions, including the ones you threw away.
- Client and teacher feedback and what you changed because of it.
- Sources for anything you did not create yourself: images, code, data, text. Note the licence or permission (see the Creative Commons entry in the glossary).
- The ability to explain it. If you can walk a teacher through any part of your project and say why you did it that way, you have the strongest evidence of all.