Software Development Units 3 and 4

VCE Software Development Units 3 and 4 


KK = Key Knowledge. All KK are examinable (as are all terms in the glossary that are relevant to this course)
If a KK uses the word "including", all of the following items are examinable.
If a KK uses the words "for example" or "such as", the following items are for clarity, and are not directly examinable.
Any bullet points shown below have been inserted by me for clarity, and are not in the original VCAA study design. (Which is available locally here.)
Hover your mouse of a red asterisk to see the official VCAA glossary definition of a term. slideshow links to a (big) slideshow if the icon has a label beside it

links to a webpage on this site.

Check out my the postmortem of VCAA's 2020 sample DA exam with lots of exam tips.

SD U3O1 KK01

Characteristics of Data typeglossary links slideshow Data types


SD U3O1 KK02

Types of Data structureglossary links, including

  • associative arrays (or dictionaries or hash tables), [not to be confused with the data dictionary design tool]
  • one-dimensional arrays (single Data typeglossary link, integer index) and
  • records (varying Data typeglossary links, field index) slideshow Arrays slideshow Linked Lists [not examinable] slideshow Records and files slideshow Hashing


SD U3O1 KK03 Methods for documenting a problem, need or opportunity slideshow Problem Statements


SD U3O1 KK04 Methods for determining Solutionglossary link requirements, constraints and scope slideshow SRS - Software specification requirements


SD U3O1 KK05

Methods of representing designs, including

  • data dictionaries,
  • mock-ups,
  • object descriptions and
  • Pseudocodeglossary link slideshow Data dictionaries slideshow Mockups slideshow Pseudocode slideshow Design tools slideshow Design factors slideshow Design tools for databases slideshow Entity relationship diagrams (ERD) for databases

SD U3O1 KK06

Formatting and structural characteristics of files, including

  • delimited (CSV),
  • plain text (TXT) and
  • XML file formats slideshow XML

Plain text data consists of (drumroll) - plain ASCII text, e.g.

67 Bradley St
6/101 Nepean Hwy
6, The Crest

Text data files can be read and edited by any software, but they lack any information about what the fields mean. e.g. the dates above could be birthdate, date of employment etc.

Also, the software reading the data needs to know in advance that each record contains 5 lines of text - otherwise reading the data soon descends into anarchy.

CSV - Comma Separated Values

CSV files are also plain text, but all the fields of a single record appear on the same line, delimited (separated) by commas and quotation marks, e.g.

"Smith","John","30/5/2010","67 Bradley St","Carlton"
"Jones","Mary","12/12/1996","6/101 Nepean Hwy","Mentone"
"Splatz", "Emile","1/4/1987","6, The Crest", "Bulleen"

There is not a lot to separate plain text and CSV data files in terms of usability or value-added structure.

True but irrelevant story - many years ago the Victorian Education Department's student record database (CASS) used a wonky version of CSV without the quotation marks, like so...

Smith,John,30/5/2010,67 Bradley St,Carlton

This usually worked...but, if any field contained a comma, the fields went out of sequence and the entire data file threw itself into an unholy disaster. Of course, inevitably, it happened.

Splatz,Emile,1/4/1887,6,The Crest


After Emile's record, all the data was trashed. It was a fun day for me, because I had Emile in my school's data and I had to inform the Education Department about the meltdown that effectively stopped all of our daily access to student data until Emile's raw data was changed manually. The Education Department had to rewrite their student database software and they moved to use XML instead.

Morals: (1) Think ahead. (2) Data management shortcuts can be costly in the long run slideshow XML data files are also plain text, but they contain structural information to identify fields and records within the file.

Lots of programs rely on XML to store their data - such as Microsoft Office's DOCX, XLSX and PPTX files - where the "X" means the document is stored in XML format.


SD U3O1 KK07 A programming language as a method for developing working modules that meet specified needs slideshow Programming skills ? slideshow Software Requirement Specifications ?

I really have no idea what VCAA wants to teach in this KK

Let's summarise the theory for this KK:

Yes - a programming language does develop working modules to meet specified needs.

