SDLC — Software Development Life Cycle | HSC Software Engineering

Overview 🔄 The Software Development Life Cycle

🔄 What is the SDLC?

🎯 (SE-11-01, SE-12-01, SE-12-06 — applies across the entire course)

📌 The SDLC is the structured process software engineers follow to plan, create, test, and deliver software. Every topic in the HSC Software Engineering course is anchored to at least one phase of this cycle.

The NESA NSW HSC Software Engineering syllabus explicitly structures the Software Engineering Project (Year 12) around four cyclical phases. However, the same cycle underpins all other topics — from Programming Fundamentals in Year 11 to Secure Software Architecture and Software Automation in Year 12. Understanding where you are in the cycle at any moment is key to demonstrating depth in both exams and the major project.

🎯

Identifying & Defining

Problem analysis, requirements, feasibility

→

🔬

Research & Planning

Design, architecture, project scheduling

→

💻

Producing & Implementing

Coding, integration, documentation

→

🧪

Testing & Evaluating

Validation, evaluation, maintenance

Cycle, Not Waterfall: The phases are a cycle — after evaluating, you loop back to identifying new requirements or improvements. In Agile approaches this loop happens every sprint (2–4 weeks). In WAGILE approaches you may complete a full pass through all four phases before cycling back. Assessors reward students who articulate this iterative nature.

📌 Where the SDLC Appears Across the Course

Topic	Year	Primary SDLC Phase(s)	Key Syllabus Concepts
Programming Fundamentals	11	Phase 1 (defining the problem), Phase 3 (coding)	Problem definition, algorithm design, data types, testing
Object-Oriented Paradigm	11	Phase 2 (design), Phase 3 (implementation)	Class design, UML, encapsulation, inheritance, polymorphism
Programming Mechatronics	11	All phases — applied to hardware/software integration	Sensor input, actuator output, control logic, testing with real devices
Secure Software Architecture	12	Phase 2 (security design), Phase 4 (security testing)	Threat modelling, CIA triad, authentication, encryption, penetration testing
Programming for the Web	12	Phase 2 (UI/UX design), Phase 3 (front/back-end coding)	HTML/CSS/JS, HTTP, REST APIs, databases, accessibility
Software Automation	12	Phase 2 (automation design), Phase 3 & 4 (implementation and testing)	Scripting, batch processing, scheduling, MLOps pipelines
Software Engineering Project	12	All four phases — explicitly structured around the cycle	Full SDLC applied to an original major project with documentation

Methodology ⚖️ Agile vs WAGILE

⚖️ Agile vs WAGILE — Choosing Your Methodology

🎯 (SE-12-02 — evaluate and justify development approaches)

📌 A methodology determines how you move through the SDLC phases. Selecting the right one — and being able to justify your selection to assessors — is a key syllabus requirement.

Agile

🏃 Agile (Iterative/Incremental)

Work is divided into short sprints (2–4 weeks). Each sprint produces a working, shippable increment. Requirements are expected to evolve — change is welcomed, not resisted.

Frequent client feedback after each sprint
Backlog of user stories prioritised each sprint
Daily stand-ups for team coordination
Working software over comprehensive documentation
Cross-functional, self-organising teams
Retrospectives after each sprint to improve the process

WAGILE (Waterfall-Agile Hybrid)

🌊 WAGILE (Structured Iterations)

A pragmatic hybrid used widely in the HSC project context. Phases are planned in advance (Waterfall-style) but internal to each phase, short Agile iterations are used to build and refine features.

Upfront planning document (Gantt chart, project scope)
Each SDLC phase has defined deliverables and deadlines
Within each phase: short iterative development cycles
Client check-ins at phase boundaries, not every sprint
Suits HSC assessment because deliverables align with marking criteria
Change requests are controlled via a formal change-request log

🤔 When to Use Each Methodology

Decision Guide — Agile vs WAGILE

Use Agile when...

Requirements are unclear or likely to change significantly. The client is highly available for regular feedback. The team is experienced and self-managing. The product is new with high uncertainty (startups, R&D projects). There is no fixed scope deadline.

Use WAGILE when...

There is a fixed deadline with defined deliverables (like the HSC major project). The client is not available every week. You need a clear paper trail of design decisions for assessors. Requirements are reasonably stable but refinement is needed during implementation.

Real-world examples

Spotify (music streaming), Atlassian Jira, Facebook feature rollouts, Google Chrome release cadence.

Real-world examples

NASA's Orion spacecraft software, enterprise banking systems, Australian government digital services, hospital management platforms.

📝 Assessor Tip — Justify Your Choice: Do not just state "I used Agile." Assessors expect you to justify your methodology choice with reference to project characteristics — scope certainty, client availability, team size, and timeline constraints. A student who correctly identifies that their HSC project is best served by WAGILE and explains why will always outperform one who copies the word "Agile" without explanation.

