The system development life cycle in HSC Information Processes and Technology
“Describe the traditional stages of the system development life cycle (understanding the problem, planning, designing, implementing, testing, evaluating and maintaining) and the approaches used to build new information systems”
The system development life cycle (SDLC) is the structured set of stages a team follows to build an information system: understanding the problem, making decisions and planning, designing solutions, implementing, testing and evaluating, and maintaining. Understanding defines requirements; planning schedules the work and chooses a solution; designing produces the detailed specifications; implementing builds and installs the system; testing and evaluating check it meets requirements; and maintenance keeps it working and adapts it over time. The classic waterfall runs these once in order, while prototyping, agile and outsourcing offer faster or more flexible alternatives.
Jump to a section
Legacy course. This page covers HSC Information Processes and Technology (IPT), which NESA has replaced. The last IPT HSC exam was held in 2024; current students study Enterprise Computing 11-12 or Software Engineering 11-12 (first HSC exams in 2025). See the IPT hub for what carries over, or our HSC Software Engineering hub. Use this page as background only.
What this dot point is asking
NESA wants you to describe the traditional stages a project team works through when it builds a new information system, in order, and to explain what happens in each. You also need to recognise that the strict sequence is one approach among several, and that real projects often iterate, prototype or build in parallel rather than march through the stages once.
The answer
Why a life cycle exists
Building an information system is large and risky. A life cycle breaks the work into ordered stages so the team always knows what to do next, can schedule and budget the project, and can check progress against a plan. Each stage produces outputs (documents, designs, code) that feed the next.
The traditional stages
- Understanding the problem
- The team works out what the new system must do. They identify the requirements by interviewing users, observing the current system, examining documents and issuing questionnaires. The output is a clear statement of the problem and the requirements the solution must satisfy.
- Making decisions and planning
- The team decides whether and how to proceed, weighing feasibility (technical, economic, operational and schedule). They choose a development approach, schedule the work with Gantt charts, allocate people and funds, and set milestones. Planning produces the project plan that controls the rest of the cycle.
- Designing solutions
- The team specifies the system in detail: the data and its structure (database schemas, data dictionaries), the information processes, the user interface, and the hardware and software. Design turns the requirements into a blueprint precise enough to build from.
- Implementing
- The system is built and installed. This includes acquiring hardware and software, writing or configuring software, converting existing data, and choosing a conversion method (direct, parallel, phased or pilot) to switch from the old system to the new one. Participants are trained and documentation is written.
- Testing, evaluating and maintaining
- Testing checks the system works correctly against the requirements, using real and boundary data. Evaluation asks whether the finished system actually solved the original problem and met user needs. Maintenance then corrects faults found in use, adapts the system to changing needs, and improves it, often looping back into earlier stages.
Development approaches
The waterfall approach runs the stages once, strictly in order, with each stage completed before the next begins. It is simple to manage but inflexible: a requirement missed early is expensive to fix late.
Prototyping builds a working model of part of the system early, so users can react to something concrete. Their feedback refines the requirements before the full system is built, reducing the risk of building the wrong thing.
Other approaches include the agile or iterative style, which develops the system in small repeated cycles delivering working features often, and outsourcing or buying a customised off-the-shelf package instead of building from scratch. Each trades off speed, cost, control and flexibility.
The conversion method chosen at implementation matters for risk. Parallel conversion runs the old and new systems together so the old one is a safety net, but it doubles the running cost. Direct (or crash) conversion switches over instantly: cheap, but with no fallback if the new system fails.
How the stages map to the project tools
The planning stage is where Gantt charts, the project journal, scheduling and funding decisions live; those tools are covered in the project tools dot point. The life cycle is the larger frame that those tools serve, and the social and ethical responsibilities apply at every stage, especially design and implementation.
Listing the stages without describing what happens in each. NESA marks the content of a stage (requirements gathering, feasibility, conversion), not just the label.
Treating the waterfall as the only model. Prototyping, agile and outsourcing are legitimate approaches; describing alternatives shows real understanding.
Confusing testing with evaluation. Testing checks the system works correctly; evaluation checks it solved the original problem and met user needs. They answer different questions.
Forgetting maintenance. The cycle does not end at install; maintenance is a named stage and often loops back into design.
Mixing up conversion methods. Parallel keeps both systems running; pilot installs in one area first; phased introduces parts over time; direct switches instantly. Name the right one for the scenario.
Exam-style questions
Questions in the style of NESA exam questions on this dot point, each with a worked answer. They are written by ExamExplained unless tagged "Past paper"; the year shows the paper a question is modelled on.
2019 HSC-style3 marksA gym wants to develop a mobile app to automate customer payments and gym class bookings within six months and to work with the gym's existing programs. Describe risks that should be considered in the feasibility study of this project.Show worked answer →
Feasibility is assessed early in understanding the problem and planning. For 3 marks describe three risks across the recognised feasibility types and tie each to the gym.
Schedule risk. The six month deadline is tight, so there is a risk the app cannot be built, tested and converted in time, which would delay the promotion and bookings.
Technical risk. The app must integrate with the gym's existing payment and booking programs, so there is a risk those systems are incompatible or cannot exchange data reliably.
Operational and economic risk. There is a risk members will not adopt the app or that development and maintenance cost more than the savings from automation, making the project not worthwhile.
Markers reward naming feasibility categories and linking each risk to this specific project rather than listing risks in the abstract.
2020 HSC-style3 marksParents currently order and pay for school items at the office. A new system will let parents order and pay using their mobile phone. How could the prototyping approach be used to develop the new system?Show worked answer →
Prototyping is a development approach where a working model is built early, shown to users, and refined through repeated cycles. For 3 marks describe how it would be applied here.
Build an early model. Developers build a basic prototype of the ordering and payment screens so parents and school staff can see and use a working version quickly rather than waiting for the finished system.
Gather feedback and refine. Parents trial the prototype and give feedback on usability (for example how easy it is to select items and pay), and developers refine the prototype over several iterations.
Confirm requirements. Each cycle clarifies the real requirements, reducing the risk of building the wrong system, and the refined prototype can evolve into the final ordering and payment system.
Markers reward the iterative build, feedback and refine cycle applied to this ordering system.
2020 HSC-style1 markA university wants to engage a technology specialist to update its online learning system and also wants to give input and refine its requirements during development. Which combination of development approaches should the university use? (Outsourcing and agile / Outsourcing and traditional / Participant development and agile / Participant development and traditional.)Show worked answer →
The answer is "Outsourcing and agile."
Outsourcing is correct because the university wants to engage an external technology specialist to carry out the work rather than build it with in-house staff.
Agile is correct because the university wants to give input and refine its requirements throughout development. Agile delivers the system in short iterations with continuous client feedback, which suits changing or evolving requirements, whereas the traditional approach fixes requirements up front. Participant development would mean the university's own people build the system, which contradicts engaging a specialist.