What else does VCAA want?


SD U3O1 KK08 Naming Conventionglossary links for Solutionglossary link elements slideshow Naming conventions slideshow Database structure naming slideshow File Naming


SD U3O1 KK09

Processing featuresglossary link of a programming language, including

  • classes,
  • control structures,
  • functions,
  • instructions and
  • methods slideshow Functions, statements etc

Quick summary -


Classes are types of objects, such as Text boxes, Labels, Spiders, Wines - each has its own relevant properties


  • a text box may have properties: width, font, background colour.
  • a spider may have properties: average size, deadliness, colour.
  • a wine may have properties: flavour, raritym colour.

Some classes (e.g. text box) are inherent and defined by a programming language.

Others classes (e.g. spider or wine) are created and defined by the programmer.

Control structures

Control structures are commands that control the flow of the execution of a program based on values that apply at the time of execution.

The most common types are:

LOGICAL (Conditional, Selection) - IF / THEN / ELSE


Variants include CASE which neatly collapses a large, messy collection of IF statements into a nice, neat package:


IF age = 3 then group = "Tiny Tots"
IF age >3 and age <=6 then group = "Minnows"
IF age >=6 and age <=10 then group = "Sardines"


CASE age

Case 3 : Group = "Tiny Tots"
Case <= 6 : Group = "Minnows"
Case <=10 : Group = "Sardines"


Don't expect exam pseudocode to use CASE structures. They have never appeared before.

But IF statements are guaranteed to appear.
FOR/NEXT has appeared in past exams and may well appear again.


SD U3O1 KK10

Algorithms for sorting, including

  • selection sort and
  • quick sort slideshow Selection Sort

Quick sort

Developed in 1961, QuickSort works by selecting a pivot value, and dividing the data into two partitions - one with values less than the pivot's value, and one with values greater. The partitions are then repeatedly (recursively) divided into two sub-arrays and and re-sorted. The QuickSort algorithm is faster than some others, such as bubble sort.

SD students in 2014's exam question B2 were asked:

2b. Briefly explain how a quick sort works and how this differs from a bubble sort. 2 marks [6 lines]

You could expect a similarly-hard question this year. My answer in my postmortem was

- A quick sort recursively subdivides the data set into 2 parts and chooses a pivot value. All items in the part of the data set that are less than the pivot value are moved to the left of the pivot item, items greater than the pivot value are moved to the right of the pivot item. This is repeated until all items are sorted.

- Compared to the bubble sort, the quick sort is more complex to code, but is usually more efficient with large data sets.

In their examiners' report, VCAA commented:

...most students struggled to provide a complete and detailed response, with many missing the second part of the question – ‘how this differs from a bubble sort’.

The following are examples of high-scoring responses.

1. With each iteration, a value called a pivot is chosen from the list. For each other value, if it is greater than pivot it places it to the right, if it is less than, it places to left. The pivot is in the right place and on the two side lists.
This differs from bubble sort as it is a divide and conquer algorithm, whereas bubble sort goes through one by one. Quick sort as a result is much faster.

2. A quick sort chooses a random pivot item and compared other items to that element until it has two subsets of elements higher and lower than the pivot. It then does the same to the sublists and so on till it’s all sorted.
The difference to the bubble sort is the creation of sublists rather than looping over one list.

By the way: in 2014, the average mark for this question was only 0.6 out of 2.

In 2016, SD students faced this in question A2

Question A2

In the process of sorting an array of eight integers using the quick sort algorithm, the first partitioning with the array appears as follows.









Which one of the following statements is correct?

  1. Neither 17 nor 19 was the pivot.
  2. The pivot was either 17 or 19.
  3. The pivot was 17, but was not 19.
  4. The pivot was not 17, but it could have been 19.

To see the answer HIGHLIGHT FROM HERE > B <TO HERE. It was a tough question for 1 mark!

TIP - If you spent 10 minutes working it out, you would have been better guessing and taking a 25% chance of being right.

More to come.


SD U3O1 KK11

Algorithms for

  • binary searching and
  • linear searching slideshow Searching - linear and binary slideshow Searching, sorting, filtering