🔁 Scrum Framework (Agile in Practice)

Most HSC students and industry teams implement Agile via the Scrum framework. Understanding Scrum's mechanics is essential for both exam responses and project documentation.

📋 Product BacklogA prioritised list of all features, user stories, and bug fixes the product needs. Maintained by the Product Owner. Items at the top are most refined and ready to work on.

🏃 SprintA fixed time-box (2–4 weeks) during which a "Done" increment of the product is created. The sprint goal is agreed before it begins and does not change mid-sprint.

📌 Sprint BacklogThe subset of Product Backlog items selected for the current sprint, plus the plan for how to deliver them.

☀️ Daily Stand-upA 15-minute synchronisation event. Each team member answers: (1) What did I do yesterday? (2) What will I do today? (3) Are there any impediments?

🔍 Sprint ReviewAt the end of each sprint, the team demonstrates the working increment to stakeholders and collects feedback to refine the backlog.

🪞 Sprint RetrospectiveThe team inspects its own process and identifies improvements for the next sprint. Focuses on people, relationships, process, and tools.

Phase 1 🎯 Identifying and Defining

🎯 Phase 1 — Identifying and Defining

🎯 (SE-12-01, SE-12-06 — defining the problem space and requirements)

📌 The purpose of Phase 1 is to establish a clear, bounded understanding of the problem before any design or code begins. Software built without a well-defined problem statement routinely fails.

🔍 What You Must Demonstrate in This Phase

Problem Identification

Clearly describe the real-world need or opportunity the software addresses. Use evidence (surveys, observations, interviews with a client/stakeholder). Avoid vague statements like "people need an app."

Feasibility Analysis

Assess whether the project is viable across three dimensions: scheduling feasibility (can it be built in the available time?), financial feasibility (are required tools/resources available?), and technical feasibility (does the team have the skills?).

Requirements Elicitation

Document both functional requirements (what the system must do) and non-functional requirements (performance, security, usability, maintainability). Use user stories in the format: "As a [role], I want [feature] so that [benefit]."

Scope Definition

Explicitly state what is in scope and what is out of scope. This prevents scope creep during development. Record scope decisions in a project scope statement.

Data Requirements

Identify the types of data the system will use, store, and process. Begin drafting a data dictionary with field names, data types, sizes, and validation rules.

🛠️ Course Tools Used in Phase 1

📝 StoryboardsSketch the user interface flow and screen transitions before writing any code. Assessors expect to see storyboards for every major screen/view.

🗄️ Data DictionariesFormally define every data field — name, type, size, range, required/optional, and description. This ensures design consistency and is a mandatory deliverable for the major project.

📊 Use Case DiagramsShow all actors (users, external systems) and the functions they interact with. Particularly important for identifying which stakeholders drive which requirements.

🧠 Mind MapsBrainstorm and organise initial ideas, feature clusters, and stakeholder categories before writing formal requirements.

📋 User Stories / Acceptance CriteriaUser stories anchor requirements to real user needs. Each story must be accompanied by measurable acceptance criteria for assessors to evaluate completeness.

📝 How to Demonstrate Phase 1 Knowledge in an Exam: When given a scenario, apply the structure: (1) identify the problem clearly, (2) assess feasibility, (3) list both functional AND non-functional requirements, and (4) define scope. Use SMART criteria — requirements must be Specific, Measurable, Achievable, Realistic, and Time-bound. Award yourself marks for each distinct concept named and applied, not just listed.

Phase 2 🔬 Research and Planning

🔬 Phase 2 — Research and Planning

🎯 (SE-12-02, SE-12-03, SE-12-04 — design, architecture, and project management)

📌 Phase 2 transforms requirements into a blueprint. This is the design phase — you decide how the system will be built before writing a single line of production code. Time invested here is always recovered in Phase 3.

🏗️ What You Must Demonstrate in This Phase

Software Architecture and Design

Choose an appropriate architecture pattern (e.g., layered, client-server, MVC). Decompose the system into modules using a structure chart. Define how modules interact (interfaces, data flow).

Algorithm Design

Design the logic of key algorithms using pseudocode or flowcharts before coding begins. Pseudocode is preferred for written exam responses; flowcharts are valuable for visual documentation in the major project.

Object-Oriented Design

Produce class diagrams showing attributes, methods, and relationships (inheritance, association, composition). Identify encapsulation boundaries and access modifiers.

Data Design

Design the database schema (entity-relationship diagram), normalise tables to at least 3NF, and finalise the data dictionary from Phase 1. Define SQL statements for core operations (CREATE, INSERT, SELECT, UPDATE, DELETE).

Project Management Plan

Create a Gantt chart showing tasks, durations, dependencies, and milestones. Assign responsibilities if working in a team. Define communication channels (e.g., GitHub Issues, Slack, meeting minutes).

