📋 Software Engineering Project

🎯 Identifying and Defining

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

📌 Define and analyse the requirements of a problem to ensure the software engineering solution is viable and purposeful.

📋 Problem Requirements

Before coding begins, a software engineer must define the core requirements (Outcome SE-12-01):

• 🎯 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.

🛠️ Tools for Idea Generation & Solution Development

Explore the tools used to develop ideas and guide the project lifecycle (Outcome SE-12-06):

📐 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.

Structure Chart: Library Management System
==========================================
                [Main Program]
               /        |       \
    [Book Module]  [Member Module]  [Report Module]
      /    |   \       /    \          |       \
[Add] [Search] [Return] [Register] [Update] [Loans] [Overdue]
  |       |        |
[Validate] [DB Lookup] [Fine Calc]

🔍 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.

📝 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.

🚀 Software Implementation Methods

🎯 (SE-12-01)

📌 Investigate types of software implementation methods used when transitioning a client from an old system to a new solution (Outcome SE-12-01).

🏗️ Research and Planning: Development Approaches

🎯 (SE-12-01)

📌 Research and use standard software development approaches to structure the engineering lifecycle.

📅 Project Management & Communication

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

📅 Project Management

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

💬 Communication & Social Issues

Explore communication issues associated with project work. Engineers must prioritise involving and empowering the client through constant dialogue, enabling feedback during Agile iterations, and negotiating realistic deadlines and features (Outcome SE-12-09).

Furthermore, engineers must explore social and ethical issues, such as equitably dividing work when collaborating, acting professionally when working individually, and transparently responding to stakeholder concerns regarding data security (Outcome SE-12-05).

📊 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). In the SEP, your Gantt chart must cover all four project phases.

Gantt Chart: Library Management System — 10-Week Schedule
=============================================================
Task                          | Wk1 | Wk2 | Wk3 | Wk4 | Wk5 | Wk6 | Wk7 | Wk8 | Wk9 | Wk10
------------------------------|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----
PHASE 1 — Identifying & Defining
  Requirements gathering       | ███ | ███ |     |     |     |     |     |     |     |
  Problem definition           | ███ | ███ |     |     |     |     |     |     |     |
  Client consultation          |     | ███ | ███ |     |     |     |     |     |     |
PHASE 2 — Research & Planning
  System design (structure)    |     |     | ███ | ███ |     |     |     |     |     |
  Algorithm design (pseudocode)|     |     |     | ███ | ███ |     |     |     |     |
  Gantt & risk planning        |     |     | ███ | ███ |     |     |     |     |     |
PHASE 3 — Producing & Implementing
  Core module development      |     |     |     |     | ███ | ███ | ███ |     |     |
  UI/front-end implementation  |     |     |     |     |     | ███ | ███ |     |     |
  Integration & version control|     |     |     |     |     |     | ███ | ███ |     |
PHASE 4 — Testing & Evaluating
  Testing & bug fixing         |     |     |     |     |     |     |     | ███ | ███ |
  Client review & feedback     |     |     |     |     |     |     |     |     | ███ |
  Final report & submission    |     |     |     |     |     |     |     |     | ███ | ███
=============================================================
Key: ███ = Task active during this week

⚠️ Risk Management

Risk management involves identifying potential threats to project success, assessing their likelihood and impact, and planning mitigation strategies in advance. A risk register is maintained throughout the project and updated as new risks emerge or existing risks are resolved.

🎨 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.

📈 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 0 DFD — Library Management System (Context Diagram)
===========================================================

  [Library Member] ----search request---→ (Library Management System)
  [Library Member] ←---search results---- (Library Management System)
  [Library Member] ----loan request------→ (Library Management System)
  [Library Member] ←---loan confirmation- (Library Management System)

  [Staff Member]   ----return record----→ (Library Management System)
  [Staff Member]   ←---fine calculation-- (Library Management System)
  [Staff Member]   ----report request---→ (Library Management System)
  [Staff Member]   ←---overdue report---- (Library Management System)

  [Admin]          ----manage books-----→ (Library Management System)
  [Admin]          ←---system reports---- (Library Management System)

Key:
  [ ] = External Entity (outside the system boundary)
  ( ) = Process (the system itself)
  ----→ = Data Flow (direction of data movement)

🛡️ Quality Assurance & Back-End Engineering

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

🛡️ Quality Assurance (QA)

Investigate how software engineering solutions are quality assured. QA involves defining clear criteria on which quality will be judged (e.g., load times, error rates). It requires a continual checking process to ensure requirements are met, whilst strictly addressing compliance and legislative requirements (e.g., Australian Privacy Principles) (Outcome SE-12-01).

📐 Modelling Tools

Demonstrate the use of 🛠️ modelling tools to map out software logic. This includes Data Flow Diagrams (DFDs), Structure Charts, and Decision Trees (Course Spec p. 5-10) (Outcome SE-12-06).

⚙️ Back-End Engineering Contribution

Explain the contribution of back-end engineering to the success and ease of software development (Outcome SE-12-07):

🖥️ 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 — dramatically 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. Additionally, 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. Additionally, implementing HTTPS with TLS certificates encrypts all data in transit, protecting against man-in-the-middle attacks on public networks.

💻 Producing and Implementing

🎯 (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 approaches. Engineers must develop, construct and document algorithms and allocate appropriate resources to support development (Outcome SE-12-02).

💾 Programmed Data Backup & Version Control

Demonstrate the use of programmed data backup to ensure data integrity during development. Additionally, implement version control (e.g., Git) to safely track code changes, manage collaborative merges, and document the project's evolution (Outcome SE-12-04, SE-12-09).

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')

💡 Strategies for Difficulties & Outsourcing

Explore strategies to respond to difficulties when developing. This includes searching for solutions online (e.g., official documentation, StackOverflow), seeking collaboration with peers for code reviews, or outsourcing specific technical components (e.g., paying for an external API service rather than building it from scratch) (Outcome SE-12-09).

✨ Innovative UI Solutions

Propose an additional innovative solution using a prototype and a user interface (UI) design. Prototyping allows clients to interact with a mock-up of the system, providing early validation of the UI layout before heavy backend coding commences (Outcome SE-12-06).

🌿 Version Control Workflow

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

🧩 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))

✅ 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.

🧪 Testing and Evaluating

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

📌 Apply methodologies to test and evaluate code, and Analyse and respond to client feedback. Evaluating the effectiveness of a solution ensures it meets the initial problem requirements.

🎯 Effectiveness & Testing Data

Evaluation involves generating a test plan and executing it using rigorous testing data based on path testing (ensuring every line of code executes) 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 (Outcome SE-12-08, SE-12-09).

⚡ Language-Dependent Code Optimisation

Use language-dependent code optimisation techniques to refine execution speed and readability. In Python, this often involves using list comprehensions instead of standard loops, or utilising built-in C-optimised functions (Outcome SE-12-08).

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()

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.

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.

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 demonstrates to assessors that you conducted genuine testing and responded to the results.

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.

📝 HSC Assessment Guidance

🎯 (All Outcomes: SE-12-01 to SE-12-09)

📌 Understanding what assessors are looking for in each phase will help you maximise marks and avoid common pitfalls.

What Markers Look for in Each Phase