SD U3O1 KK12

Validationglossary link techniques, including

  • existence checking,
  • range checking and
  • type checking

Data Validation


SD U3O1 KK13

Techniques for checking that modules meet design specifications, including

  • trace tables and
  • construction of test data slideshow Test data slideshow Trace tables, desk checks


SD U3O1 KK14

Purposes and characteristics of internal documentation, including

  • meaningful comments and syntax. slideshow Internal documentation


SD U3O2 KK01

Security considerations influencing the design of solutionglossary links, including

  • authentication and
  • data protection

Let's assume the vague KK refers to user authentication.

In your SD software, it means that you need to demonstrate that you know the value of

  • logins/passwords (you can fake it for the outcome outcome - e.g. accept any text for username/password and let the user in)
  • protecting data from accidental deletion or loss (e.g. forcing users to jump through confirmation hoops before deleting data or exiting without saving)

But in terms of pure theory, user authentication and data protection measures can involve a host of things:

Designing User Authentication

  • registering new users, and verifying their email address with a test email.
  • PINs
  • login/password - including the enforcement of strong passwords
  • Challenge/response security questions (e.g. mother's maiden name)
  • Two factor (2FA) or multifactor authentication, e.g. each data access session requires the entry of a one-time access key received via text message to the user's phone; e.g. ATMs require a physical card and a typed PIN.
  • hardware tokens, e.g. Yubi key, smart card, debit/credit/ATM card
  • biometric readings, e.g. fingerprint, iris scan, voice print, face recognition

Designing data protection

  • data encryption, both stored (e.g. public key cryptography like PGP) and in transit (TTL,SSL)
  • bot exclusion, e.g. Recaptcha
  • providing users with information about their last recorded activity (e.g. last login date/time/IP address) to highlight illicit account access
  • restricting access to registered
    • geographic locations,
    • MAC addresses (unique codes identifying individual devices)
    • IP addresses
  • FIDO (Fast ID Online) security keys
  • logging users out after a period of inactivity
  • analysing users' behaviour patterns to detect suspicious changes to typical usage, e.g. typing speeds, common typing errors, mouse usage

Most of the methods above are designed to protect against deliberate, malicious threats to data.

Designing to protect users against themselves

The main threat to data is not less evil, but it's much more likely - user error caused by incompetence, ignorance, laziness or carelessness.

UP - unauthorised people

To all of the prevention strategics you should add: "Educate / train users about this threat: its dangers, and how to recognise and handle it."

Fun fact: 91% of all successful attacks on data begin with a phishing exploit.

Moer than half of lost data was caused by user error.

Threat to data

Prevention design

Phishing & spear phishing (phishing targeted at specific victims)- giving passwords or identifying data about themselves to UP

Access hierarchy - only give people the access to data that they need to do their job. No more.

Misusing software or pressing the wrong keys and deleting data Job training and certification that users are competent to access certain equipment, data or software.
Losing phones, laptops etc or leaving devices where they can be used by UP Set up strong access controls e.g. password protection of operating system, documents, network; biometric scan.
Allowing UP access to restricted equipment, e.g. file servers, workstations, backup media Biometric restriction of user access to sensitive areas using swipe cards, fingerprint scans etc.
Using stupidly-simple passwords

Automate the requirement for strong (long, complex) passwords.

Lock users out after a few failed login attempts.

Reusing the same passwords for several different accounts

Education about the risks.
Clicking links to malware Scan all visited websites and incoming emails or texts for malware. Block known danger sites.
Opening infected email attachments

Strong, current antivirus scanning.

Carelessly document disposal (paper or electronic) Sensitive documents can easily be undeleted. Paper documents can be fished out of bins or skips. All documents should be wiped and/or shredded physically or electronically when disposed of.
Fiddling with security settings To "speed up my computer" a user may turn off security settings like virus scanning or user access control. This can be prevented by mandating the setting in group policies that can only be changed by system administrators.
Introducing unauthorised equipment to a secure system Forbid users to use their own personal software, wifi routers, switches, computers IoT devices, etc that could be insecure or infected with malware.
Social engineering Educate users about being manipulated into giving UP access to data or resources.



A clever gadget:

The Scramble Keypad randomly assigns digits to different positions for users to enter their PINs. This prevents onlookers from detecting a PIN by the movement of the user's fingers. It also has a narrow viewing angle so people to the sides of the user cannot see the displayed digits.


SD U3O2 KK02

Techniques for collecting data to determine needs and requirements, including

  • interviews,
  • observation,
  • reports and
  • surveys slideshow Data Collection techniques



SD U3O2 KK03 Functional and non-functional requirements

For more details, see... slideshow SRS - Software specification requirements

Functional and non-functional requirements

but the short answer is:

Functional requirements (FR) = what a solution is required to do, e.g.

  • print a receipt with 2 seconds;
  • adjust Australian prices to include GST
  • produce charts of the data

Consider a FR like a verb.

Non-functional requirements (NFR) of the solution (solution attributes) are qualities such as
user-friendliness, performance levels, e.g. the solution should be

  • responsive,
  • attractive
  • robust,
  • portable,
  • reliable
  • maintainable
  • expandable
  • etc

Consider a NFR like an adjective

SD U3O2 KK04

Constraints that influence Solutionglossary links, including

  • economic,
  • legal,
  • social,
  • technical and
  • usability slideshow slideshow SRS - Software specification requirements

SD U3O2 KK05 Factors that determine the scope of Solutionglossary links slideshow slideshow SRS - Software specification requirements

SD U3O2 KK06 Features and purposes of software requirement specifications slideshow slideshow SRS - Software specification requirements

SD U3O2 KK07

Tools and techniques for depicting the interfaces between Solutionglossary links, users and networks, including

  • use case diagrams created using Unified modelling language (UML)glossary link slideshow Use Case Diagrams (UCD)


SD U3O2 KK08

Features of

  • context diagrams and
  • data flow diagrams slideshow Data flow diagrams (DFD) and context diagrams (CD) slideshow Data flow diagram example


SD U3O2 KK09 Techniques for generating design ideas slideshow Design Ideas


SD U3O2 KK10 Criteria for evaluating the alternative design ideas and the Efficiencyglossary link and Effectiveness of Solutionglossary links. slideshow Evaluation


SD U3O2 KK11

Methods of expressing Solutionglossary link designs using

  • data dictionaries,
  • mock-ups,
  • object descriptions and
  • Pseudocodeglossary link slideshow Design tools slideshow Design factors slideshow Mockups slideshow Data dictionary slideshow Pseudocode


SD U3O2 KK12

Factors influencing the design of Solutionglossary links, including

  • affordance,
  • interoperability,
  • marketability,
  • security and
  • usability slideshow Design Factors slideshow Affordance

Yes, "affordance" - not "affordability" as was written in the same KK in the 2016 study design! Big whoops from VCAA there :-)

