What are the stages of the system development life cycle and how does a team move a project through them?
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
A focused answer to the HSC Information Processes and Technology dot point on the system development life cycle. The stages from understanding the problem to maintenance, prototyping and other development approaches, and the traps markers look for.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
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.
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.
Exam-style practice questions
Practice questions written in the style of NESA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
2019 HSC3 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 HSC3 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 HSC1 marksA 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.