← Module 4: Software Engineering Project
Inquiry Question 1: How are large-scale software solutions developed and managed?
Compare software development methodologies, including waterfall, agile and scrum, and identify when each is appropriate
A focused answer to the HSC Software Engineering Module 4 dot point on development methodologies. Waterfall, agile, scrum, kanban, when each is appropriate, the worked example, and the traps markers look for.
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to compare the dominant software development methodologies, name their phases or ceremonies, and identify the project contexts in which each is appropriate. Waterfall and agile (with scrum as the most common agile variant) are the two you must know in depth.
The answer
Waterfall
A sequential methodology. The project flows downstream through fixed phases:
- Requirements: capture every functional and non-functional requirement.
- Design: produce architecture, data model and detailed design documents.
- Implementation: write the code.
- Verification (testing): confirm the implementation meets the requirements.
- Deployment: ship to production.
- Maintenance: bug fixes and changes go through formal change control.
Phase exit gates require sign-off documents. Changes to earlier phases require formal change requests.
Strengths: predictable plan, clear deliverables, suits regulated and contracting environments where every requirement must be traceable.
Weaknesses: assumes requirements are known up front, late discovery of defects is expensive, no working software until late in the project, struggles when requirements change.
When to use: building regulations, defence procurement, certified medical devices, anything with a fully specified contract.
Agile
An iterative, incremental methodology. The project is broken into short iterations (1-4 weeks). Each iteration delivers a working slice of software.
The Agile Manifesto (2001) values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile is a family of methodologies. The most common variants:
- Scrum: fixed-length sprints, defined roles (product owner, scrum master, dev team), ceremonies (planning, daily stand-up, review, retrospective).
- Kanban: continuous flow, visual board, work-in-progress limits, no fixed sprint.
- Extreme Programming (XP): heavy emphasis on engineering practices (pair programming, TDD, continuous integration).
Scrum in detail
The most widely used agile variant:
Roles
- Product Owner: decides what to build, prioritises the backlog.
- Scrum Master: facilitates the process, removes blockers.
- Development Team: builds the increment.
Artefacts
- Product backlog: prioritised list of all work, owned by the product owner.
- Sprint backlog: items selected for the current sprint.
- Increment: the working software produced this sprint.
Ceremonies (per sprint, typically 2 weeks)
- Sprint planning at the start: the team commits to a sprint goal and selects backlog items.
- Daily stand-up (15 minutes): each member shares what they did, what they will do, and any blockers.
- Sprint review at the end: demo the increment to stakeholders.
- Sprint retrospective: the team reflects on what to improve.
Kanban in detail
Continuous flow, no fixed sprint. The team maintains a visual board with columns (To do, In progress, In review, Done) and a work-in-progress (WIP) limit per column. Items flow through the board as capacity allows.
Strengths: minimal ceremony, easy to start, great for support and operations work where priorities change daily.
Weaknesses: no built-in checkpoint for stakeholders, less predictable timelines.
When to choose what
| Project shape | Methodology |
|---|---|
| Fully specified contract, regulated industry, stable requirements | Waterfall |
| Customer-facing product, fast-changing market, early user feedback valuable | Scrum |
| Support team, operations work, continuous flow of small items | Kanban |
| Strong engineering culture, willing team, tight feedback loop | XP (often inside scrum) |
Most real teams pick a base methodology and adapt. A scrum team may also use kanban for support tickets. A waterfall project may use agile sprints inside the implementation phase.
Hybrid approaches
- Scrumban: scrum's roles and ceremonies with kanban's WIP limits.
- SAFe (Scaled Agile Framework): scrum coordinated across many teams in a large enterprise.
- Hybrid waterfall-agile: high-level waterfall plan for the year, agile sprints inside each milestone.
A worked example
A two-person team building a study app. They choose scrum:
- 2-week sprints.
- A shared GitHub issue board as the backlog.
- Daily 10-minute video stand-up.
- End-of-sprint demo to their teacher (the product owner stand-in).
- Retrospective notes in a shared doc.
After three sprints they have a working app with login, study sessions, and progress tracking. Each sprint delivered something usable, even if the full feature set is not yet complete. They can re-prioritise the backlog if user feedback suggests a different next feature.
Past exam questions, worked
Real questions from past NESA papers on this dot point, with our answer explainer.
2024 HSC6 marksCompare the waterfall and agile software development methodologies. For each, identify a project type where it would be appropriate and one where it would not.Show worked answer →
Waterfall is a sequential methodology. The project moves through fixed phases in order: requirements, design, implementation, testing, deployment, maintenance. Each phase produces documents that feed the next. You do not revisit earlier phases without a formal change request.
Appropriate: a defence contract with fixed requirements, a building regulation system where the rules are legally locked, embedded firmware for a medical device where every requirement must be traceable.
Not appropriate: a new consumer web app where user feedback will reshape priorities, a startup MVP where the product is still being discovered, any environment where requirements change faster than the project plan can be updated.
Agile is iterative. The project is broken into short iterations (typically 1-4 weeks). Each iteration produces a working slice of software. Requirements are revisited continuously. The team reflects after each iteration and adjusts.
Appropriate: a customer-facing app whose users will be invited to use early versions and give feedback, a digital product whose competitive landscape changes monthly, a team that needs to deliver value within months not years.
Not appropriate: contracts that require a fully specified deliverable up front, regulated environments that demand documented sign-off at each phase, safety-critical systems where each change requires formal verification.
Markers reward both methodologies named correctly, their core mechanic (sequential vs iterative), concrete suitability examples, and the recognition that methodology choice depends on requirements stability, regulatory context, and team size.
Related dot points
- Use version control to manage source code, including commits, branches, merges, pull requests and remote repositories
A focused answer to the HSC Software Engineering Module 4 dot point on Git. Commits, branches, merges, pull requests, the worked feature-branch workflow, and the traps markers look for.
- Describe testing strategies, including unit testing, integration testing, system testing and user acceptance testing
A focused answer to the HSC Software Engineering Module 4 dot point on testing. Unit, integration, system, UAT, the test pyramid, test-driven development, the worked Python example, and the traps markers look for.
- Use project management tools to plan, track and communicate work across a software team, including issue trackers, Kanban boards and Gantt charts
A focused answer to the HSC Software Engineering Module 4 dot point on project management tools. Issue trackers (GitHub Issues, Jira), Kanban boards, Gantt charts, the worked example, and the traps markers look for.