SD U3O2 KK13 Characteristics of user experiences, including Efficientglossary link and effectiveglossary link user interfaces slideshow Interface design


SD U3O2 KK14

Development model approaches, including

  • agile,
  • spiral and
  • waterfall

Software Development Life Cycle (SDLC) Development models agile, spiral and waterfall


SD U3O2 KK15

Features of Project managementglossary link using Gantt charts, including the identification and sequencing of

  • tasks,
  • time allocation,
  • dependencies,
  • milestones and
  • critical path slideshow Gantt Charts slideshow Project Management (you can safely ignore discussion of PERT charts, exciting and useful as it is)


SD U3O2 KK16 Goals and objectives of organisations and Information systemglossary links slideshow Goals and objectives of organisations and systems slideshow Strategic, tactical and operational goals and objectives


SD U3O2 KK17 Key Legal requirementsglossary link relating to the ownership and privacy of data and information. slideshow Data privacy slideshow Copyright


SD U4O1 KK01

Procedures and techniques for handling and Managing filesglossary link and data, including

  • archiving,
  • backing up,
  • disposing of files and data and
  • security slideshow Data security threats slideshow Data security slideshow Testing network security

SD U4O1 KK02

Ways in which

  • storage media,
  • transmission technologies and
  • organisation of files

affect access to data slideshow