Security Architecture

Identify threats using a model such as STRIDE. Define security controls for authentication, authorisation, input validation, and data encryption. This is particularly important for Year 12 Secure Software Architecture outcomes.

Test Plan

Draft a test plan before coding so you know what "done" looks like. Define test cases for functional requirements, specifying test data (normal, boundary, erroneous) and expected results.

🛠️ Course Tools Used in Phase 2

📐 Structure ChartsDecompose the system into modules and show their hierarchical relationships and data passing. Required for the major project and assessed in exams.

💬 PseudocodeLanguage-independent algorithm description. Write pseudocode for all major algorithms before coding them. Examiners strongly prefer pseudocode to actual code in written responses.

🔀 FlowchartsVisualise the control flow of an algorithm — decisions, loops, and processes. Use standard ANSI/ISO flowchart symbols.

🧩 Class Diagrams (UML)Show classes, attributes, methods, and relationships (inheritance, association). Essential for documenting OO designs in both Year 11 OOP and Year 12 major project.

🗃️ Entity Relationship Diagrams (ERDs)Show tables, fields, primary/foreign keys, and relationships (one-to-one, one-to-many, many-to-many). Required wherever a relational database is used.

📅 Gantt ChartsVisualise project schedule with tasks, durations, dependencies, and milestones. Tools: MS Project, Trello, Excel, Canva. A completed vs planned Gantt comparison is excellent evidence for evaluation.

🔄 Data Flow Diagrams (DFDs)Show how data moves through the system — external entities, processes, data stores, and data flows. DFDs are a NESA-specified tool (Course Spec p. 8). Level 0 (context diagram) and Level 1 DFDs are required.

🛡️ Threat Modelling (STRIDE)Identify and categorise security threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Used in Secure Software Architecture.

📝 How to Demonstrate Phase 2 Knowledge in an Exam: For design questions, always show your thinking at two levels: (1) the high-level architectural decision (which pattern, why), and (2) the detailed design artifact (draw a structure chart, write pseudocode, sketch a class diagram). Exam responses that jump straight to code without a design step miss the syllabus intent entirely.

Phase 3 💻 Producing and Implementing

💻 Phase 3 — Producing and Implementing

🎯 (SE-12-05, SE-12-07 — software construction, coding standards, version control)

📌 Phase 3 is construction. Requirements and design are translated into working software. Quality is built in — not tested in later. Following coding standards, using version control, and writing maintainable code are non-negotiable syllabus requirements.

💡 What You Must Demonstrate in This Phase

Coding Standards and Style

Follow a recognised style guide consistently (PEP 8 for Python). Use meaningful variable/function names, consistent indentation, and appropriate comments. Assessors look for evidence of professional coding practice, not just working code.

Modular Implementation

Implement the structure chart from Phase 2 as actual modules, classes, or functions. Each module should have a single responsibility (SRP). Show the mapping between your design and your code in documentation.

Version Control

Use Git with meaningful, atomic commit messages throughout development. A well-maintained commit history demonstrates professional process. Branching for features and merging via pull requests is considered best practice.

Input Validation and Error Handling

Validate all user inputs against defined rules (data type, range, format). Implement appropriate error handling to prevent crashes and provide meaningful feedback. Never trust user input.

Security Implementation

Implement the security controls designed in Phase 2: password hashing (bcrypt, not MD5/SHA-1), parameterised SQL queries (prevent SQL injection), HTTPS, session management. For Year 12 Secure Software Architecture, this phase is the core deliverable.

User Interface Implementation

