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.

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.

Characteristics of Data types

Data types

Types of Data structures, including

• associative arrays (or dictionaries or hash tables), [not to be confused with the data dictionary design tool]
• one-dimensional arrays (single Data type, integer index) and
• records (varying Data types, field index)

Arrays

Linked Lists [not examinable]

Records and files

Hashing

Problem Statements

SRS - Software specification requirements

Methods of representing designs, including

• data dictionaries,
• mock-ups,
• object descriptions and
• Pseudocode

Data dictionaries

Mockups

Pseudocode

Design tools

Design factors

Design tools for databases

Entity relationship diagrams (ERD) for databases

Formatting and structural characteristics of files, including

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

XML

Plain text data consists of (drumroll) - plain ASCII text, 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

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

Carlton,Anderson,Ken,3/10/2005

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

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.

Programming skills ?

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?

Naming conventions

Database structure naming

File Naming

Processing features of a programming language, including

• classes,
• control structures,
• functions,
• instructions and
• methods

Functions, statements etc

Quick summary -

Classes

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

e.g.

• 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

LOOPS (iteration) - FOR / NEXT , DO / LOOP, WHILE / UNTIL, LOOP / WHILE

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

Compare:

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"

END CASE

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.

Algorithms for sorting, including

• selection sort and
• quick sort

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.

Algorithms for

• binary searching and
• linear searching

Searching - linear and binary

Searching, sorting, filtering

Validation techniques, including

• existence checking,
• range checking and
• type checking

Data Validation

Techniques for checking that modules meet design specifications, including

• trace tables and
• construction of test data

Test data

Trace tables, desk checks

Purposes and characteristics of internal documentation, including

• meaningful comments and syntax.

Internal documentation

Security considerations influencing the design of solutions, 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.

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.

Techniques for collecting data to determine needs and requirements, including

• interviews,
• observation,
• reports and
• surveys

Data Collection techniques

For more details, see...

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

Constraints that influence Solutions, including

• economic,
• legal,
• social,
• technical and
• usability

SRS - Software specification requirements

SRS - Software specification requirements

SRS - Software specification requirements

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

• use case diagrams created using Unified modelling language (UML)

Use Case Diagrams (UCD)

Features of

• context diagrams and
• data flow diagrams

Data flow diagrams (DFD) and context diagrams (CD)

Data flow diagram example

Design Ideas

Evaluation

Methods of expressing Solution designs using

• data dictionaries,
• mock-ups,
• object descriptions and
• Pseudocode

Design tools

Design factors

Mockups

Data dictionary

Pseudocode

Factors influencing the design of Solutions, including

• affordance,
• interoperability,
• marketability,
• security and
• usability

Design Factors

Affordance

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

Interface design

Development model approaches, including

• agile,
• spiral and
• waterfall

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

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

• tasks,
• time allocation,
• dependencies,
• milestones and
• critical path

Gantt Charts

Project Management (you can safely ignore discussion of PERT charts, exciting and useful as it is)

Goals and objectives of organisations and systems

Strategic, tactical and operational goals and objectives

Data privacy

Copyright

Procedures and techniques for handling and Managing files and data, including

• archiving,
• backing up,
• disposing of files and data and
• security

Data security threats

Data security

Testing network security

Ways in which

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

affect access to data

Uses of Data structures to organise and manipulate data

Arrays

Linked Lists

Records and files

Hashing

Processing features of a programming language, including

• classes,
• control structures,
• functions,
• instructions and
• methods

Processing features

Characteristics of Efficient and effective Solutions

Efficient and effective solutions

Techniques for checking that coded Solutions meet design specifications, including

• construction of test data

Test Data

Validation techniques, including

• existence checking,
• range checking and
• type checking

Data Validation

Techniques for Testing the usability of Solutions and forms of documenting test results

Testing

Techniques for recording the progress of projects, including adjustments to

• tasks and timeframes,
• annotations and
• logs

Gantt charts

Gantt and PERT charts (PERT is not examinable, but nice to know)

Factors that influence the Effectiveness of development models

Strategies for evaluating the Efficiency and Effectiveness of

• software Solutions and
• assessing project plans.

Evaluation

Physical 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

Encryption

Software updates

Data security threats

Data security

Testing network security

Penetration Testing (White Hat - Ethical hacking)

Software auditing and Testing strategies to identify and minimise potential risks

Testing

Trace tables, desk checks

Test data

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

Types of web application risks, including

• cross-site scripting and
• SQL injections

Cross-site scripting

SQL injections

Managing risks posed by software acquired from third parties

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.

Characteristics of data that has integrity, including

• accuracy,
• authenticity,
• correctness,
• reasonableness,
• relevance and
• timeliness

Data integrity

Reasons why individuals and organisations develop software, including meeting the goals and objectives of the organisation

Goals & Objectives (take 1)

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

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

Data privacy

Copyright

Ethical issues arising during the software development process and the use of a software Solution

Ethical dilemmas

Criteria for evaluating the Effectiveness of software development security strategies

The impact of ineffective security strategies on data integrity

Data integrity

Threats to data

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

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

Non-specific, but relevant stuff is in...

Threats to data

Data Security

Go back to wherever you were before this page

All original content copyright © vcedata.com
All rights reserved.

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