Software Engineering Project

Defining and Analysing Requirements

🎯 (SE-12-01, SE-12-06)

📌 Define and analyse the requirements of a problem

• demonstrating need(s) or opportunities
• assessing scheduling and financial feasibility
• generating requirements including functionality and performance
• defining data structures and data types
• defining boundaries

Problem Requirements

Before coding begins, a software engineer must define the core requirements:

• 🎯 Demonstrating needs or opportunities: Clearly identifying the real-world problem the software solves for the client.
• 💰 Assessing scheduling and financial feasibility: Determining if the project can be completed within the allocated timeframe and budget.
• 📝 Generating requirements: Defining functionality (what the system must do) and performance (how well/fast it must do it).
• 🗄️ Defining data structures and types: Specifying how information will be securely collected and stored.
• 🚧 Defining boundaries: Establishing the scope to prevent "scope creep" during development.

Demonstrating a need or an opportunity

A need is a problem that real people have now. An opportunity is a chance to do something better that nobody has complained about yet. Either way you must demonstrate it with evidence from the people affected, not assume it. Useful evidence is an interview, an observation of the current process, samples of the current records, a short survey, or a measurement (such as how long a task takes today).

Assessing scheduling and financial feasibility

Feasibility asks whether the project can realistically be finished with the time and money available. Estimate the effort task by task, add a contingency for things that go wrong (10% to 20% is common), and compare the total with the time you actually have. Do this before promising features to the client.

• Time available: 7 weeks × 7 hours a week (class time plus home study) = 49 hours.
• Core scope with 15% contingency: 42 × 1.15 = 48.3 hours. This is less than 49 hours, so the core scope is schedule-feasible, with only 0.7 hours to spare.
• Core scope plus email reminders: (42 + 8) × 1.15 = 57.5 hours. This is more than 49 hours, so it is not feasible.
• Financial feasibility: the project uses only free tools (VS Code, Python, SQLite, Git and GitHub) and the library's existing computer, so the cash cost is $0. A costed budget for a paying client is worked through in Applying Project Management.
• Decision: email reminders are put outside the boundary for version 1 and recorded as a possible later version. Mrs Chen agrees, because the overdue list she needs most is still delivered.

Requirements Analysis

Requirements must be clearly categorised before development starts. ⚙️ Functional requirements describe what the system must do; ⚡ Non-functional requirements describe how well it must do it (quality attributes). Documenting both types ensures the solution is both complete and fit for purpose.

Generating requirements: the Library Loans list

Give every requirement an ID, a priority and a way it will be verified. Requirements that cannot be checked ("the system should be fast") are not yet requirements. The IDs let the test plan and the final evaluation point back to them, as in the later sections of this page.

User Stories and Acceptance Criteria

User stories capture requirements from the end-user's perspective in plain language. They follow the format: "As a [role], I want [feature], so that [benefit]." Each user story is accompanied by acceptance criteria — specific, testable conditions that confirm the story has been implemented correctly.

Defining data structures and data types

Requirements say what information the system handles. You then decide how each item is typed (text, whole number, decimal, date, true/false) and how items are structured (a single variable, a list, a dictionary of records, a database table). Choose the simplest type that stores the value correctly and lets you validate it.

from datetime import date

# A dictionary gives direct lookup by member ID; a list keeps loan records in order.
members = {
    "S0012345": {"name": "Alice Chen", "active_loans": 1},
    "S0012346": {"name": "Ben Ortiz", "active_loans": 5},
}
loans = [
    {"isbn": "9780743273565", "member_id": "S0012345", "due": date(2026, 3, 17)},
]

print(members["S0012346"]["name"])       # direct lookup by key
print(len(loans))                        # a list of records
print(type(loans[0]["due"]).__name__)    # a real date, not text

Expected output: Ben Ortiz, then 1, then date.

Constraints and boundaries

A constraint limits how the project may be carried out. A boundary defines what the system will and will not do. Together they protect the project from scope creep, the slow growth of requirements that nobody has costed.

The system boundary is shown on the Level 0 data flow diagram in Using Modelling Tools: students, the librarian and the school admin system are outside the boundary, and the Library Loans system is inside. A written scope statement makes the same boundary explicit.

Handling a change request. When Mrs Chen asks for something outside the boundary: (1) write the request down; (2) estimate its hours; (3) show the effect on the schedule (the email reminders in the feasibility example added 8 hours and made the project infeasible); (4) let the client decide to swap it for something else, extend the deadline or defer it; (5) record the decision in the process diary. Boundaries also exist inside the data. "A member may hold at most 5 loans" is a boundary that later becomes boundary test data at 4, 5 and 6.

Tools to Develop Ideas and Generate Solutions

🎯 (SE-12-01, SE-12-06)

📌 Explore tools used to develop ideas and generate solutions

• brainstorming, mind-mapping and storyboards
• data dictionaries, including selecting appropriate data types
• algorithm design
• code generation
• testing and debugging
• installation
• maintenance

Brainstorming and mind-mapping

Brainstorming is a short burst of ideas with no judging, so quantity comes before quality. Mind-mapping then organises the ideas around a central topic, with branches for groups and sub-branches for detail. The two steps work as a pair: diverge (collect everything), then converge (sort, cut and choose using the requirements and constraints).

Worked example. In five minutes the student and Mrs Chen list everything the library system could do: scan barcodes, email reminders, search by title, fines, staff sign-in, student photos, reserve a study room, print the overdue list, reading recommendations, renew a loan. The mind map below groups those ideas, and the constraints from the previous section decide which branches are built now.

• Library Loans
  • Loans (build now): issue, return, loan limit; renew (later)
  • Catalogue (build now): search by title or ISBN, availability
  • Reports (build now): overdue list, fines, CSV export
  • Members (build now): name and ID only; staff sign-in
  • Later versions: email reminders, reserving a study room, recommendations
  • Rejected: student photos (privacy risk and no client need)

Storyboards and Wireframes

A storyboard visually maps the sequence of screens a user encounters when completing a task. A wireframe is a low-fidelity layout sketch of a single screen, showing the placement of UI elements without colour or detailed styling. Together, they allow client feedback on the interface before any front-end code is written.

Worked storyboard. NESA describes a storyboard as showing the screens and the links between them. This one covers issuing a loan.

Data Dictionary

A data dictionary formally defines every data item used in the system — its name, data type, size, valid range, and description. It ensures consistency between the design documents and the code implementation, and establishes the data structures required for the project.

Selecting appropriate data types: NESA's data dictionary layout

NESA's Course Specifications (p. 8) describe a data dictionary as a comprehensive description of each variable, and give a layout with these columns: variable, data type, format for display, size in bytes, size for display, description, example and validation. The table above is a working format for a project. In the exam, complete or read a dictionary in the NESA layout, as below. A date and time is always stored as 32 bits (4 bytes), whatever format it is displayed in.

Selecting the type: ask what the value means and what you will do with it. If you will calculate with it, use a number; if you compare it in time, use a date; if it is an identifier or a code, use a string even when it looks numeric; if there are two states, use a Boolean. Then write the validation so the type can only hold legal values.

Project Structure Chart

A structure chart breaks the software solution into its major components before coding begins. It shows how the top-level system is decomposed into modules, and how those modules relate to each other. The chart below illustrates a typical school library management system.

Algorithm design

An algorithm is the step-by-step logic of a solution, written before the code. NESA's Course Specifications ask for algorithms as pseudocode or flowcharts, built from sequence, selection and repetition. In pseudocode keywords are capitals, structures come in pairs (every IF has an ENDIF, every BEGIN has an END), indentation shows the structure, and a subroutine is called by name with its own algorithm written separately. Start with a short mainline that calls subroutines.

BEGIN LibraryLoans
    SignIn
    REPEAT
        DisplayMenu
        Get choice
        CASEWHERE choice evaluates to
            1: IssueLoan
            2: ReturnBook
            3: SearchCatalogue
            4: OverdueReport
            5: Display "Goodbye"
            OTHERWISE: Display "Choose a number from 1 to 5"
        END CASE
    UNTIL choice = 5
END LibraryLoans

One subroutine in detail: the fine for a loan (requirement FR6, 20 cents a day up to $10.00). The fine is held in cents so the arithmetic is exact. This is a nested IF, with one ENDIF for each IF.

BEGIN CalculateFine (daysOverdue, fine)
    IF daysOverdue <= 0 THEN
        fine = 0
    ELSE
        IF daysOverdue > 50 THEN
            fine = 1000
        ELSE
            fine = daysOverdue * 20
        ENDIF
    ENDIF