SD U4O1 KK03

Uses of Data structureglossary links to organise and manipulate data slideshow Arrays slideshow Linked Lists slideshow Records and files slideshow Hashing


SD U4O1 KK04

Processing featuresglossary link of a programming language, including

  • classes,
  • control structures,
  • functions,
  • instructions and
  • methods slideshow Processing features


SD U4O1 KK05

Characteristics of Efficient and effective Solutionglossary links slideshow Efficient and effective solutions


SD U4O1 KK06

Techniques for checking that coded Solutionglossary links meet design specifications, including

  • construction of test data slideshow Test Data


SD U4O1 KK07

Validationglossary link techniques, including

  • existence checking,
  • range checking and
  • type checking
Data Validation


SD U4O1 KK08

Techniques for Testingglossary link the usability of Solutionglossary links and forms of documenting test results slideshow Testing


SD U4O1 KK09

Techniques for recording the progress of projects, including adjustments to

  • tasks and timeframes,
  • annotations and
  • logs slideshow Gantt charts slideshow Gantt and PERT charts (PERT is not examinable, but nice to know)


SD U4O1 KK10

Factors that influence the Effectiveness of development models slideshow

SD U4O1 KK11

Strategies for evaluating the Efficiencyglossary link and Effectiveness of

  • software Solutionglossary links and
  • assessing project plans. slideshow Evaluation


SD U4O2 KK01

Physicalglossary link and software security controls used to protect software development practices and to protect software and data, including

  • version control,
  • user authentication,
  • encryption and
  • software updates

Version control


User authentication




Software updates slideshow Data security threats slideshow Data security slideshow Testing network security

Penetration Testing (White Hat - Ethical hacking)


SD U4O2 KK02

Software auditing and Testingglossary link strategies to identify and minimise potential risks slideshow Testing slideshow Trace tables, desk checks slideshow Test data


SD U4O2 KK03

Types of software security and data security vulnerabilities, including

  • data breaches,
  • man-in-the-middle attacks and
  • social engineering

and the strategies to protect against these slideshow


SD U4O2 KK04

Types of web application risks, including

  • cross-site scripting and
  • SQL injections

Cross-site scripting


SQL injections



SD U4O2 KK05

Managing risks posed by software acquired from third parties slideshow

Let's start with definitions:

  • First party refers to stuff (software, data, sandwiches etc) you generated yourself.
  • Second party is not collected by you, but comes from someone else - a trusted partner or colleague.
  • Third party comes from any other - possibly unknown - source. It may be 100% accurate and reliable - or it may not.

Don't confuse first/second party data with primary/secondary data.First, second or third part data could all be either primary (from original sources) or secondary (from sources that quote or process primary data).

Software from third parties has to be treated as if it carries the bubonic plague. Even if your dear old mum emailed you a "funny program" on it, you would be wise to put on rubber gloves before handling it.

Any software you did not create yourself, regardless of its origins, must be initially with suspicion. Even second-party software from your most reliable source might have been infected by trojans, viruses, worms or other malware before you got it.

Software downloaded from the internet is especially dubious. Using pirated software is like kissing a crocodile: you never know what may happen. Even if you have fifteen of the best antivirus software suites installed, a zero-day exploit may get past every one of them and your system will be immediately toasted.

Possible Payloads

The payload is the type of damage that malware can achieve. The term is derived from the power of military explosives.

