HSC Software Engineering common mistakes
HSC Software Engineering · Understand the traps and how to avoid them.
When asked to justify a chosen software development methodology for a scenario, the candidate names a methodology (e.g. Agile) and lists its generic advantages instead of tying each advantage to a specific constraint stated in the scenario, such as a fixed regulatory deadline or a client who cannot articulate requirements up front.
Candidates memorise methodology definitions and their textbook pros and cons, then treat every scenario as a prompt to dump that list. They do not extract the scenario's constraints (team size, requirement volatility, safety criticality, client availability) and so never connect the two.
What to do instead
Before writing, underline every constraint in the scenario and write a two-column plan: constraint on the left, methodology feature that addresses it on the right. Then write each justification as 'because the scenario states X, methodology Y's practice Z handles it by...'. Reject any sentence that would still be true for a different scenario.
Describing SDLC phases as a flat list of activities without showing the artefacts that pass between them, or drawing every model as a strict waterfall even when the question asks about iterative, spiral or incremental approaches.
Candidates learn phase names (requirements, design, implementation, testing, maintenance) as vocabulary and never learn what each phase produces or how those outputs feed the next phase. Diagrams in revision notes are often simplified to a single linear arrow chain.
What to do instead
For each phase, memorise one input and one output artefact (e.g. requirements phase: input = stakeholder needs, output = signed-off requirements specification and test acceptance criteria). Practise redrawing waterfall, iterative, spiral and incremental models and labelling where feedback loops return and what triggers them.
Writing object-oriented code that exposes all attributes as public, uses inheritance for every relationship, and duplicates logic across sibling classes instead of encapsulating state and using polymorphism or composition where appropriate.
Candidates can define encapsulation, inheritance and polymorphism in prose but have not practised applying them under exam conditions. They default to the simplest code that runs, and 'is-a' relationships feel natural even when 'has-a' composition is correct.
What to do instead
Adopt a checklist before finalising any class design: are attributes private with controlled access, does each subclass genuinely satisfy the parent's contract, could a shared behaviour be pulled into a superclass or interface, and is composition a better fit? Practise refactoring a deliberately poor class diagram into a well-encapsulated one and justify each change.
Analysing algorithm complexity by counting the lines of code or the number of loops rather than identifying the dominant operation and expressing growth in terms of input size n, and confusing best case, worst case and average case.
Big-O is often taught as a labelling exercise (memorise that bubble sort is O(n squared)) rather than a derivation skill. Candidates also conflate the number of nested loops with the actual growth when loop bounds depend on n in non-obvious ways.
What to do instead
For every algorithm, identify the operation that executes most often as a function of n, derive the count algebraically, then drop constants and lower-order terms. State explicitly which case you are analysing and why. Compare two algorithms on the same input size with a table of operation counts to see why constants matter at small n but not asymptotically.
Choosing a data structure for a scenario by naming its abstract properties (e.g. 'a stack is LIFO') without linking the choice to the access pattern the scenario actually needs, such as frequent search by key, ordered traversal, or last-in-first-out undo behaviour.
Data structures are revised as isolated definitions with no connection to problem requirements. Candidates rarely practise reading a scenario and extracting the operations that dominate (insert, delete, search, traverse) before selecting a structure.
What to do instead
Use a decision procedure: list the operations the scenario performs and how often, then match against a table of structures with their complexity per operation. Write one sentence per choice explaining which required operation it optimises and what it sacrifices.
Producing data-flow diagrams, structure charts or class diagrams with invented or inconsistent notation, such as processes that are actually data stores, arrows with no labels, or class relationships drawn without multiplicity.
Candidates learn diagram types from mixed sources and never commit to one standard notation. Under time pressure they draw what looks plausible rather than what the notation requires, and they omit labels because labels take effort.
What to do instead
Pick the standard notation for each diagram type (e.g. Yourdon/DeMarco symbols for DFDs) and memorise the small set of legal symbols and connection rules. For every diagram, apply a self-check: every process has at least one input and one output, every data flow is labelled with a noun, every store appears in both a process and the data dictionary, and every relationship has multiplicity.
Treating user-centred design as a single step of 'ask users what they want', omitting personas, task analysis, prototyping, and iterative usability evaluation, and failing to describe how findings from evaluation feed back into the design.
The phrase 'user-centred' invites a vague answer. Candidates have not practised describing a full UCD cycle with concrete methods and artefacts, so they produce a sentence where a paragraph with named techniques is required.
What to do instead
Memorise a UCD cycle with named methods at each stage: research (interviews, observation, personas), design (wireframes, low-fidelity prototypes), evaluate (heuristic evaluation, usability testing with representative users), iterate. In answers, describe at least one concrete evaluation method and state exactly what change it would drive.
Writing web code that builds SQL queries by concatenating user input, stores secrets in client-side JavaScript, or renders user input directly into the DOM, and then failing to identify these flaws when asked to review a supplied snippet.
Candidates focus on making features work and have limited exposure to threat modelling. Security is often studied as a list of attack names rather than as concrete coding patterns to avoid and detect.
What to do instead
Learn the defensive counterpart of each common vulnerability: parameterised queries against SQL injection, server-side secret storage and environment configuration against exposed credentials, output encoding and framework escaping against cross-site scripting, and input validation on the server as well as the client. Practise auditing short code snippets line by line against a checklist of injection, authentication, exposure and validation risks.
Producing a project schedule or Gantt chart that ignores task dependencies and resource limits, or estimating effort without a stated basis, so the plan shows several tasks running in parallel that actually depend on one another.
Candidates list tasks and assign plausible durations without building a dependency network or considering team capacity. Estimation is treated as guessing rather than as a technique with named methods.
What to do instead
Build a precedence table first (task, duration, predecessors), derive the critical path, then allocate resources and check for overallocation. State the estimation technique used (e.g. analogous estimation from a similar past project, or three-point estimation) and justify the durations rather than asserting them.
Answering ethical, legal or social questions with a general opinion ('it is wrong to steal data') without naming the specific obligation, legislation or professional standard that applies, or without identifying the competing stakeholders and interests.
Candidates treat these questions as invitations to express values rather than to apply frameworks. They have not practised mapping scenarios onto privacy principles, intellectual property categories, accessibility obligations or professional codes of conduct.
What to do instead
For each scenario, write a stakeholder table (who is affected, what each stands to gain or lose), then name the specific instrument that applies (e.g. Australian Privacy Principles for personal data handling, copyright versus patent versus trade secret for IP, WCAG for accessibility) and state the concrete action the engineer should take and why.