END CalculateFine (daysOverdue, fine)

Desk-check it with a trace table before writing any code. The four inputs below sit on the edges of the rules (0 and 1 for overdue, 50 and 51 for the cap).

def calculate_fine_cents(days_overdue):
    """Return the fine in cents: 20 cents a day, capped at 1000 (ten dollars)."""
    if days_overdue <= 0:
        fine = 0
    else:
        if days_overdue > 50:
            fine = 1000
        else:
            fine = days_overdue * 20
    return fine


for days in (0, 1, 50, 51):
    print(days, calculate_fine_cents(days))

Expected output: 0 0, 1 20, 50 1000, 51 1000, matching the trace table.

Code generation

Code generation is turning a design into working code. It can be done by hand, guided by the design documents, or with tools that produce code from a description: templates and project scaffolds, IDE features that create class or function outlines, tools that create database code from a schema, and generative AI assistants. Whatever produces the first draft, you remain responsible for understanding, testing and acknowledging it.

A good hand-generation habit is to create stubs straight from the structure chart, so the code matches the design from the first commit. A data dictionary row set turns directly into a class.

from dataclasses import dataclass
from datetime import date


def issue_loan(member_id, isbn):
    """Structure chart module: Borrowing. Not written yet."""
    raise NotImplementedError


@dataclass
class Loan:
    """One row of the Loan record in the data dictionary."""
    isbn: str
    member_id: str
    due: date
    fine_cents: int = 0


print(Loan("9780743273565", "S0012345", date(2026, 3, 17)))

Expected output: Loan(isbn='9780743273565', member_id='S0012345', due=datetime.date(2026, 3, 17), fine_cents=0)

Testing and debugging

Testing finds out whether the software fails; debugging finds out why and fixes it. Both are tools for developing solutions, not only a stage at the end: test each module as you write it. Common debugging tools are print statements or a logger, an IDE breakpoint with single-step execution, and a trace table on paper. Part 4 covers the full methodology.

Worked example (defect BUG-002). The loan limit test fails: a member with 5 loans is allowed a sixth. Reproduce it, isolate the condition, then fix it.

def can_borrow(active_loans, limit=5):
    return active_loans <= limit      # bug: 5 <= 5 is True, so a sixth loan is allowed


print(can_borrow(5))                    # expected False, actual True

# Fix: a member may borrow only while they hold FEWER than the limit
def can_borrow(active_loans, limit=5):
    return active_loans < limit


print(can_borrow(5))                    # False
print(can_borrow(4))                    # True

Expected output: True, then False, then True. The first line shows the defect. The last two show the boundary now behaves correctly.

Installation

Installation puts the finished software into the client's environment so they can use it. It is planned like any other task, because a solution that only runs on the developer's laptop is not delivered. Plan the install around the implementation method chosen (direct, phased, parallel or pilot).

python -m venv .venv
.venv\Scripts\activate            # Windows. On macOS or Linux: source .venv/bin/activate
pip install -r requirements.txt
python setup_database.py           # creates the empty database and the first staff account
python main.py

Maintenance

Maintenance is the work of keeping software useful after it is installed. It usually costs more effort over the life of a system than the original build, so design for it: clear structure, comments and docstrings, tests, version control and a defect log. Maintenance is commonly grouped into four types (these are widely used industry terms, not a NESA list).

Software Implementation Methods

🎯 (SE-12-01)

📌 Investigate types of software implementation methods

• direct
• phased
• parallel
• pilot

Comparing the methods against criteria

To investigate the methods, compare them against the same criteria every time. The differences below follow from how each method is built: what runs at the same time, and how many people are exposed to a fault.

Phased and pilot are easy to confuse. Phased introduces the new features one stage at a time (for example the loans module first, then reports). Pilot introduces the whole system to a few users first (for example one class of borrowers), then everyone. Organisations sometimes combine them, piloting with one group and then rolling out in phases.

Worked example: switching the library over

Choose the method for Library Loans using facts from the scenario: one library, one desk with two volunteers, the paper cards are the only current record, and every loan must stay accurate.

Justification: parallel is chosen because accuracy matters most and the volume of loans is small enough for double entry to be affordable. What would change the decision: if the school wanted the system in five libraries, a pilot in one library followed by a rollout would become the better choice, because parallel running in every library would be expensive.

The Waterfall Approach

🎯 (SE-12-01, SE-12-09)

📌 Research and use the Waterfall software development approach

• logical progression of steps used throughout the life cycle
• stages of ‘falling water’
• advantages and disadvantages
• scale and types of developments

Waterfall works through the development steps one at a time, in order. Each stage is finished and signed off before the next begins, so the project flows downwards like water over a series of ledges.

• Logical progression of steps: requirements → design → development → testing → installation → maintenance. Each stage produces documents that the next stage relies on.
• Stages of 'falling water': going back up is difficult and expensive. A change found during testing may mean redoing design and development.

Scale and types of developments: Waterfall suits large projects with stable, well-understood requirements and strict regulation, such as a hospital records system or an aircraft control system.

Logical progression of steps: stages and sign-off

Each Waterfall stage ends with a deliverable that is reviewed and signed off before the next stage starts. That is what makes progress easy to track, and it is why going back is expensive. The Library Loans project would look like this.

Stages of 'falling water': what going back costs

Suppose that at acceptance testing Mrs Chen asks for different loan periods for junior and senior students. In Waterfall the change reaches back through every finished stage.

The plan has 3 spare days (32 days of critical work in a 35-day term, see Applying Project Management), so the change makes the release 3 days late. The same request in an Agile project is one new backlog item, done in the next sprint. This is the key trade-off to be able to explain.

Scale and types of developments: when Waterfall fits

The Agile Approach

🎯 (SE-12-01, SE-12-09)

📌 Research and use the Agile software development approach

• rate of developing a final solution
• method tailoring
• iteration workflow
• scale and types of developments

Agile builds software in short cycles called iterations or sprints. Each cycle delivers a small working piece that the client can try and give feedback on, so the plan keeps adjusting as the project goes.

• Rate of developing a final solution: a usable version appears early and improves every sprint, so value arrives sooner than in Waterfall.
• Method tailoring: teams adapt the process to suit the project, for example choosing one-week sprints or skipping formal ceremonies in a small team.
• Iteration workflow: plan → build → test → review with the client → adjust, then repeat.
• Scale and types of developments: best for small to medium projects where requirements are likely to change, such as a start-up's mobile app or a school's online booking system.

Rate of developing a final solution

Agile measures progress by working software, not documents. Requirements become a backlog of user stories, and each story is given a size in story points (a relative estimate of effort). The points a team finishes in a sprint are its velocity. Averaging past velocities gives a forecast that improves every sprint. The Library Loans backlog, with the stories tied to the requirement IDs:

import math

completed = [8, 6, 7]                        # points finished in sprints 1 to 3
remaining = 26 - sum(completed)              # points still in the backlog
velocity = sum(completed) / len(completed)   # average points per sprint
print(round(velocity, 1), remaining, math.ceil(remaining / velocity))

Expected output: 7.0 5 1, meaning an average of 7.0 points a sprint, 5 points left, and 1 more sprint. The client had a working issue-and-return system after sprint 2, well before the final sprint. That early value is the difference from Waterfall.

Method tailoring

Method tailoring means adapting the framework to suit the project rather than following it rigidly. Scrum was written for small teams, so a solo student keeps the purpose of each practice and changes its form.

Iteration workflow

Each iteration follows plan, build, test, review, adjust. Sprint 2 of Library Loans, as a plan:

• Sprint goal: a returned book is recorded, fines are calculated and staff can sign in.
• Sprint backlog: record a return (3 points), calculate fines (3 points) and staff sign-in (2 points), so 8 points planned.
• Build and test: write each function with its unit tests, commit small changes, keep the board up to date.
• Definition of done: the code is committed, unit tests pass, the acceptance criteria are met, and Mrs Chen has seen it working. A story that misses any one of these is not counted.
• Review and adjust: at the demonstration the returns and fines worked, but password hashing for sign-in was unfinished. A story counts only when it is done, so 2 points were completed short and the velocity was 6, not 8. Sign-in moves to sprint 3 and the forecast is updated.

Scale and types of developments: when Agile fits

Agile suits small to medium projects, often with one team, where the client is available and requirements are likely to change. The Agile Manifesto (2001) states the values behind it: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. The items on the right still matter, but the items on the left matter more.

The WAgile Approach

🎯 (SE-12-01, SE-12-09)

