VCE Software Development Units 3 and 4 

KK = Key Knowledge. All KK are examinable
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.

Note from 2023-10-04: The VCAA Curriculum Manager confirms that glossary items are only examinable if they also appear in KK. Others are just examples.

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.

is cute, but completely irrelevant.

Check out my incomplete 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? the glossary lists it]

Records and files

Hashing

The glossary also says: Types of data structures include: arrays, associative arrays, classes, fields, files, hash tables, linked lists, queues, records and stacks.

Terms in the glossary are only examinable if they also appear in a KK after "including..."

So, stacks appear in the glossary but not in any KK, so they are not directly examinable.

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

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

Do you have a spare month or two in which to discuss this KK in detail? No? Let's keep it brief, then.

Storage media

Let's look at size/capacity and speed of storage/transmission.

1. Size - Physical size of storage media - hard disks are big and heavy, compared with SSDs (solid-state disks), and NAND (e.g. USB keys, SD cards) which weigh next-to-nothing and can be as small as a fingernail. I tie a colourful ribbons to my 64GB / 128GB thumb drives so I don't lose them. But the sheer IMMENSE CAPACITY of spinning hard disks and their relative low cost still makes them valuable for mass data storage. Also keep in mind that the largest SSD you can buy in October 2023 is

Do this: go online a find the cheapest new 12TB SSD you can. Now look for the cheapest 12TB HDD. Calculate the cost per gigabyte and get back to me. I'll wait a few years. I bet I won't need to change my stance until the 2028 study design.

1. Capacity - old-fashioned spinning-metal hard disks still far outclass solid-state storage in terms of sheer storage capacity, and cost per terabyte.

Verdict:

For portability - NAND USB drives. SD cards for insertion into phones.

For daily speed and performance in computers - SSD and M2 / NVMe drives.

For sheer outright storage capacity - hard disks.

Transmission technologies

This gets quite technical. We have both LAN and WAN transmission to consider.

LAN (Local Area Network) transmission:

1. Wireless (Wifi) - 2GHz vs 5GHz. 2 is slower, but can can deal better with walls etc. 5 is faster, but has a weaker penetration of obstacles. We're looking at speeds of

2. Wired - CAT5 (category 5) - cable needs to be punched through walls and floors, but is much faster and more secure than wireless. Compare 1000mbps (cabled) with 54mbps (wifi) at 2023. CAT6 can reach far higher speeds than CAT5.

WAN (wide area network) transmission:

Don't worry too much about this, since it's usually out of your control. In the old days you might have been given ADSL (slow phoneline modem connection), but today you may be able to get Fibre to the node (FTTN) / curb (FTTC) / premises (FTTP) - each one offering increased speeds, depending on the plan you choose. e.g. NBN suppliers may offer plans with 100Mbps down / 40mbps up; others might offer 200Mbps down / 20 Mbps up. Swings and roundabouts, kids.

3. Satellite - remote users may have to rely on slowish satellite internet services. I have a friend in Siberia who has one.

4. Truck - for huge data transmission, it's still cheaper and quicker to put the data on a truck and ship it overland. True story. Amazon AWS offers the Snowmobile which "moves extremely large amounts of data to AWS. Transfer up to 100 PB [1 petabyte = 1,024TB] per Snowmobile, a 45-foot-long ruggedized shipping container pulled by a semi-trailer truck."

Organisation of files

I will get to this in a couple of years... maybe. Tell me if you need an urgent update

Uses of Data structures to organise and manipulate data - includes:

classes

A class is a type of object used in Object Oriented Programming (OOP).

It is a pre-defined type of thing. e.g. car, box, house, textbox, button that has basic features, but may be created with differering abilities and features.

For example, take the class of a textbox.

It is created by the language's developers with specific things that it can respond to (events), carry out (e.g. methods) and features than can be adjusted by the programmer (properties).

So a textbox object may be designed with events it can respond to, such as:

• GOTFOCUS - what the textbox should do when the user clicks on it
• KEYDOWN - what it should do when the users presses a key
• UNDO - what to do when the user wants to reverse the last action

Methods may include its ability to: move, refresh its contents, or resize itself,.

Properties are the characteristics that the programmer may give an instance of a class. (e.g. a specific textbox created for the entering of a postcode). Customisable values of an instance of a textbox object may include its:

• width
• border colour
• default value (the value that will be used if the user does not choose a different value)
• font size
• visibility (is it shown on screen or not?)
• justification (is the text aligned left, right, centred?)
• value (the text contained in the textbox)

So, a class is a type of object that has certain pre-defined abilities and adjustable qualilties.

That's why classes of house do not have events such as "losing traction on ice" and classes of car don't have properties such as "number of bedrooms."

fields

A field is a data type within a data structure or a file. They are most often seen in database records.

e.g. A record in a data base may contain fields such as FIRSTNAME, FAMILYNAME, DOB, STREETADDR, SUBURB,POSTCODE, SEX...