Build the UI following the storyboards from Phase 1. Apply usability principles: consistency, feedback, error prevention, recognition over recall (Nielsen's heuristics). Accessibility (WCAG 2.1 AA) is required for web-based projects.

Documentation

Write docstrings for all functions/classes. Maintain an inline comment strategy for non-obvious logic. Update the data dictionary if the schema evolves. Produce an installation/deployment guide.

🛠️ Course Tools Used in Phase 3

🐍 Python (or chosen language)The primary implementation language for HSC projects. Must be used with PEP 8 style, docstrings, and modular design. OOP features (classes, inheritance) are expected in Year 12 submissions.

🔀 Git / Version ControlAll code must be tracked with Git. Commit messages should be descriptive and atomic. Provide the repository URL or a commit log extract as project evidence.

🗄️ SQL (SQLite / PostgreSQL)Use parameterised queries to prevent SQL injection. Implement the schema from the ERD designed in Phase 2. Include CREATE TABLE, INSERT, SELECT (with JOINs), UPDATE, DELETE statements with explanations.

🌐 HTML / CSS / JavaScriptFor web-based projects. HTML for structure (semantic elements), CSS for presentation (responsive design), JavaScript for client-side behaviour. Must follow web standards and accessibility guidelines.

🧪 Unit Test StubsWrite test stubs alongside your code (test-driven development approach). Importing Python's unittest module and writing test cases alongside implementation is highly regarded by assessors.

🛠️ IDE ToolsUse VS Code or PyCharm with linting, debugging, and version control integration. Demonstrate awareness of how the IDE supports professional development practice.

📝 How to Demonstrate Phase 3 Knowledge in an Exam: When writing or reading code in exam contexts, always annotate your reasoning: name the programming construct used (loop, selection, function, class), explain its purpose, and connect it to the requirement it satisfies. A line of code without context earns fewer marks than explained code. Show understanding of why a construct was chosen, not just what it does.

Phase 4 🧪 Testing and Evaluating

🧪 Phase 4 — Testing and Evaluating

🎯 (SE-12-08, SE-12-09 — testing, evaluation, and reflection)

📌 Phase 4 validates the software against requirements and evaluates the entire development process. It is not a formality — assessors expect systematic, evidence-based testing and a critical, honest evaluation that identifies both strengths and limitations.

🧩 Testing Types — Know All Four

Testing Type	What is Tested	Who Runs It	SDLC Connection
Unit Testing	Individual functions or methods in isolation	Developer	Happens during Phase 3, alongside coding
Integration Testing	How modules interact when combined	Developer / QA	After multiple units are complete (late Phase 3)
System Testing	End-to-end functionality against requirements	QA team	When the complete system is assembled (Phase 4)
User Acceptance Testing (UAT)	Whether the system meets client expectations	Client / end users	Final stage of Phase 4, before deployment

📊 Test Data Categories

✅ Normal DataValid inputs within the expected range. The system should process these correctly and produce the expected output. E.g., age = 25 for a system that accepts ages 18–65.

🔲 Boundary DataValues at the exact edge of valid ranges (minimum, maximum, and just outside). E.g., age = 18, age = 65, age = 17, age = 66. Boundary cases reveal off-by-one errors.

❌ Erroneous / Invalid DataData that should be rejected by the system. E.g., age = "hello", age = -5, an empty string for a required field. Tests that validation logic works correctly.

📝 What You Must Demonstrate in This Phase

Systematic Testing with a Test Table

Document every test case with: Test ID, description, input data, expected result, actual result, and pass/fail status. Use the three data categories above for every input. Assessors expect at least 15–20 test cases for a major project.

Defect Log

Record every defect found during testing: defect ID, description, severity (critical/high/medium/low), steps to reproduce, expected vs actual result, fix applied, and resolution status.

Evaluation Against Requirements

Return to the requirements documented in Phase 1. For each requirement, state whether it was fully met, partially met, or not met — and explain why. This cross-referencing is essential for high-level responses.

Process Evaluation

Evaluate how well the development process worked — did the Gantt chart reflect reality? Were sprint goals met? What would you change in a future project? Demonstrate honest, critical reflection.

Future Improvements

Identify genuine, technically specific improvements for a future version (v2.0). Vague answers like "I would add more features" are not rewarded. Be specific: "Implement OAuth 2.0 for authentication to replace the current custom session token system."

🛠️ Course Tools Used in Phase 4

🧪 Python unittestWrite automated unit tests using Python's built-in unittest module. Demonstrate that tests run and pass with screenshot evidence. Automated tests are more credible than manual testing alone.

📊 Test TablesA structured table documenting every test case. A NESA-specified tool (Course Spec p. 9). Every major feature must have test cases using normal, boundary, and erroneous data.

🐛 Defect / Bug LogsTrack every discovered defect with severity, reproduction steps, and resolution. GitHub Issues, Jira, or a spreadsheet are all acceptable formats. The log demonstrates genuine testing activity.

📋 UAT Feedback FormsDocument client/user feedback from acceptance testing sessions. Include the date, tester name, findings, and how feedback was incorporated. Written evidence of UAT is mandatory for the major project.

📈 Gantt Chart (Planned vs Actual)Compare your original schedule against what actually happened. Identify where tasks ran over/under, and explain variance. This comparison is a rich source of process evaluation content.

📝 How to Demonstrate Phase 4 Knowledge in an Exam: When asked to "evaluate" software, go beyond describing what was done. Use a structure: (1) State the criterion (e.g., the requirement), (2) Provide evidence (test results, user feedback), (3) Make a judgement (was it successful?), and (4) Recommend improvements. Evaluation without evidence is description; evaluation with evidence is analysis; evaluation with justified judgements is the standard that earns top marks.

Tools Reference 🛠️ Tool Mapping by SDLC Phase

🛠️ Course Tools — Mapped to SDLC Phases

🎯 (Course Spec pp. 8–9 — tools and techniques across the development lifecycle)

📌 The NESA syllabus specifies a set of tools that students must know how to apply. This section maps each tool to the SDLC phase(s) where it is primarily used, with an example artefact for each.

Phase 1

🎯 Identifying and Defining

📋 Data Dictionary

Define data fields with name, type, size, range, and validation rules. Example artefact: A table showing field member_id as VARCHAR(8), required, format "S" + 7 digits, auto-generated.

🖼️ Storyboards

Hand-drawn or digital sketches of each screen/view in the application. Example artefact: Wireframe of the login screen showing input fields, submit button, and error message location.

👥 Use Case Diagrams

UML diagram showing system actors and their interactions with system functions. Example artefact: Use case diagram showing Member, Staff, and Admin actors with their respective use cases (Search Books, Issue Loan, Generate Report).

📝 User Stories

Requirement statements in "As a [role], I want [feature] so that [benefit]" format with acceptance criteria. Example artefact: "As a member, I want to search books by title so I can find available items quickly." With 4 measurable acceptance criteria.

Phase 2

🔬 Research and Planning

📐 Structure Charts

Hierarchical decomposition of the system into modules showing data passing between levels. Example artefact: Top-level [Main] decomposed into [Authentication], [Catalogue], [Loans], [Reports] with sub-modules under each.

💬 Pseudocode

Language-independent algorithm description using keywords BEGIN/END, IF/THEN/ELSE, FOR/WHILE, INPUT/OUTPUT. Example artefact: Pseudocode for a binary search algorithm across the book catalogue, 10–15 lines.

🔀 Flowcharts

Visual algorithm using standard symbols: oval (start/end), rectangle (process), diamond (decision), parallelogram (I/O). Example artefact: Flowchart of the login validation process including the two-factor auth branch.

🧩 Class Diagrams (UML)

Show classes with attributes (+/-/#), methods, and relationships (inheritance ▷, association ─, composition ◆). Example artefact: Class diagram showing User ◁ Member and User ◁ Staff inheritance with shared and unique attributes.

🗃️ ERD (Entity Relationship Diagram)

Database schema showing tables, primary keys (PK), foreign keys (FK), and cardinality. Example artefact: ERD showing Member (PK: member_id) one-to-many Loans (FK: member_id) many-to-one Book (PK: book_id).

🔄 Data Flow Diagrams

Show how data flows between external entities, processes, and data stores using Gane-Sarson or Yourdon notation. Level 0 (context) and Level 1 DFDs required. Example artefact: Level 1 DFD showing the Loan Management process decomposed into sub-processes.

📅 Gantt Chart

Project schedule showing tasks, durations, dependencies, and milestones on a timeline. Example artefact: 10-week chart with tasks grouped by SDLC phase, including milestones for design review, code freeze, and UAT.

📋 Test Plan

Document defining the testing scope, types, test cases (before coding), schedule, and entry/exit criteria. Example artefact: Test plan with 20 test cases derived from user stories, categorised by type (unit/integration/UAT).

Phase 3

💻 Producing and Implementing

🐍 Source Code

Implementation in Python (or web stack) following PEP 8, with docstrings, modular structure, and input validation. Example artefact: book_service.py with class BookService, docstrings, and parameterised SQL queries.

🔀 Git Version Control

Atomic commits with descriptive messages, feature branches, and a main branch protected by pull requests. Example artefact: Git log showing 40+ commits across development with messages like "feat: add book search by ISBN" and "fix: resolve off-by-one in loan due date".

🗄️ SQL Implementation

Parameterised queries to prevent SQL injection, transactions for data integrity, and views for complex reporting queries. Example artefact: CREATE TABLE members with constraints, and a parameterised SELECT with JOIN for the loan report.

📝 Inline Documentation

Docstrings for all public functions/classes, inline comments for complex logic, and a README with setup instructions. Example artefact: Google-style docstrings on every function with Args, Returns, and Raises documented.

Phase 4

🧪 Testing and Evaluating

📊 Test Tables

Document every test with ID, description, type (unit/integration/system/UAT), data category, input, expected, actual, and pass/fail. Example artefact: 20-row table covering all 8 user stories with 3 data categories each.

🧪 Python unittest

Automated test cases using unittest.TestCase subclasses. Example artefact: test_book_service.py with 10 test methods covering add, search, delete, and edge cases, run with python -m unittest discover.

🐛 Defect Log

Track bugs with ID, description, severity, steps to reproduce, fix, and status. Example artefact: 8-row log showing defects discovered during UAT, their severities (1 critical, 3 high, 4 medium), and all resolved before submission.

📋 UAT Feedback Forms

Structured feedback collected from real or simulated clients during acceptance testing. Example artefact: Signed form from the teacher-acting-as-client noting 3 change requests, with change request log showing how each was addressed.

Real-World Examples ✅ Effective SDLC in Famous Software

✅ Where the SDLC Was Done Well

📌 These real-world examples show the SDLC applied effectively. For each case, identify which phase made the difference and what lesson applies to the HSC course.

✅ Effective

Spotify — Continuous Agile Delivery

Streaming Platform · Founded 2006 · 600M+ users

🎯 Phase 1

Spotify identified a clear, bounded problem: illegal music piracy was rampant because legal alternatives were too expensive and inconvenient. Their requirements were built around eliminating friction for users, not replicating iTunes. The problem statement was sharp.

🔬 Phase 2

Spotify developed the "Squad Model" — an architectural plan for how independent squads (8–12 people) would own distinct product areas. This design decision allowed each squad to move independently through the SDLC simultaneously. Architecture was explicitly designed for parallelism.

💻 Phase 3

Squads used two-week sprints with continuous integration (CI). Every commit to main triggered automated tests and a build. Feature flags allowed incomplete features to be deployed to production but hidden from users — enabling real testing in production conditions.

🧪 Phase 4

Spotify used A/B testing to evaluate features with real users before full rollout. Data-driven evaluation replaced subjective opinion. The Discover Weekly feature (2015) was only rolled out globally after A/B tests showed a 25% increase in listening time.

📚 HSC Lesson

Methodology justification matters. Spotify chose full Agile because requirements evolved rapidly (new streaming rights, new device types), client feedback was immediate (user data), and the team was large and self-managing. Apply this reasoning to justify your own methodology choice in the project.

✅ Effective

NASA Mars Rover (Perseverance) — WAGILE for Safety-Critical Systems

NASA JPL · Launched 2020 · $2.7B USD

🎯 Phase 1

Requirements were exhaustively defined before any design began. Every requirement had a priority level, rationale, source, and verification method. Non-functional requirements (reliability: must operate autonomously for 1 Martian year; safety: must not damage sample collection equipment) were documented as rigorously as functional requirements.

🔬 Phase 2

JPL used formal design reviews (PDR — Preliminary Design Review, CDR — Critical Design Review) with independent review boards before proceeding to implementation. Structure charts and formal specifications were produced for every subsystem. Security architecture was a first-class concern in the design phase.

💻 Phase 3

Code was written in C and C++ with strict adherence to NASA's coding standard (NPR 7150.2). Every function had a maximum of 60 lines. No dynamic memory allocation after initialisation. These constraints were enforced by automated tools. Modular design allowed each subsystem team to work independently.

🧪 Phase 4

JPL conducted over 10,000 unit tests with 100% code coverage on safety-critical paths. They ran the full mission simulation in a dedicated "testbed" rover on Earth before launch. Every defect was logged, root-caused, and fixed before certification. UAT was simulated with mission operators in a Mars-environment test lab.

📚 HSC Lesson

Non-functional requirements deserve equal weight. Reliability, safety, and performance were treated with the same rigour as functional features. In HSC projects, many students only test what the software does, not how well it does it. Test non-functional requirements explicitly.

✅ Effective

GitHub Copilot — Iterative Research-Driven Development

GitHub / Microsoft · Launched 2021

🎯 Phase 1

The identified problem was developer productivity: developers spent significant time writing boilerplate code. The team validated this with developer surveys and analysis of code search patterns on GitHub's existing platform.

🔬 Phase 2

The team spent significant time in the research phase exploring model architectures (Codex, a variant of GPT-3) before committing to an implementation. Technical feasibility was assessed via prototype. Security architecture had to address the risk of the model reproducing copyrighted code — a non-functional security requirement addressed in the design phase.

🧪 Phase 4

Copilot was released as a technical preview with a limited user base (Phase 4 as UAT at scale). Evaluation was data-driven: GitHub measured task completion time, suggestion acceptance rates, and code quality metrics. The iteration loop from evaluation back to Phase 3 (model fine-tuning) happened continuously.

📚 HSC Lesson

Research is a genuine phase, not a checkbox. The Copilot team's willingness to invest in research before committing to an implementation direction prevented expensive wrong-turns. In HSC terms: don't jump from a vague problem statement straight to coding. Research existing solutions, evaluate alternatives, and justify your design decisions.

Real-World Examples ❌ Ineffective SDLC in Famous Software

❌ Where the SDLC Went Wrong

📌 These cautionary cases show what happens when phases of the SDLC are skipped, rushed, or ignored. Each example maps to specific syllabus concepts and offers a direct lesson for HSC students.

❌ Ineffective

Healthcare.gov — Phase 1 & 4 Failures

US Government · Launched October 2013 · $600M+ USD

What went wrong

The US Affordable Care Act website launched nationally on October 1, 2013 and immediately crashed. Within the first day, only 6 people out of 4.7 million visitors successfully enrolled. The site was offline or severely degraded for over two months.

🎯 Phase 1 Failure

Requirements were poorly defined and changed repeatedly as legislation was still being drafted. Non-functional requirements for load capacity were not specified — the system was never designed to handle millions of simultaneous users. The scope was never frozen.

🧪 Phase 4 Failure

End-to-end system testing was only conducted in the final two weeks before launch. Load testing was inadequate — the system was tested with hundreds of simulated users when it needed to handle millions. UAT was effectively skipped. Senior officials were told the system was ready based on unit tests that passed, without integration or system testing.

📚 HSC Lesson

Testing types are not interchangeable. Unit tests passing does not mean the system works. You must test integration and system behaviour explicitly. In your major project, document all four testing types — assessors know the difference and will check whether you demonstrated each one.

❌ Ineffective

Boeing 737 MAX MCAS — Design and Testing Phase Catastrophe

Boeing · 346 fatalities in two crashes · 2018–2019

What went wrong

The Maneuvering Characteristics Augmentation System (MCAS) — software that automatically pushed the nose of the aircraft down — was implicated in two fatal crashes (Lion Air 610 and Ethiopian Airlines 302). 346 people died. The entire 737 MAX fleet was grounded for 20 months.

🔬 Phase 2 Failure

The MCAS system was expanded in capability late in the design process without a corresponding review of safety requirements. Engineers relied on a single angle-of-attack sensor (a single point of failure) without a design review that would have caught this architectural flaw. The security/safety architecture was not revisited when the scope of MCAS changed.

🧪 Phase 4 Failure

Testing did not simulate the failure mode where the single sensor sent erroneous data. The FAA's own certification process accepted Boeing's safety analysis without independently verifying it. There was no test case for "what if the only angle-of-attack sensor fails?" — a boundary/erroneous data case that was never tested.

📚 HSC Lesson

Erroneous data testing is not optional. Your test plan must include cases where inputs are wrong, missing, or malformed. Single points of failure must be identified in the design phase (Phase 2) and tested explicitly in Phase 4. When you change the scope of a feature mid-development, go back to Phase 2 and review the design impact before continuing to Phase 3.

❌ Ineffective

Therac-25 — Software Defects with Fatal Consequences

Atomic Energy of Canada Limited · 6 radiation overdose incidents · 1985–1987

What went wrong

The Therac-25 was a computer-controlled radiation therapy machine. A race condition in its software could cause the machine to deliver radiation doses up to 100 times the intended amount, resulting in radiation burns, paralysis, and death for at least six patients.

💻 Phase 3 Failure

Earlier hardware safety interlocks had been removed and replaced with software-only controls when the new software version was written. A race condition — where operator inputs and machine state collided in a specific timing window — was never detected because the defect only occurred when an operator typed quickly at a specific speed. The defect was in the code but also in the assumptions about operator behaviour (requirements).

🧪 Phase 4 Failure

Testing was insufficient and relied on the same operator behaviour patterns as normal use. The specific sequence of rapid keystrokes that triggered the race condition was never included in the test plan. Patient reports of overdoses were dismissed as machine errors for over a year before the software root cause was identified.

📚 HSC Lesson

Software in safety-critical contexts requires defence in depth. Never rely on software as the only safeguard. This maps to the concept of redundancy in security architecture. In software terms: implement multiple layers of validation (client-side AND server-side). Always test edge cases systematically, not just the "happy path" — the defect that kills is always in the untested edge case.

❌ Ineffective

Twitter/X — Rushed Production Releases Without Testing

Twitter/X · 2022–2023 · Post-acquisition period

What went wrong

Following the 2022 acquisition, Twitter's new management rapidly pushed features into production (Twitter Blue verification, API changes, UI modifications) without adequate testing cycles. Several features were rolled back within hours of launch due to widespread bugs. The platform experienced multiple outages that would not have occurred with proper Phase 4 validation.

🔬 Phase 2 Failure

New feature designs were not reviewed against existing system architecture. Twitter Blue verification (the blue tick) was released without designing for abuse prevention — within hours, impersonators had purchased verification for brands including major companies and politicians, causing significant reputational and financial damage (Eli Lilly's insulin pricing tweet caused a $15B stock drop).

🧪 Phase 4 Failure

Features were pushed to all users simultaneously without incremental rollout (A/B testing or staged deployment). There was no UAT phase with representative user groups before full launch. Feedback from engineers warning about testing gaps was reportedly dismissed.

📚 HSC Lesson

Speed and quality are a trade-off that must be managed, not ignored. Skipping Phase 4 to ship faster creates technical debt and real-world harm. In HSC terms: rushing your testing to finish the project is the most common student mistake. A well-tested project with fewer features is always preferable to an untested project with many features.

Assessment Guidance 📝 HSC Exam and Project Tips

📝 HSC Assessment Guidance for the SDLC

🎯 (All outcomes — knowing what assessors look for in each phase)

🎯 Responding to SDLC Questions in the Written Exam

NESA uses specific command verbs that indicate the depth of response required. Understanding these in the context of the SDLC is essential:

Command Verb	What It Means for SDLC Questions	Example Question
Identify	Name a phase, tool, or concept. One word or short phrase. No explanation required.	"Identify one tool used in the Research and Planning phase."
Describe	Name and explain the characteristics of something. 2–4 sentences.	"Describe the purpose of a Data Flow Diagram in the SDLC."
Explain	Give reasons for why something is done. Show cause-effect relationships.	"Explain why requirements are gathered before design begins."
Justify	Give reasons and evidence for a choice. Connect to the specific scenario.	"Justify the use of WAGILE methodology for the scenario described."
Evaluate	Assess against criteria, weigh strengths and limitations, and reach a reasoned judgement.	"Evaluate the effectiveness of the testing strategy used in the case study."
Propose / Design	Create a solution — draw a diagram, write pseudocode, or outline a plan for the given scenario.	"Design a test plan for the system described, including three test cases."

📋 The Major Project — SDLC Documentation Checklist

For the Software Engineering Project, assessors mark your project portfolio against the SDLC. Use this checklist to ensure every phase is evidenced:

Phase	Required Evidence	Common Mistake
Phase 1	Problem statement, feasibility analysis, requirements table (functional + non-functional), user stories with acceptance criteria, data dictionary draft, scope statement	Listing only functional requirements; skipping non-functional requirements entirely
Phase 2	Structure chart, pseudocode for key algorithms, class diagram (UML), ERD, DFDs (Level 0 and Level 1), Gantt chart, test plan, security threat model	Going straight from requirements to coding; producing design documents after coding ("reverse engineering" the docs)
Phase 3	Source code (modular, PEP 8), Git commit history, annotated code excerpts, inline documentation, implementation mapping to structure chart	Submitting monolithic code without demonstrating modular design; no version control history
Phase 4	Test table (20+ cases, all three data categories), automated unit test output, defect log, UAT feedback form, requirements evaluation table, process evaluation, future improvements	Testing only happy-path (normal data); no boundary or erroneous test cases; evaluation that only lists what was done rather than judging how well it was done

⚠️ The Biggest Mistake in SDLC Responses: Treating the SDLC as a list of phases to tick off rather than as a system of thinking. Assessors are looking for evidence that you understand why each phase exists, how phases depend on each other, and how your decisions in one phase affected the next. Connect your phases explicitly: "The non-functional requirement for sub-2-second search response (Phase 1) informed the indexed database design (Phase 2) and was verified by boundary test case TC-14 (Phase 4)."

📚 Syllabus Outcome Cross-Reference

📌 Every SDLC concept on this page is explicitly required by the NESA NSW HSC Software Engineering syllabus. This table maps each outcome to the phases and topics covered above.

Outcome	Description	SDLC Phase(s)	Where Covered on This Page
SE-11-01	Applies the software development cycle to the development of software solutions	All phases	What is the SDLC? · Entire page
SE-12-01	Identifies, defines, and analyses the requirements and constraints of a software engineering problem	Phase 1	Phase 1 — Identifying and Defining · Tool Mapping Phase 1
SE-12-02	Research, plan, design, and evaluate approaches to programming and project management	Phase 2	Phase 2 — Research and Planning · Agile vs WAGILE · Tool Mapping Phase 2
SE-12-03	Uses appropriate tools, techniques, and strategies to manage complexity	Phase 2 & 3	Phase 2 (structure charts, DFDs) · Phase 3 (modular coding, version control)
SE-12-04	Uses and applies secure software development practices	Phase 2 & 3	Phase 2 (threat modelling, security architecture) · Phase 3 (input validation, SQL parameterisation)
SE-12-05	Implements software solutions using object-oriented, event-driven, and structured programming paradigms	Phase 3	Phase 3 — Producing and Implementing · Tool Mapping Phase 3
SE-12-06	Selects and uses appropriate tools and techniques to develop, document, and implement software solutions	All phases	Tool Mapping Reference (all four phase sections)
SE-12-07	Communicates and collaborates using appropriate conventions, tools, and strategies	Phase 2 & 3	Phase 2 (Gantt charts, communication planning) · Phase 3 (version control, documentation)
SE-12-08	Applies systematic testing and debugging practices	Phase 4	Phase 4 — Testing and Evaluating · Tool Mapping Phase 4 · Case Studies
SE-12-09	Evaluates the effectiveness of software solutions and development strategies	Phase 4	Phase 4 (requirements evaluation) · Case Studies (effective and ineffective SDLC) · HSC Assessment Guidance

Using This Page in Your Study:

For the Written Exam: Use the command verb table to match your response depth to the question. Use the case studies as evidence when asked to "evaluate" or "justify."
For the Major Project: Use the documentation checklist in the HSC Assessment Guidance section to verify you have produced the required artefacts for every phase.
For Cross-Topic Study: Return to the course topic table (What is the SDLC? section) to identify which SDLC phase is central to the topic you are currently studying.