📌 Research the WAgile software development approach

• understanding it is a hybrid model
• analysis of the ‘when’ and ‘how’ intervention is applied during the development life cycle
• scale and types of developments

WAgile is a hybrid model: it plans and closes a project the Waterfall way but builds the software in Agile sprints.

• When intervention is applied: at fixed checkpoints, such as signing off requirements, approving a design, and a final security audit before release.
• How intervention is applied: through formal reviews and sign-offs at those gates. Between them, the team works in sprints and adapts to feedback.
• Scale and types of developments: medium to large projects that need both flexibility and firm control, such as a bank adding a new feature to an existing regulated system.

Analysing the 'when' and 'how' of intervention

Intervention is a planned point at which someone outside the build team checks or changes direction. In WAgile the when is the gate, and the how is the evidence and approval the gate requires. For Library Loans:

Choosing a development approach: criteria

To choose between Waterfall, Agile and WAgile, rate each approach against criteria drawn from the project and weight the criteria that matter most. Here is a weighted decision matrix for Library Loans (each rating is out of 5, and the weight shows how much the criterion matters, from 1 to 3).

Each total is the sum of weight × rating. For Waterfall: 3×2 + 2×2 + 3×5 + 2×5 + 1×4 = 39. WAgile scores highest because the school needs sign-offs and a fixed deadline, yet Mrs Chen can still steer the build. The totals are close, and different weights could change the answer. What earns marks is the reasoning behind each rating, not the arithmetic.

Applying Project Management

🎯 (SE-12-05, SE-12-09)

📌 Apply project management to plan and conduct the development and implementation of a project and software engineering solution

• scheduling and tracking using a software tool, including Gantt charts
• using collaboration tools

Apply project management to plan and conduct the development of a software solution. This involves scheduling and tracking using software tools, notably 🛠️ Gantt charts, to allocate time to tasks, and using collaborative tools (e.g., GitHub, Jira) to track team progress.

Gantt Chart — Project Schedule

A Gantt chart is a horizontal bar chart that maps project tasks against a timeline. It visually shows the start date, duration, and end date of each task, and can indicate task dependencies (where one task must complete before another begins). A useful Gantt chart for your project covers all four syllabus phases (identify and define, research and plan, produce and implement, test and evaluate), so it is easy to show that no phase was skipped.

What a Gantt chart must show

NESA's Course Specifications (p. 11) say a Gantt chart displays each component task on an estimated timeline, and list what it should show:

• Self-explanatory task names ("Search module", not "Task 4").
• The estimated time for each task and its dependent tasks, meaning tasks that cannot start until another finishes.
• A time scale with dates, and important milestones clearly marked.
• Optionally, resources: the chart can allocate team members to tasks and show each person's percentage completion.
• Regular updates during development to compare actual with estimated times.

Worked example: dependencies, float and the critical path