Each field has a data type (e.g. numeric, string, date) that applies to every data item in that field.

files

A file is a set of data stored in a discrete (separate) collection. The size of a file may vary from small (a few bytes or kilobytes) to gigabytes.

Each file's data is stored with a strict format, usually consisting of records, which in turn are made up of fields

- records (e.g. a collection of pre-defined fields decribing an object such as a

person (firstname, familyname, dateof birth, shoesize, suburb...)

raincoat (colour, length, material, number of pockets, hooded or not...)

Data files may be saved in a variety of formats on disk (to save time, let's assume ''disk" is any form of permanent storage)

Common file formats are:

• comma-delimited text - e,g, Smith, James, 30 Wombat St, Hightown, Vic, 3333
• CSV (comma separated values) e.g. "Smith, the Great", "A Time to Live, A Time to Die", "1856" (notice how CSV allows commas to be used within fields
• XML - a text-based file that contains and defines its own hierarchical structural definition. e.g. from Educba.com. Notice how each record and field has its own beginning and ending heading.The backslash (/) marks the end of a corresponding field, record or file name. The beauty of XML data files is that they contain their own database definition!

<bookstore>

<book>

<title>Java For Dummies</title>

<author>Tan Ah Teck</author>

<category>Programming</category>

<year>2009</year>

<edition>7</edition>

<price>19.99</price>

</book>

<title>More Java For Dummies</title>

<author>Tan Ah Teck</author>

<category>Programming</category>

<year>2008</year>

<price>25.99</price>

</book>

<title>The Complete Guide to Fishing</title>

<author>Bill Jones</author>

<author>James Cook</author>

<author>Mary Turing</author>

<category>Fishing</category>

<category>Leisure</category>

<language>French</language>

<year>2000</year>

<edition>2</edition>

<price>49.99</price>

</book>

</bookstore>

queues, and stacks

Hash tables

Linked Lists

Records and files

Arrays and associative arrays

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

In the Good Old Days™, programmers were solitary animals, living in putrid cellars, dining on yesterday's pizza, and wondering if their toenail infection was preventing them landing a supermodel girlfriend. No more.

Programmers now work in teams, collaborating on code, often working on the same code at the same time as a number of other coders spread across the city, country, or globe.

If one team's programmer tweaked a function at the same time as another programmer saved a different modification to the same function - what would happen? Chaos!

Version control keeps track of all code modifications in a database. If mistakes are made, they can be 'rolled back' (undone). If conflicting changes are made, one version can be kept and the others removed.

With version control, a thorough history of code development is maintained, and all changes are tracked.

User authentication

Obviously, a programming team needs to ensure that changes to code are being made by authorised people.

Secure logins and - if necessary - heightened authentication (e.g. two-factor identification) may ben needed to ensure that changes to code are being made by the right people.

Encryption

Duh. These days, any system manager would be fired for not strongly encrypting all stored code and data (e.g. RSA, DSA, RC4, DES), and not encrypting all traffic across a LAN and WAN (e.g. SSL, TLS).

Software updates

Outdated software is vulnerable to new (e,g, "zero day" = freshly-invented) security attacks. Android devices - typically phones - only receive system updates for a couple of years, but security updates can go on for far longer in order to keep the devices safe from new threats.

A danger of using outdated operating systems (like Windows 95) is that they are sitting ducks for thousands of attacks that were never even imagined when the OS was released. Think of new COVID strains: your jab from 3 years ago is not going to protect you from tomorrow's new mutant strain.

Code needs to be constantly updated to address new threats.

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

Let's quote the study design's definition of "effectiveness" : A measure of how well a solution, information management strategy or a network functions and whether each achieves its intended results.

We are not discussing efficiency, which only relates to time, money and effort.

We are looking for criteria (singular = criterion) - the features used for judgement.

In other words, what features of SD security strategies should be used to judge how well those strategies perform?

• speed of recognising a threat? No. That is an efficiency criterion.
• how many person-hours are required to keep a system secure? No. Again - efficiency.
• cost of keeping the system secure? You got it - efficiency, not effectiveness.

But keep those in mind because the examiners like to test on such distinctions in definitions.

So, what evaluation criteria are relevant to this KK?

- accuracy: if the system fails to recognise a genuine threat, ít's called a false negative. If it reacts to a non-threat as if it were a real threat, it's a false positive.

- attractiveness? Hardly.

- clarity - if a threat were vaguely identifed without enough information to deal with it, that would be an effectiveness failure. e.g. "One of the files just downloaded might be infected with a virus." Certainly not clear.

- relevance - if an error message appeared even if the threat did not apply to your operating system - that would be ineffective.

- timeliness - being warned about a threat three days after your system was compromised? NOT EFFECTIVE!

- usability - if a threat warning were buried deep in a system log file that you would NEVER EVER find - not effective!

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.