Malware aka a computer "virus" nowadays can mean all sorts of bad software, such as:

  • a virus - malicious software that usually arrives in an infected document or program and needs user action to copy itself and spread. Old viruses used to delete files or cause minor mischief, and are rare nowadays.
  • a worm - malicious software that (unlike a virus) can reproduce and spread on its own without user assistance. Entire networks can be infected from a single infected computer.
  • a Trojan is not a different technology to viruses or worms. It's a Trojan's behaviour that sets it apart: it gets into a system by pretending to be a friendly and harmless helpful download but it harbours evil content. It's a reference to the Trojan Horse at the ancient battle of Troy.
  • ransomware - your computer is locked out: and any others on your LAN. You must pay to decrypt your own storage devices.
  • bitcoin miner - enslaving your GPU to waste your electricity and cores while slowing your computer down.
  • keylogger - saving your keystrokes as you enter passwords - and then sending your credentials to hackers.
  • spyware - so your stalker or ex can monitor your online activities and take remote control of your computer.
  • rootkit - a specialised type of malware that gives attackers access to the most basic, sensitive parts of a computer system.

Most malware is designed to

  • delete, damage, encrypt or steal data or documents
  • steal sensitive user information or login/password credentials
  • allow secret access to and control of a computer or a system
  • act as a parasite to exploit victims' IT resources to serve the attacker's needs (e.g. bitcoin mining)
  • change a computer's behaviour, e.g. to show popup ads, change which sites a browser goes to, participate as a zombie in DDOS (distributed denial of service) attacks

And realise that Apple and Linux computers and phones are just as susceptible to malware as Windows or Android devices - they just aren't targeted as often because they are smaller populations of users and not worth the effort.

  • Always keep your malware scanners running and up to date.
  • Keep an eye on new social engineering exploits, e.g. leaving infected USB keys lying around so victims will plug them in to their computers
  • Update your operating systems so the most up-to-date security measures are working.
  • Do not automatically click on links in emails, or open attachments - especially those in your spam folder.
  • Before clicking on ANY link, read it and ask yourself if it looks genuine. If in doubt, go to the organisation's public homepage and navigate from there.
  • Never call phone numbers given in unsolicited emails. Go to the genuine organisation's webpage and get the phone number from there.

Managing the risks

- Company rule: do not bring in software from outside the organisation. Do not install your own programs onto a company-owned laptop, for example. Do not bring in your own network devices (especially wifi routers) and connect them to company networks.

- Company's file server should be set to scan for malware in all files on users' devices.

- Educate users about what social engineering looks like, and how to avoid risky behaviour (e.g. opening attachments, using software from dubious sources). 95% of user error is ignorance, and not malicious intent.





SD U4O2 KK06

Characteristics of data that has integrity, including

  • accuracy,
  • authenticity,
  • correctness,
  • reasonableness,
  • relevance and
  • timeliness slideshow Data integrity

SD U4O2 KK07

Reasons why individuals and organisations develop software, including meeting the goals and objectives of the organisation slideshow Goals & Objectives (take 1) slideshow Goals & Objectives (take 2)

I'm not sure why I did goals and objectives twice... let me know if you figure out how they differ :-)

SD U4O2 KK08

Key legislation that affects how organisations control the collection, storage (including cloud storage) and communication of data:

  • the Copyright Act 1968,
  • the Health Records Act 2001,
  • the Privacy Act 1988 and
  • the Privacy and Data Protection Act 2014 slideshow Data privacy slideshow Copyright


SD U4O2 KK09

Ethical issues arising during the software development process and the use of a software Solutionglossary link slideshow Ethical dilemmas


SD U4O2 KK10

Criteria for evaluating the Effectiveness of software development security strategies slideshow


SD U4O2 KK11

The impact of ineffective security strategies on data integrity slideshow Data integrity slideshow Threats to data slideshow Data Security

Possible impacts - a summary:

  • loss of trade secrets
  • potential violation of the Privacy Act, Health Records Act etc
  • if personal information is damaged or released loss of reputation as a trustworthy organisation
  • loss of income after catastrophic data loss destroys your ability to get paid by customers or conduct business
  • prosecution by the tax office if tax records are lost
  • corporate death
SD U4O2 KK12

Risk management strategies to minimise security vulnerabilities to software development practices.

Non-specific, but relevant stuff is in... slideshow Threats to data slideshow Data Security



Go back to wherever you were before this page

All original content copyright ©
All rights reserved.

This page was created on 2022-01-17
Last modified on Saturday 29 October, 2022 15:11

Saturday 29 October, 2022 15:11