Some tasks can run at the same time; others must wait. The critical path is the longest chain of dependent tasks, and it decides the earliest finish date. (The critical path is a standard planning technique; NESA's specification asks for dependencies and milestones and does not name it, but it is the way to find which dependencies matter most.) For each task, work out four times and one number:

• ES (earliest start) is the latest EF of the tasks it depends on, or 0 if there are none. EF (earliest finish) = ES + duration. This is the forward pass.
• LF (latest finish) is the earliest LS of the tasks that depend on it, or the project end if none do. LS (latest start) = LF − duration. This is the backward pass.
• Float (slack) = LS − ES. It is how many days a task can slip without delaying the project. Tasks with zero float are critical.

Task G must wait for both D (finishes on day 13) and F (day 18), so G starts on day 18, and D has 5 days of float. The critical path is A → B → C → F → G → H → J = 5 + 3 + 4 + 6 + 7 + 4 + 3 = 32 days. The term gives 35 days, so the plan has 3 days of spare time.

To reproduce the table in code, the passes are short. This program computes the same numbers.

tasks = {
    "A": (5, []),
    "B": (3, ["A"]),
    "C": (4, ["B"]),
    "D": (5, ["B"]),
    "E": (8, ["C"]),
    "F": (6, ["C"]),
    "G": (7, ["D", "F"]),
    "H": (4, ["E", "G"]),
    "I": (6, ["C"]),
    "J": (3, ["H", "I"]),
}

early = {}
for name, (days, before) in tasks.items():          # forward pass
    start = max((early[p][1] for p in before), default=0)
    early[name] = (start, start + days)

project = max(finish for start, finish in early.values())

late = {}
for name in reversed(list(tasks)):                   # backward pass
    days = tasks[name][0]
    after = [n for n, (d, before) in tasks.items() if name in before]
    finish = min((late[n][0] for n in after), default=project)
    late[name] = (finish - days, finish)

print(f"Project duration: {project} days")
for name in tasks:
    spare = late[name][0] - early[name][0]
    print(name, "early", early[name], "late", late[name], "float", spare, "CRITICAL" if spare == 0 else "")

Expected output: Project duration: 32 days, then one line per task. Tasks A, B, C, F, G, H and J print CRITICAL; D and E print float 5 and I prints float 11. For example, the line for D is D early (8, 13) late (13, 18) float 5.

Tracking: actual versus estimated

A plan is only useful if you keep it up to date. At each check, record the actual time, work out the variance, and ask whether the task was on the critical path. Only a slip on a critical task (or a slip larger than the float) moves the finish date.

After three tasks the critical path has slipped by 2 days, so the forecast finish is day 34 of 35 and only 1 spare day remains. The response is to protect the critical path: trim the polish on the interface (task G) rather than the testing (task H), and tell Mrs Chen at the next review. The same figures can be shown on the chart by updating each bar to its actual length, as NESA's specification suggests.

Budgeting

A budget estimates what the project will cost and is then compared with what it actually costs. A school project usually has no cash budget, but time is a budget too (49 hours in the feasibility example). To practise costing, suppose a professional developer built the same core scope for a paying client at illustrative rates.

The rate and the licence cost are invented for practice. In a real project you would use the organisation's rates and quotes. Track spending against the budget as the project goes, and report any variance: if 10 hours are used before the design is finished and only 5 were planned, the budget is already under pressure and the client should hear about it early. A project with free tools, like this one, still records its time budget and any costs avoided by using free software.

Using collaboration tools

NESA's glossary defines collaborate as working with others towards a shared goal, through a variety of modes of communication, which may be achieved using a range of technologies, tools and processes. A tool is worth using if it makes work visible, keeps a record, or makes it easy for the client and peers to respond.

Before choosing a tool, check your school's rules on cloud services, because some tools store data outside Australia and student information must not be uploaded to them.

Process Diary Example Excerpt

The process diary (or log book) is a chronological record of your development journey. NESA's Course Specifications (p. 12) say entries, made at regular intervals, should include the date, the person making the entry, progress since the last entry, tasks achieved, stumbling blocks or issues and how they were managed, possible approaches for upcoming tasks, reflective comments and resources used. The excerpt below covers each of these.

Social and Ethical Issues in Project Work

🎯 (SE-12-05, SE-12-09)

📌 Explore social and ethical issues associated with project work, including working individually, collaboratively and responding to stakeholders

Project work raises social and ethical questions about how people are treated, whether you work alone or in a team.

Working individually

Working alone removes team conflict but not responsibility. The issues are honesty, acknowledgement and self-management.

• Honest reporting. Record what you did and what went wrong in the process diary. Do not present a feature that is half-working as finished, and do not claim testing you did not do.
• Acknowledging others' work. Copying code, images or ideas without credit is plagiarism, and it may also breach copyright (the Copyright Act 1968). Open-source code can be reused under its licence, which usually requires you to keep the author's notice. Add a comment with the source and licence next to any borrowed code.
• Tools that write code. If generative AI is allowed on a task, say how you used it and make sure you can explain every line. NESA's ACE rules require marks to reflect your own knowledge, skills and understanding.
• Managing your own time. Tell the client early if a deadline is at risk instead of hiding it.

Working collaboratively

In a team the extra issues are fair distribution of work, credit, respect for different views and skills, and handling disagreement. Suppose a classmate, Ben, joins the Library Loans project to build the interface.

• Agree roles and rules early: who owns which modules, how code is reviewed, and how disagreements are settled (for example, the client's stated requirements decide).
• Make contributions visible. Version control records who did what, so credit can be shared accurately:

git shortlog -sn --no-merges
    14  Sam Nguyen
     9  Ben Ortiz

Commit counts are a starting point for a conversation, not a mark: one large, careful commit can be worth more than ten trivial ones. Combine them with the task board and diary entries.

• Review kindly and specifically. "This loop will fail for an empty list" helps; "this is messy" does not. Criticise the code, not the person.
• Handle an uneven workload by talking early, adjusting the plan, and telling the teacher if it is not resolved, rather than quietly redoing a partner's work or letting it slide.

Responding to stakeholders

A stakeholder is anyone affected by, or with an interest in, the software. They often want different things, so the ethical task is to be transparent, protect the people who have no voice in the room, and record how conflicts were settled.

• Be transparent about what the software will and will not do, including its known limitations.
• Protect personal information. Collect only what the requirements justify (data minimisation). Under the Australian Privacy Principles in the Privacy Act 1988, organisations covered by the Act must also keep personal information secure and use it only for the purpose it was collected. Which privacy law covers a school depends on the school, so check it. The Secure Software Architecture page explains this.
• Design for inclusion. Consider users with low vision, motor difficulties or limited English: readable contrast, keyboard use, plain language.
• Resolve conflicts openly: in the example, the overdue list shows the title and days overdue only to signed-in staff, which meets Mrs Chen's need and limits the exposure of student data. Record the decision.

Communication Issues in Project Work

🎯 (SE-12-09)

📌 Explore communication issues associated with project work

• involving and empowering the client
• enabling feedback
• negotiating

Good communication keeps the client, the team and the software pointed at the same goal.

• Involving and empowering the client: invite the client to reviews and let them make decisions about priorities, so the solution is theirs as well as yours.
• Enabling feedback: make it easy to comment, for example with a demo at the end of each sprint and a simple feedback form.
• Negotiating: agree on what is realistic. If a feature won't fit the deadline, offer options, such as a simpler version now and the full feature later.

Involving and empowering the client

Involving the client means including them in decisions from the start. Empowering them means giving them real authority over the things only they can judge, and the information to use it. The Library Loans project does this in four ways.

• Mrs Chen owns the priorities. She orders the backlog and decides which stories come first.
• Plain language. The student shows wireframes and a working demonstration, and avoids terms such as "ORM" and "endpoint" unless they are explained.
• Options, not verdicts. "There are two ways to show overdue books. Here is what each costs in time. Which suits your Friday routine?"
• Acceptance criteria written with her, so she knows exactly what "done" means for each story.

A communication plan

Decide in advance who needs what information, how, and how often. Written down, this is a communication plan.

Enabling feedback

Feedback only arrives if giving it is easy and the client can see what happens to it. Match the method to the question you are asking.

Close the loop: tell the client what changed because of their feedback and what did not, with a reason. People stop giving feedback that disappears.

Negotiating

Negotiating is reaching an outcome both sides can accept, usually by trading scope, time and quality rather than simply refusing or agreeing. A useful order: listen to the real need behind the request, show the effect on time and cost with numbers, offer options, agree in writing, and record it.

Quality Assurance

🎯 (SE-12-01, SE-12-06, SE-12-07)

📌 Investigate how software engineering solutions are quality assured

• defining criteria on which quality will be judged
• ensuring requirements are met using a continual checking process
• addressing compliance and legislative requirements

Quality assurance (QA) is everything a team does to make sure the finished software is good enough, not just at the end but throughout the project. It has three parts.

Defining criteria on which quality will be judged

Quality means "fit for the purpose the client has". It is judged against criteria agreed before building, each with a target that can be measured. Standard quality models, such as ISO/IEC 25010, list characteristics like functionality, performance, usability, reliability, security and maintainability. Turn each characteristic that matters into a measurable criterion and a check.

Quality assurance is about the whole process (planning, standards, reviews, testing during development) so that defects are prevented. Quality control checks the finished product for defects. A project needs both.

Ensuring requirements are met using a continual checking process

The later a defect is found, the more it costs to fix, so checks are built into every stage instead of waiting for the end. Every check points back to a requirement ID.

Addressing compliance and legislative requirements

Software must obey the law and relevant standards, so compliance is a quality criterion like any other. Identify what applies early and turn it into requirements. This table is a study aid and not legal advice.

Using Modelling Tools

🎯 (SE-12-06)

📌 Demonstrate the use of modelling tools

Modelling tools let you plan and explain a system before and while you build it. Choose the tool that answers the question you have: a data flow diagram for how data moves, a structure chart for how the program is divided into modules, and a decision tree or table for complex choices. In your project, show a model and explain how it shaped your code.

Data Flow Diagram (DFD)

A Data Flow Diagram (DFD) models how data moves through a system. It shows external entities (users or other systems), processes that transform data, data stores (databases or files), and the data flows connecting them. A Level 0 DFD (Context Diagram) shows the entire system as a single process with all external entities. A Level 1 DFD expands the main process into its sub-processes.

Level 1 for Library Loans: a worked answer

A Level 1 DFD opens up the single process and shows the data stores. NESA's symbols are a circle for a process, a labelled curved arrow for a data flow, a data store, and a rectangle for an external entity. The canteen figure below uses the same notation on a different system, so you can check the symbols. The table gives the Library Loans answer flow by flow.

Choosing the right tool

Decision tree: can this loan be issued?

The rules for FR2 and FR3 are decisions in sequence, so a decision tree shows every outcome. It also sets the number of test cases: there is one path to each outcome, and so three paths need at least three tests.

Show a model and explain how it shaped your code. Example: the structure chart named Borrowing, Returning and Search as separate modules, so the code has issue_loan(), return_book() and search_by_title() in separate files. A change to the search then cannot break the loan rules.

The Contribution of Back-End Engineering

🎯 (SE-12-02, SE-12-03)

📌 Explain the contribution of back-end engineering to the success and ease of software development

• technology used
• error handling
• interfacing with front end
• security engineering

Explain the contribution of back-end engineering to the success and ease of software development:

Technology Used

The selection of server-side frameworks and database technologies fundamentally determines a project's performance, scalability, and long-term maintainability. For example, a Django (Python) framework provides a built-in ORM, authentication system, and admin panel — reducing development time for data-driven applications. Alternatively, Node.js enables non-blocking I/O suited to high-concurrency environments, such as real-time chat applications. Database choice is equally critical: a relational database such as PostgreSQL enforces data integrity through foreign keys and ACID transactions, whereas a NoSQL database such as MongoDB offers flexible document schemas suited to rapidly evolving data models.

Error Handling

Robust error handling ensures the server remains stable and informative when unexpected inputs or system failures occur. Without it, an unhandled exception could crash the entire server process — making the application unavailable to all users simultaneously. For example, a try/except block in Python can catch a database connection timeout and return a user-friendly 503 Service Unavailable HTTP response, rather than exposing a raw stack trace to the client. Also, structured logging (e.g., Python's logging module) records error details for post-mortem debugging, without leaking sensitive system information to end-users.

Interfacing with Front End

Back-end engineers design Application Programming Interfaces (APIs) that define precisely how the front-end client requests and receives data. A RESTful API uses standard HTTP methods (GET, POST, PUT, DELETE) with JSON payloads, allowing any front-end technology — React, Angular, or a mobile app — to consume the same endpoints without modification. For example, a GET request to /api/students/42 would return a JSON object containing that student's profile. Efficient API design minimises data transfer by returning only required fields, and uses HTTP status codes correctly (200 OK, 404 Not Found, 401 Unauthorised) so the front end can respond appropriately to every outcome.

Security Engineering

The back end is the primary line of defence against malicious attacks. Password security is implemented through cryptographic hashing algorithms such as bcrypt, which store a one-way hash rather than plaintext — meaning a complete database breach still cannot reveal user credentials. Input sanitisation and parameterised SQL queries prevent SQL injection attacks, where an attacker might otherwise embed SQL commands in a form field to manipulate or delete database records. Also, implementing HTTPS with TLS certificates encrypts all data in transit, protecting against man-in-the-middle attacks on public networks.

Worked example: a small back-end endpoint

The Library Loans back end could expose one endpoint that the front end calls to look up a member. Each numbered comment marks one of the four Including items.

import logging
import sqlite3

from flask import Flask, jsonify            # (1) technology used: a small framework

app = Flask(__name__)
logging.basicConfig(level=logging.INFO, format="%(levelname)s %(message)s")
DB_PATH = "library.db"


@app.get("/api/members/<member_id>")       # (3) interface with the front end: URL, method, JSON
def get_member(member_id):
    """Return one member as JSON, or a clear error the front end can act on."""
    try:
        with sqlite3.connect(DB_PATH) as db:
            row = db.execute(
                "SELECT member_id, name FROM members WHERE member_id = ?",   # (4) security: parameterised query
                (member_id,),
            ).fetchone()
    except sqlite3.Error:
        logging.exception("Database error while looking up a member")     # (2) error handling: detail to the log
        return jsonify(error="Service temporarily unavailable"), 503       #     generic message to the user
    if row is None:
        return jsonify(error="Member not found"), 404
    return jsonify(member_id=row[0], name=row[1]), 200

Expected behaviour (using the database from the earlier examples): a request for S0012345 returns status 200 and {"member_id": "S0012345", "name": "Alice Chen"}. An unknown ID returns 404 and {"error": "Member not found"}. If the database file cannot be opened, the server logs the full error, returns 503 with a generic message, and stays running.

Passwords need the same care. The next program stores a random salt with a slow hash, so identical passwords give different stored values and a stolen database does not reveal them (libraries such as bcrypt do this for you and are the usual choice in a real project; this version uses only Python's standard library).

import hashlib
import hmac
import os


def hash_password(password):
    """Return salt + slow hash. The salt is random, so equal passwords give different results."""
    salt = os.urandom(16)
    digest = hashlib.pbkdf2_hmac("sha256", password.encode(), salt, 200_000)
    return salt + digest


def check_password(password, stored):
    salt, digest = stored[:16], stored[16:]
    attempt = hashlib.pbkdf2_hmac("sha256", password.encode(), salt, 200_000)
    return hmac.compare_digest(attempt, digest)


stored = hash_password("correct horse battery")
print(check_password("correct horse battery", stored))
print(check_password("Password1", stored))
print(hash_password("same") == hash_password("same"))

Expected output: True, False, False.

Contribution to success and ease of development

• Separation of concerns. Because the front end only knows the URL and the JSON shape, the interface can be redesigned, or a mobile app added, without touching the loan rules.
• Testability. Endpoints and functions with clear inputs and outputs can be tested without a screen, so defects are found early.
• Reliability. Handled errors keep one bad request from stopping the service for everyone, and the log gives the developer what they need to fix it.
• Trust. Security built in at the back end protects the client and the people whose data is stored, and avoids expensive retrofits later.
• Speed of development. A well-chosen framework and database supply common features (routing, sessions, migrations), so effort goes into the client's actual problem.

Designing, Constructing and Implementing a Solution

🎯 (SE-12-02, SE-12-04, SE-12-06, SE-12-09)

📌 Design, construct and implement a solution to a software problem using appropriate development approach(es)

Modular Design — Python Example

A well-engineered solution separates concerns into distinct modules and classes. The example below shows how the Library Management System is implemented using modular Python, with each class responsible for a single aspect of the system.

"""
Library Management System — Modular Python Design
Demonstrates separation of concerns across classes.
"""

# ── DATA LAYER ─────────────────────────────────────────────
class Book:
    """Represents a single book in the library catalogue."""
    def __init__(self, isbn: str, title: str, author: str):
        self.isbn = isbn
        self.title = title
        self.author = author
        self.available = True

    def __repr__(self):
        status = "Available" if self.available else "On Loan"
        return f"Book({self.title!r} by {self.author} — {status})"


class Member:
    """Represents a library member."""
    MAX_LOANS = 5

    def __init__(self, member_id: str, name: str, email: str):
        self.member_id = member_id
        self.name = name
        self.email = email
        self.active_loans = []

    def can_borrow(self) -> bool:
        return len(self.active_loans) < self.MAX_LOANS


# ── SERVICE LAYER ──────────────────────────────────────────
class LoanService:
    """Handles all business logic for issuing and returning loans."""

    def __init__(self):
        self.loans = []  # In a real system, this would query a database

    def issue_loan(self, book: Book, member: Member) -> str:
        """Issue a loan if the book is available and member can borrow."""
        if not book.available:
            return f"Error: '{book.title}' is currently on loan."
        if not member.can_borrow():
            return f"Error: {member.name} has reached the maximum loan limit."

        book.available = False
        member.active_loans.append(book.isbn)
        self.loans.append({"isbn": book.isbn, "member_id": member.member_id})
        return f"Success: '{book.title}' issued to {member.name}."

    def return_book(self, book: Book, member: Member) -> str:
        """Process a book return."""
        if book.isbn not in member.active_loans:
            return f"Error: No active loan found for '{book.title}'."
        book.available = True
        member.active_loans.remove(book.isbn)
        return f"Success: '{book.title}' returned by {member.name}."


# ── SEARCH MODULE ──────────────────────────────────────────
class Catalogue:
    """Manages the book catalogue and provides search functionality."""

    def __init__(self):
        self.books: list[Book] = []

    def add_book(self, book: Book):
        self.books.append(book)

    def search_by_title(self, query: str) -> list[Book]:
        """Case-insensitive partial title search."""
        query = query.lower()
        return [b for b in self.books if query in b.title.lower()]

    def search_by_isbn(self, isbn: str) -> Book | None:
        """Return the book matching the given ISBN, or None."""
        return next((b for b in self.books if b.isbn == isbn), None)


# ── MAIN PROGRAM ───────────────────────────────────────────
if __name__ == "__main__":
    catalogue = Catalogue()
    loan_service = LoanService()

    book1 = Book("978-0-7432-7356-5", "The Great Gatsby", "F. Scott Fitzgerald")
    member1 = Member("S001", "Alice Chen", "alice@school.edu.au")

    catalogue.add_book(book1)
    print(catalogue.search_by_title("gatsby"))
    print(loan_service.issue_loan(book1, member1))

Expected output:

[Book('The Great Gatsby' by F. Scott Fitzgerald — Available)]
Success: 'The Great Gatsby' issued to Alice Chen.

Design: from models to a module layout

Designing a solution means deciding its parts before writing them, using the models from Part 1 and Part 2. Each module in the structure chart becomes a file or class with one job, and each data store in the DFD becomes a table or file. The design decisions for Library Loans:

Construct: small, tested steps

1. Set up first: a folder layout (for example src/, tests/, docs/), a Git repository, and a README.
2. Build one story at a time from the backlog, on its own branch, in the order of the Gantt chart's critical path.
3. Write the test, then the code, or at least write the tests for a function before moving to the next. Use the test data table from Part 4.
4. Follow a coding standard: PEP 8 naming and layout, meaningful names (days_overdue, not d), a docstring on every function, comments that explain why.
5. Commit small changes with clear messages and demonstrate a working piece to the client at each review.

Implement: use the appropriate development approach

"Implement" is the step that delivers the solution to the client, following the plan for the approach chosen. The approach changes how you construct and deliver.

Presenting Your Solution

🎯 (SE-12-09)

📌 Present a software engineering solution using presentation software

At the end of the project you present your solution to an audience such as your client, class or teacher. Presentation software such as PowerPoint, Google Slides or Keynote helps you show the problem, the solution and the evidence that it works.

• Open with the need or opportunity you addressed.
• Demonstrate the key features, using a live demo or screen recording.
• Show evidence from testing and client feedback.
• Finish with an honest evaluation and next steps.

A slide plan for the Library Loans presentation

Presenting well

• Know your audience. A client wants to know what it does for them and what it cost; a teacher also wants the process evidence. Adjust the amount of technical detail.
• Make slides accessible. Large text, strong contrast, no important information carried by colour alone, and alt text for images.
• Rehearse against the clock, including the demo, and prepare answers to the likely questions ("What if two people borrow the same book?").
• Be honest about limits. Naming what does not work yet builds more trust than hiding it.

Developing and Documenting Algorithms

🎯 (SE-12-02, SE-12-09)

📌 Develop, construct and document algorithms

Before and during coding, write the key parts of your solution as algorithms, then keep them with your documentation so others can follow your logic.

• Develop: plan the logic in pseudocode or a flowchart before you write code.
• Construct: turn each algorithm into code, one subroutine at a time.
• Document: keep the final algorithms, with comments and a short description of inputs, outputs and purpose.

NESA's Course Specifications expect algorithms as pseudocode or flowcharts using the standard control structures. The March 2026 specifications show a nested IF as an ELSE that holds another IF, with one ENDIF for every IF. Write it that way.

Develop: plan the logic

Start with the decision rules. FR2 and FR3 say a loan needs an available book and a member under the limit. That is the decision tree from Part 2, now as an algorithm that returns a single value, so it is written as a function.

BEGIN CanIssueLoan (bookAvailable, activeLoans, allowed)
    IF bookAvailable = False THEN
        allowed = False
    ELSE
        IF activeLoans >= 5 THEN
            allowed = False
        ELSE
            allowed = True
        ENDIF
    ENDIF
END CanIssueLoan (bookAvailable, activeLoans, allowed)

Construct: turn it into code

Each algorithm becomes one function with the same name and the same decisions, so a reader can lay the pseudocode beside the code. A second algorithm, for a feature proposed for a later version (reserving a study room), uses a repetition and a condition with AND. Times are in minutes after midnight, and a new booking clashes if it starts before an existing one finishes and finishes after it starts.

BEGIN CheckClash (newRoom, newStart, newFinish, clash)
    clash = False
    FOR i = 1 TO bookingCount
        IF bookedRoom[i] = newRoom AND newStart < bookedFinish[i] AND newFinish > bookedStart[i] THEN
            clash = True
        ENDIF
    NEXT i
END CheckClash (newRoom, newStart, newFinish, clash)

def has_clash(new_room, new_start, new_finish, bookings):
    """Return True if the new booking overlaps an existing one in the same room.
    Times are minutes after midnight."""
    clash = False
    for room, start, finish in bookings:
        if room == new_room and new_start < finish and new_finish > start:
            clash = True
    return clash


bookings = [(2, 600, 660)]                 # room 2, 10:00 to 11:00
print(has_clash(2, 630, 690, bookings))    # 10:30 to 11:30  -> overlaps
print(has_clash(2, 660, 720, bookings))    # 11:00 to 12:00  -> starts as the other ends
print(has_clash(3, 630, 690, bookings))    # same time, different room

Expected output: True, False, False. The second case shows why the comparison uses < and >, not <= and >=: two bookings that only touch do not overlap. It is also a boundary test case.

Document: keep the algorithm with its evidence

An algorithm that is not kept with the project cannot be reviewed or maintained. For each important algorithm record:

Allocating Resources

🎯 (SE-12-06, SE-12-09)

📌 Allocate resources to support the development of a software engineering solution

Allocating resources means deciding what time, people, hardware, software and money each part of the project will get.

Worked example: allocating the 49 hours

Resources are allocated to tasks. This allocation puts the hours from the feasibility estimate against each task, with the tools and people each one needs, and keeps the contingency visible.

NESA's Gantt chart specification also notes that a chart can allocate team members to tasks and show each person's percentage completion. In a team, add a "who" column and update each person's percentage complete at every check.

Resource risks and responses

Programmed Data Backup

🎯 (SE-12-04, SE-12-09)

📌 Demonstrate the use of programmed data backup

A programmed data backup copies your data automatically on a schedule or before a risky change, so you don't have to remember to do it.

import shutil
from datetime import datetime

def programmed_backup(db_filepath, backup_directory):
    """Automates the backup of the project database with a timestamp."""
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    backup_file = f"{backup_directory}/db_backup_{timestamp}.sqlite3"
    
    try:
        shutil.copy2(db_filepath, backup_file)
        print(f"✅ Backup successful: {backup_file}")
    except IOError as e:
        print(f"❌ Backup failed: {e}")

# Execute backup before deploying a new feature
programmed_backup('app_data.sqlite3', './backups')

Planning what to back up

Decide the answers to five questions before writing any code. Together they make a backup strategy.

A more robust backup program

Copying a database file with shutil.copy2 can produce a damaged copy if the application is writing at that moment. SQLite has a built-in backup method that is safe on a live database. This version also checks the copy and prunes old backups.

import sqlite3
from datetime import datetime
from pathlib import Path

KEEP = 5   # how many backups to retain


def backup_database(db_path, backup_dir):
    """Copy a live SQLite database safely, check the copy, and prune old copies."""
    backup_dir = Path(backup_dir)
    backup_dir.mkdir(exist_ok=True)
    stamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    target = backup_dir / f"library_{stamp}.sqlite3"

    source = sqlite3.connect(db_path)
    copy = sqlite3.connect(target)
    try:
        source.backup(copy)                      # safe even while the app is running
        ok = copy.execute("PRAGMA integrity_check").fetchone()[0] == "ok"
    finally:
        copy.close()
        source.close()

    if not ok:
        target.unlink()
        raise RuntimeError("Backup failed its integrity check and was deleted")

    old = sorted(backup_dir.glob("library_*.sqlite3"))[:-KEEP]
    for path in old:
        path.unlink()
    return target


if __name__ == "__main__":
    print("Backup written to", backup_database("library.db", "backups"))

Expected output (the file name holds the date and time of the run): Backup written to backups/library_20260930_160000.sqlite3. After more than five runs the backups folder still holds only five files.

Running it automatically

A backup that depends on someone remembering will be forgotten. Ask the operating system to run the program on a schedule.

# Windows: run every day at 4 pm
schtasks /create /tn "LibraryBackup" /tr "python C:\LibraryLoans\backup.py" /sc daily /st 16:00

# Linux or macOS: add this line with crontab -e (minute hour day month weekday)
0 16 * * 1-5 python3 /home/library/LibraryLoans/backup.py

Prove the backup works: a restore check

import sqlite3


def count_members(backup_path):
    """Open a backup and confirm the data is really there."""
    db = sqlite3.connect(backup_path)
    try:
        return db.execute("SELECT COUNT(*) FROM members").fetchone()[0]
    finally:
        db.close()


print(count_members("backups/library_20260930_160000.sqlite3"))

Expected output: the number of members in the live system at the time of the backup (for a test database holding one member, 1). If it prints 0 or raises an error, the backup is not usable. Record the result of each restore test in the process diary.

Implementing Version Control

🎯 (SE-12-06, SE-12-09)

📌 Implement version control when developing a software engineering solution

Version control is a fundamental professional practice. Git allows engineers to track every change made to the codebase, revert to earlier versions if bugs are introduced, and collaborate without overwriting each other's work. The workflow below demonstrates the standard Git feature-branch workflow used in professional software engineering.

# ── INITIAL SETUP ──────────────────────────────────────────
# Initialise a new repository and make the first commit
git init library-management-system
cd library-management-system
git add README.md
git commit -m "Initial commit: project structure"

# ── FEATURE DEVELOPMENT ────────────────────────────────────
# Always create a new branch for each feature
git checkout -b feature/book-search

# After writing code, stage and commit your changes
git add src/search.py tests/test_search.py
git commit -m "Add book search by title and ISBN with unit tests"

# ── MERGING A FEATURE ──────────────────────────────────────
# Switch back to main and merge the completed feature
git checkout main
git merge feature/book-search --no-ff -m "Merge feature/book-search into main"

# ── USEFUL COMMANDS ────────────────────────────────────────
git log --oneline --graph    # View commit history as a graph
git diff HEAD~1 HEAD         # See changes since the last commit
git status                   # Check which files are staged/unstaged
git stash                    # Temporarily save uncommitted changes

# ── TAGGING A RELEASE ──────────────────────────────────────
git tag -a v1.0 -m "Version 1.0 — submitted for client review"
git push origin main --tags

Why use version control?

Branches, merges and a merge commit

After the feature-branch workflow above, the history looks like this. The merge commit has two parents, because --no-ff records that a branch was merged.

git log --oneline --graph
*   a3f9c21 Merge feature/loan-limit into main
|\
| * 5be0d47 Add can_borrow with loan limit check
|/
* 1c7a8e2 Initial commit: project structure

When two changes collide: a merge conflict

If the same line changes on two branches, Git cannot choose, so it stops the merge and marks the file. Suppose main lowered the limit to 4 while another branch raised it to 6:

git merge feature/limit-six
Auto-merging rules.py
CONFLICT (content): Merge conflict in rules.py
Automatic merge failed; fix conflicts and then commit the result.

# rules.py now contains:
<<<<<<< HEAD
MAX_LOANS = 4
=======
MAX_LOANS = 6
>>>>>>> feature/limit-six

Resolve it by deciding, not by picking a side automatically. The requirement (FR3) says the limit is 5, so neither is right. Edit the file to MAX_LOANS = 5, delete the three marker lines, then run git add rules.py and git commit. The Programming for the Web page covers this in more depth.

What not to commit, and how to write commits

• Keep secrets and data out of the repository. Passwords, API keys and the live database (library.db) do not belong in Git, and once pushed they are hard to remove. List them in a .gitignore file and keep keys in environment variables. A repository on GitHub can be public.
• One logical change per commit, with a message that says what and why: Fix off-by-one in can_borrow (BUG-002). Referring to the defect ID links the history to the defect log.
• Review before merging. A pull request lets a peer read the change, comment and approve it before it reaches main.
• Tag releases (git tag -a v1.0) so the exact version the client tested can always be recovered.

Responding to Difficulties

🎯 (SE-12-02, SE-12-04, SE-12-06, SE-12-09)

📌 Explore strategies to respond to difficulties when developing a software engineering solution

• looking for a solution online
• collaboration with peers
• outsourcing

Every project hits problems. What matters is how you respond:

• Looking for a solution online: start with official documentation, then trusted forums such as Stack Overflow. Test anything you find, and cite code you reuse.
• Collaboration with peers: explain the problem to a classmate or ask for a code review. Often, explaining the problem is enough to spot the bug.
• Outsourcing: use an existing service or library for a hard, non-core part, such as a payment provider or a login service.

Looking for a solution online

1. Read the error message and copy the last line exactly (for example KeyError: 'due'). Search for it with the name of the language or library.
2. Try official documentation first (docs.python.org, the library's own site), then established communities such as Stack Overflow.
3. Judge the source: is it recent, does it match your version, does an accepted answer explain why it works? An answer you do not understand is a risk.
4. Test it in isolation in a small file before it enters your project.
5. Acknowledge it: a comment with the URL and licence, and a process diary entry. Never paste passwords, real student data or the whole project into a public forum.

Collaboration with peers

• Explain the problem aloud to a classmate (often called rubber-duck debugging). Putting it into words often exposes the fault.
• Ask a good question: what you expected, what happened instead, what you already tried, and the smallest code that shows the problem.
• Pair on the difficulty: one person types while the other reads the logic, then swap.
• Ask for a code review when a fresh pair of eyes is needed; in the earlier example, a peer spotted the time zone error.
• Keep the work your own. A peer may explain and suggest, but you must write and understand your solution, and record the help in the process diary.

Outsourcing

Outsourcing means handing a part of the work to an outside provider: a library, a hosted service or API, or another person or company. The developer keeps the part that is specific to the client. It is sensible for a hard, well-solved, non-core part such as secure login, payments or maps. The trade-offs to weigh are cost, control, security and privacy (where the data goes), reliability of the supplier, licence terms, and the effort to connect it.

Worked example: a difficulty log

Proposing an Innovative Solution

🎯 (SE-12-02, SE-12-04, SE-12-06, SE-12-09)

📌 Propose an additional innovative solution using a prototype and user interface (UI) design

Once your main solution works, propose one further idea that would make it better. Show it as a prototype, such as a clickable Figma mock-up or a paper sketch, with a clear UI design. You don't need to build it; you need to show it is worth building.

• Describe the problem the idea solves, using evidence from feedback.
• Show the prototype screens and explain the UI choices, such as layout, colour, font size and accessibility.
• Explain how it would fit into the existing system.

From opportunity to proposal

1. Find the opportunity in evidence: feedback, the defect log, observation, or a feature that was outside the boundary (email reminders were).
2. Sketch quickly on paper to explore several layouts.
3. Make a wireframe (layout only), then a prototype that can be clicked through.
4. Test it with real users on a small task and record what happened.
5. Recommend whether to build it, with its cost, its benefit and its risks.

Worked example: the reminders proposal

Explain the UI choices

• Layout and hierarchy: the most common task (see my due dates) is first and largest.
• Consistency: the same button style and position on every screen, so users learn once.
• Feedback: a clear message after "Turn on reminders" says what will happen and when.
• Accessibility: text contrast of at least 4.5:1 for normal text (WCAG AA), meaning is never carried by colour alone (the overdue badge has the word "Overdue"), and every control can be reached with the keyboard.
• Simplicity: no feature on the screen that a first-time volunteer does not need.

Methodologies to Test and Evaluate Code

🎯 (SE-12-08, SE-12-09)

📌 Apply methodologies to test and evaluate code

Methods for testing a system

NESA's Course Specifications (p. 30) name six methods for testing a software solution that students are expected to know and understand. Each answers a different question.

Levels of testing: unit, integration, system, acceptance

Testing also happens at different levels as the pieces are put together. These four levels are standard industry terms (only acceptance testing is in NESA's list above). Together with the methods, they form a test strategy.

Test Data Table

A comprehensive test plan uses three categories of test data to verify correctness across all scenarios. Normal data tests typical valid inputs; boundary data tests values at the exact edges of valid ranges; invalid (erroneous) data tests inputs that should be rejected.

Boundary testing: choosing the data

Boundary testing tests the values on and either side of each limit, because mistakes in a comparison (< where <= was meant) show up only there. For a range, test the value just below the minimum, the minimum, just above it, a typical value, just below the maximum, the maximum and just above it. Add data of the wrong type and empty input.

Worked example (FR3): a member may hold at most 5 loans, so the valid values for the number of active loans before issuing are 0 to 4, and the member at 5 is refused. Test the edges of that rule.

The fine rule (FR6) has its own boundaries at 0 and 1 (overdue or not) and at 50 and 51 (cap or not), which are test cases 9 to 12 above.

Path testing: covering every route through the code

Path testing chooses test data so that every path through the code runs at least once, which means every branch of every IF. Count the paths from the algorithm: each decision splits the route.

Two decisions in a nested structure give three paths, not four, because the second decision is reached only when the first is false. Path testing and boundary testing are complementary: three well-chosen inputs cover all the paths, but only the boundary values 50 and 51 would catch a mistake such as >= 50. Both inputs return 1000, so only the path and the neighbouring inputs reveal the fault.

Unit tests in Python: expected against actual

Python's built-in unittest module runs test cases and compares each actual output with the expected one. The test methods below cover the boundaries and paths worked out above.

import unittest


def can_borrow(active_loans, limit=5):
    """A member may borrow only while they have fewer than the limit."""
    return active_loans < limit


def calculate_fine_cents(days_overdue):
    """Return the fine in cents: 20 cents a day, capped at 1000 (ten dollars)."""
    if days_overdue <= 0:
        fine = 0
    else:
        if days_overdue > 50:
            fine = 1000
        else:
            fine = days_overdue * 20
    return fine


class TestLoanRules(unittest.TestCase):
    def test_loan_limit_boundaries(self):
        self.assertTrue(can_borrow(4))      # one below the limit
        self.assertFalse(can_borrow(5))     # at the limit

    def test_fine_not_overdue(self):
        self.assertEqual(calculate_fine_cents(0), 0)
        self.assertEqual(calculate_fine_cents(-3), 0)

    def test_fine_below_cap(self):
        self.assertEqual(calculate_fine_cents(1), 20)
        self.assertEqual(calculate_fine_cents(50), 1000)

    def test_fine_capped(self):
        self.assertEqual(calculate_fine_cents(51), 1000)


if __name__ == "__main__":
    unittest.main(verbosity=2)

Expected output (the wording of the test names varies a little between Python versions):

test_fine_below_cap (__main__.TestLoanRules.test_fine_below_cap) ... ok
test_fine_capped (__main__.TestLoanRules.test_fine_capped) ... ok
test_fine_not_overdue (__main__.TestLoanRules.test_fine_not_overdue) ... ok
test_loan_limit_boundaries (__main__.TestLoanRules.test_loan_limit_boundaries) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.000s

OK

Defect Log

A defect log (also called a bug tracker or issue log) records every defect discovered during testing. Each entry includes enough information for the developer to reproduce and fix the defect. The defect log is evidence that you tested genuinely and responded to the results.

Code Review Checklist

A code review is the systematic examination of code by a peer before it is merged into the main branch. It catches bugs, ensures style consistency, and improves overall code quality. The checklist below should be applied during every code review in a collaborative project.

Debugging Process

Debugging is the systematic process of identifying, isolating, and fixing defects in code. A structured debugging process is faster and more reliable than randomly changing code and hoping for improvement.

Language-Dependent Code Optimisation

🎯 (SE-12-08, SE-12-09)

📌 Use a language-dependent code optimisation technique

A language-dependent optimisation uses a feature of your particular programming language to make code faster or clearer. In Python, list comprehensions and built-in functions such as sum() and sorted() run in optimised C code, so they are usually quicker than writing the same loop yourself. Measure before and after, for example with timeit, to show the change helped.

import unittest

# OPTIMISED CODE: Using list comprehension instead of a slow for-loop
def get_valid_ages(age_list):
    """Returns ages between 18 and 65 (inclusive) using fast list comprehension."""
    return [age for age in age_list if 18 <= age <= 65]

# TESTING: Applying boundary testing methodology
class TestAgeValidation(unittest.TestCase):
    def test_boundaries(self):
        # Boundary data: 17 (invalid), 18 (valid), 65 (valid), 66 (invalid)
        test_data = [17, 18, 40, 65, 66]
        expected_output = [18, 40, 65]
        actual_output = get_valid_ages(test_data)

        # Comparing actual output with expected output
        self.assertEqual(actual_output, expected_output)

if __name__ == '__main__':
    unittest.main()

Language-dependent and language-independent optimisation

A language-independent optimisation improves the algorithm or the data structure and works in any language: for example, searching a sorted list with binary search instead of scanning it. A language-dependent optimisation uses a feature of your language's design or standard library. In Python that means built-in functions written in optimised C, comprehensions, and the standard data types.

Worked example: measure before and after

The Library Loans catalogue searches by ISBN. Scanning a list of 10,000 books takes longer as the catalogue grows; a dictionary keyed by ISBN is a Python data type built for lookup. Use timeit to measure the difference instead of guessing.

import timeit

books = [{"isbn": str(9780000000000 + i), "title": f"Book {i}"} for i in range(10_000)]
target = books[-1]["isbn"]                       # worst case for a scan
by_isbn = {b["isbn"]: b for b in books}          # built once, when the catalogue loads


def scan():
    return next((b for b in books if b["isbn"] == target), None)


def lookup():
    return by_isbn.get(target)


assert scan() == lookup()                        # same answer: the optimisation is safe
print("scan  :", round(timeit.timeit(scan, number=200), 4), "seconds for 200 searches")
print("lookup:", round(timeit.timeit(lookup, number=200), 6), "seconds for 200 searches")

def total_loop(values):
    total = 0
    for v in values:
        total += v
    return total

data = list(range(100_000))
print("loop  :", round(timeit.timeit(lambda: total_loop(data), number=100), 3))
print("sum() :", round(timeit.timeit(lambda: sum(data), number=100), 3))

Expected output: four lines of timings. The exact numbers depend on the computer, so record your own. In a test run the dictionary lookup was thousands of times faster than the scan, and sum() was several times faster than the hand-written loop. The assert line matters as much as the timings: an optimisation that changes the answer is a defect.

Rules for optimising

1. Make it correct first. Optimise only code that passes its tests.
2. Measure, then change. Record the timing before and after, on the same data.
3. Re-run the tests after every optimisation, to show behaviour is unchanged.
4. Do not trade away readability for a trivial gain. Optimise where a requirement (such as NFR1's 2 seconds) is at risk.

Analysing and Responding to Feedback

🎯 (SE-12-08, SE-12-09)

📌 Analyse and respond to feedback

Feedback from your client, users and peers shows how well the solution meets its requirements. Analyse it to find patterns, then respond by deciding what to change, what to schedule for later and what to explain.

Turning feedback into action

1. Collect: use the same short questions after each round, such as a 1–5 ease-of-use rating plus one open question.
2. Group: sort comments into usability, bugs, performance and new features.
3. Prioritise: fix what blocks users first; schedule features for later versions.
4. Respond: tell users what changed, and retest to check the fix worked.

Sources and types of feedback

Feedback can be quantitative (a rating, a time, a count) or qualitative (a comment). Use both: numbers show how big a problem is, comments show what it is.

Worked example: analysing survey results

Eight testers each rate ease of use from 1 (very hard) to 5 (very easy), before and after the navigation was changed to make the loan history easier to find.

from statistics import mean

before = [3, 3, 4, 2, 3, 4, 3, 3]
after = [4, 5, 4, 4, 5, 4, 5, 4]
print(round(mean(before), 1), round(mean(after), 1))
print(sum(1 for r in before if r <= 3), "of", len(before), "rated 3 or lower before")

Expected output: 3.1 4.4, then 6 of 8 rated 3 or lower before. The mean rose by 1.3, and every tester's rating stayed the same or improved. With only eight testers this is evidence of improvement, not proof, and the report should say so.

Prioritising the response

Finally, respond to the people who gave the feedback: report what changed, what did not, and why. Record each item in the process diary or a feedback log.

Evaluating the Effectiveness of Your Solution

🎯 (SE-12-08, SE-12-09)

📌 Evaluate the effectiveness of a software engineering solution

• developing a report to synthesise feedback
• developing a test plan
• testing data used/generated based on path and boundary testing
• comparing actual output with expected output

Effectiveness & Testing Data

Evaluation involves generating a test plan and executing it using rigorous testing data based on path testing (ensuring every path through the code, and so every branch, executes at least once) and boundary testing (testing the extreme limits of input constraints). Engineers evaluate success by comparing actual output with expected output, and develop a final report to synthesise client feedback.

Test Plan Template

A test plan is a document that outlines the testing strategy, scope, resources, schedule, and exit criteria for a software project. It is prepared before testing begins to ensure testing is systematic and complete.

Comparing actual output with expected output

Every test case has an expected output, written from the requirement before the test is run, and an actual output, recorded when it is run. A test passes only when they match. A mismatch is the start of debugging, not the end of testing. The unit test below is what BUG-002 looked like before it was fixed.

import unittest


def can_borrow(active_loans, limit=5):
    return active_loans <= limit     # the bug


class TestLoanRules(unittest.TestCase):
    def test_loan_limit_boundaries(self):
        self.assertFalse(can_borrow(5))


if __name__ == "__main__":
    unittest.main()

Output:

FAIL: test_loan_limit_boundaries (__main__.TestLoanRules.test_loan_limit_boundaries)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "loans_test.py", line 10, in test_loan_limit_boundaries
    self.assertFalse(can_borrow(5))
AssertionError: True is not false

Ran 1 test in 0.000s

FAILED (failures=1)

Read it as: expected False (the member is at the limit), actual True. The traceback names the test and the line. After the fix (<= changed to <) the same test passes, and it stays in the suite so the defect cannot quietly return (regression testing).

Evaluating Against Requirements

A thorough evaluation compares what you built against what you planned from Phase 1. For each functional and non-functional requirement, document:

• Was this requirement fully met? Partially? Not met?
• What evidence demonstrates it is met? (test results, user feedback, system output)
• If not fully met, what limited the implementation?

Developing an Evaluation Report

Your evaluation report should synthesise all feedback gathered throughout the project and systematically compare actual outputs with expected outcomes. This includes:

• Requirement Coverage: Use your original requirements document and reference each requirement by number, demonstrating which were fully met, partially met, or deferred.
• Testing Evidence: Present test results showing how the system behaves against your test data (path and boundary testing cases).
• User Feedback: Document feedback from the client or stakeholders about whether the system meets their needs.
• Technical Evaluation: Discuss decisions made, challenges encountered, and how they were addressed.

To synthesise feedback is to combine several sources into a few conclusions, not to list each comment. A worked excerpt for Library Loans:

Feedback came from Mrs Chen (two reviews and the acceptance test), two volunteers (observed tasks) and eight testers (a rating survey). Three themes appeared across sources. (1) Findability: five of eight testers could not find the loan history; after the menu change the mean ease-of-use rating rose from 3.1 to 4.4. (2) Speed: Mrs Chen and two testers said search felt slow, and a timed test confirmed 4 seconds against the 2-second target (NFR1); an index reduced this to 0.3 seconds. (3) Missing reminders: raised by Mrs Chen and three testers. This is outside the version 1 boundary, so it is recommended for version 2, after a privacy review. Because the sample was small, these results show a likely improvement, not a certain one.

Evaluation Criteria Checklist

The final evaluation assesses whether the solution meets the original requirements. Evaluation must address every requirement documented in Phase 1, referencing specific test results and client feedback as evidence.

Evaluating means making a judgement

NESA's syllabus glossary defines evaluate as "make a judgement based on criteria; determine the value of." So an evaluation needs criteria (the requirements and quality targets set in Part 1), evidence against each, and an overall judgement with reasons. A worked judgement for Library Loans:

Overall, Library Loans is an effective solution. All Must requirements (FR1 to FR5, NFR1, NFR2) were met and verified: 13 of 13 test cases pass, search takes 0.3 seconds against a 2-second target, and no plaintext passwords are stored. The client accepted the system, and the evaluation also found limits. Usability (NFR3) was met in a timed walkthrough with one volunteer only, so it is less certain for other users. Fines are recorded but not paid through the system, which Mrs Chen still handles by hand. The most valuable improvement would be due-date reminders, which the prototype tests suggest students would use.

Post-project review

After delivery, review the process as well as the product, so the next project is better. Compare the plan with what happened and record lessons that can be acted on.