Software Development

Software Development

Key Knowledge

Jump to U3O1U3O2U4O1U402

20 Jan 2017 – IMPORTANT NOTE
The assessment criteria for the SD SAT have changed for 2017.
Update them here …  VCAA SD SAT & School Based Assessment (PDF)

Legend
  • SD = Software Development
  • UxOy = Unit x Outcome y
  • KK = key knowledge
  • AOS = area of study
  • SAT = school assessed task (U3O2 + U4O1 combined)
  • SAC = school assessed coursework (U3O1, U4O2)
Other SD goodies
Remember
  • All of the items listed after the word “including” are examinable.
  • All relevant items in the glossary are examinable.

Software Tools -SD

Unit 3 Software tools that students are required to both study and use in Unit 3*

  • AOS 1 -An appropriate programming language
  • AOS 2 – Unified modelling language to create use cases

Software tools that students are required to use, but not study in unit 3*

  • U3 AOS 2 – Appropriate tool for documenting project plans  

Unit 4 Software tool that students are required to both study and use in unit 4*

  • U4 AOS 1 – An appropriate programming language

Software tool that students are required to use, but not study, in unit 4*

  • U4 AOS 1 – Appropriate tool for documenting project plans  

* The  ‘Advice for Teachers’ slideshow explains that: Software that is to be “STUDIED AND USED” have explicit reference made to the relevant software functions in the key knowledge and hence the skills in using this software are assessable  

Software that is said to be just ‘USED?? needs to be used by students, but is not part of the key knowledge and their skills in using the software are not assessed. What is assessed is the knowledge or skills that are demonstrated through the use of the software.

 

SD U3O1

Interpret designs and apply a range of functions and techniques using a programming language to develop working modules.

SD U3O1-KK01 – characteristics of data types

The VCAA Glossary says that

  • Data types are the particular forms that an item of data can take including numeric, character and Boolean, and are characterised by the kind of operations that can be performed on it…
  • these fundamental types can be divided into more specific types, for example integer and floating point are numeric types.
  • More sophisticated types can be derived from them, for example a string of characters or a date type.
  • Their names may vary, such as text versus string.

ppt-iconData Types (updated for 2016)

SD U3O1-KK02 – types of data structures, including

  • one-dimensional arrays (single data type, integer index) and
  • records (varying data types, field index)

ppt-iconArrays (keep in mind that two dimensional arrays are not examinable)

A record is a user-defined fixed-length group of fields (of various data types) that can be treated as a single unit. When saved to disk as a random file, records are very quickly loaded since any record’s position in the file can be calculated by its record number and the record length. The drawback of records is that text fields must have their maximum length pre-defined, so excess text is truncated (cut off and lost) and small pieces of text still consume the entire pre-defined storage space, leading to wasteful storage.

A record might be defined like this:

(Note: the ‘as string * 15’ means the string field is 15 characters long. The lengths of other field types are automatic.)

STRUCTURE person
   GivenName as string * 15
   FamilyName as string * 25
   DOB as date
   NumKids as integer
   Married as boolean
END STRUCTURE

In a program, fields within the record might be addressed like so:

if person.NumKids = 0 then FamilyAllowance ? False

SD U3O1-KK03 – methods of representing designs, including

Object description – this simply lists all of the necessary properties of an object, such as for a textbox on an interface:

Name txtFamilyName
Caption Family Name
Visible True
ForeColour Black
Size 12
Font Arial

Obviously, only the properties relevant to the object’s class would be listed.
Properties whose default value is satisfactory need not be listed.

SD U3O1-KK04 – formatting and structural characteristics of input and output, including XML file formats

ppt-icon XML file formats

SD U3O1-KK05 – a programming language as a method for developing working modules that meet specific needs

I have no idea what to say about this KK.
What does it mean?

I think the answer is “Yes. It is”

There are hundreds of programming languages, and each one has different strengths, weaknesses and features. Most professional programmers know a handful of languages intimately, and are acquainted with several more. This lets them choose the best language for each occasion, for example C for a device driver, Visual Basic for a prototype, Python for a web-based script.

SD U3O1-KK06 – processing features of a programming language, including

  • instructions
  • procedures
  • methods
  • functions
  • control structures

In brief:

Instruction – a statement that describes an action that a program should carry out.
Procedure – a self-contained group of instructions that carry out a specific task. Also known as a routine, subroutine, module. 
Method – an action that can be carried out on an object of a given class.  e.g. Button.Show – to make a button visible
Function – a procedure that calculates and returns a value.
Control Structure – a block of code that controls which lines of code will be executed. 

  • Selection structure, e.g. IF/THEN/ENDIF
  • Iteration structure – any looping structure such as FOR/NEXT, DO/WHILE
  • Sequence structure – lines are executed in the order they appear. And GOTO/EXIT

ppt-icon Functions, procedures, etc

SD U3O1-KK07 – techniques for linear and binary searching

Linear search – slow, simple, easy-to-implement method. Start with item 1: is this what we’re looking for? No? Let’s try the next item. Repeat until item is found, or data is finished. The only way to search unsorted data.

Linear search requires up to N comparisons to search N data items. If the dataset is small, a linear search will be quicker and easier to program, and may be (near as dammit) just as acceptable as a binary search. Who cares if a search takes 10 nanoseconds or 20 nanoseconds?

Binary search – much faster, harder to program, requires data to be sorted in ascending order.  Find the value mid-way through the data and ask “Is this the value we seek?” If so, search is finished. If not, is the value less than or greater than the mid-way value?  Dispose of the half of the dataset that cannot contain the sought value. Repeat until the value is found, or is proved to be not present.

Binary search rarely needs more than 4 or 5 comparisons regardless of the number of items searched – but it requires processing overhead to sort the dataset. Binary search becomes necessary for huge datasets.

 ppt-icon Linear and binary searching

SD U3O1-KK08 – techniques for checking that modules meet design specifications, including

  • trace tables and
  • test data

ppt-iconTrace tables (and desk checks)

Trace Tables (adapted from the BBC)

When testing software, it is sometimes necessary to test a number of conditions and sub-conditions at the same time.

A trace table can be used to record the outcomes of the test.
The trace table for a very simple example, such as x=y+2, would look like this:

y x
13 15
25 27
1200 1202

Test data

Specifically designed to find weaknesses in code. Test data should act as the ultimate stress test to show up every possible code fault.

Test data should include every conceivable type of input, and focus on data that will most rigorously test the points where errors are most likely to occur. Especially boundary conditions or ‘tipping points’.

Test data should also be as brief as possible (except when load testing)

Hint: most logical errors in real life programming, and especially in exam questions, occur on boundaries. Be on the lookout for code with a statement like  IF x < y THEN… because often the error is that < should have been <= . 

Comprehensive test data includes invalid inputs to test validation code, valid inputs and inputs that are valid but unusual or unexpected.

 ppt-iconTest data 

SD U3O1-KK09 – purposes and characteristics of internal documentation, including

  • comments and
  • meaningful names.

Remember that internal documentation are comments in source code that explain the purpose of instructions. They are intended for programmers, not end-users of the software.

Compilers ignore internal documentation, so comments add no size to executable programs.

Often programmers will re-visit their software years after finishing it, so explanations of its function are always welcome reminders. Also, other programmers will usually work on your code, so it is polite to explain complex or mysterious code to them.

Good internal documentation should be non-trivial. Explaining that 

// add one to the count
Count equals Count + 1

will not be useful to anyone!

But something like this

// Temp is in Fahrenheit
Temp equals Temp + 1

does add information that the raw code lacks.

ppt-icon Naming Conventions

SD U3O2

Remember – this is part 1 of the SAT that concludes with U4O1

“Analyse and document a need or opportunity, generate alternative design ideas, represent the preferred solution design and formulate a project plan for creating the solution.”

Read details of the SAT

SD U3O2-KK01 – techniques for collecting data to determine needs and requirements, including

  • interviews,
  • surveys and
  • observation

ppt-icon Data collection techniques

SD U3O2-KK02 – features of functional and non-functional requirements

ppt-icon Analysis Activities – requirements, constraints etc

SD U3O2-KK03 – constraints that influence solutions, including

  • economic,
  • legal,
  • social,
  • technical and
  • useability factors

Here are only a few ideas…

Economic

  • The ideal solution may be too expensive for the organisation to develop or maintain once it has been developed. For example, developing a super-sophisticated network that requires a team of technicians, programmers and consultants to keep it working properly.
  • The preferred product may end up being too expensive for its target market. Features may need to be removed or scaled down to get a competitive product onto the shelves.

Legal

  • It might be tempting to ‘borrow’ code you developed for a previous employer to solve a current problem with your new employer. But using the code would violate the Copyright Act 1968, even though you created it. You previous employer is its legal owner.
  • Increasing the size of your mailing list by harvesting addresses from forums and websites would violate the Spam Act 2003.
  • Cutting corners on security may knowingly put sensitive data at risk and violate the Privacy Act 1988.

Social

  • Releasing a mega-violent game aimed at young children that would offend the community.
  • Using language or beliefs that are meant to deliberately offend or exclude sections of society.
  • Creating a social networking product that prevents young people deleting photos or posts that they later regret and want to remove.
  • Protecting users from spammers, con men, identity thieves, haters.
  • Making users feel comfortable and safe when using the solution.
  • Complying with social preferences and taboos in known markets (e.g. images of gods or unclad women).

Technical

  • Creating a product that creates documents that cannot import the market leader’s product or export in a compatible format for the competition’s product.
  • Needing to create a product that is compatible with global standards, protocols and practices. For example, an onscreen keyboard should be in QWERTY format. HTTP is used for web page transfer.
  • Creating a product that will still work well within the technical limits of a product’s RAM, secondary storage (HDD, SDD, Flash RAM), bandwidth, screen size.
  • A product may need to be compatible with a partner’s information system so you can exchange documents. For example, if an author produces documents that the publisher’s or printer’s systems cannot read, things will not go well.

Useability

  • Products should cater to the known accessibility needs of its audience.
  • A product should be designed so it minimises the need for learning how to use it.
  • Products should follow conventions to make new solutions seem familiar and approachable to their users.
  • Products should anticipate common user errors and gracefully allow users to recover from undesired actions (e.g. ‘Back’ and ‘Cancel’ buttons, ‘Are you sure?’ warnings before major actions, ‘undo’ and automatic background backups to allow rolling back to previous states or recovering data from ‘lost’ documents.)

ppt-icon Still to come

SD U3O2-KK04 – factors that determine the scope of solutions

 ppt-icon Still to come

SD U3O2-KK05 – features and purposes of software requirements specifications

ppt-icon Still to come

SD U3O2-KK06 – techniques for generating design ideas

No one technique is directly examinable, but typical and common techniques include:

  • brainstorming 
  • mind maps 
  • various diagrams like PMI (Plus/Minus/Interesting), POOCH, Venn, Fishbone
  • SCAMPER (see the slideshow)
  • forums 
  • external consultants 

ppt-icon Techniques for generating design ideas

SD U3O2-KK07 – criteria for evaluating alternative design ideas and the efficiency and effectiveness of solutions

ppt-icon Still to come

SD U3O2-KK08 – tools and techniques for depicting the interfaces between solutions, users and networks, including

  • use case diagrams created using Unified Modelling Language

ppt-iconUse Case Diagrams

SD U3O2-KK09 – features of context diagrams and data flow diagrams

 ppt-iconContext diagrams and data flow diagrams (DFD)

ppt-iconData flow diagram worked example

SD U3O2-KK10 – methods of expressing software designs using

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

ppt-icon Pseudocode

ppt-icon Mock-ups

ppt-icon Data Dictionary

Object descriptions are described in SDU3O1 KK3 (above)

SD U3O2-KK11 – factors influencing the design of solutions, including

  • useability,
  • affordability,
  • security,
  • interoperability and
  • marketability

Useability – The degree to which an object, device, software application, etc. is easy to use to achieve objectives. 

Affordability – includes the original purchase price or development costs (or ongoing subscription costs), plus ongoing running and maintenance costs.

Security – in some solutions, especially those that are online or responsible for managing money or sensitive data, security is a vital criterion. Achieving good security is a difficult and expensive process.

Interoperability – the ability of a solution to cooperate and communicate with other systems.

Marketability – the ease of selling the solution.

For details, see the slideshow…

ppt-icon Design Factors

SD U3O2-KK12 – characteristics of user experiences, including

  • efficient and effective user interfaces

ppt-icon User Interfaces

SD U3O2-KK13 – naming conventions for solution elements

 ppt-icon Naming Conventions

 SD U3O2-KK14 – project management concepts and processes,

including (concepts)

  • milestones and
  • dependencies,

and (processes)

  • task identification,
  • sequencing,
  • time allocation,
  • resources and documentation using Gantt charts

Milestones are major points of progress in a project, for example the end of the design stage.
There are no tasks or time required for the event, so milestones are shown as zero-duration, and are represented as diamond shapes. 
Milestones are used to judge whether a project is on schedule or not.

A dependency means that a following dependent task cannot be begun until a previous task has been completed.
The first task is called the predecessor, and the dependent task is the successor.
For example:
Task 1: Put on socks. (The predecessor task)
Task 2: Put on shoes. (The successor task, is dependent on Task 1. It cannot be started before the socks are on. Unless you’re really weird.)

The processes of

  • task identification,
  • sequencing,
  • time allocation,
  • resources and
  • documentation using Gantt charts

You must use a Gantt chart for the SAT.
(You can also use PERT if you like, but it’s not examinable and only the Gantt chart will be assessed for the SAC.)

  • Task ID – The first step is to list every task that needs to be done in the project. Don’t leave any out.
  • Sequencing – Getting tasks in order, based on their dependencies.
  • Time allocation – Deciding how much time each task will take. In a Gantt chart, this affects how long each task’s bar is.
  • Resources – assigning workers and equipment to tasks so people and hardware/software are available when needed, and not already busy working on a different task. Good Gantt software will warn when resources are being double-booked.
  • Documentation using Gantt charts –  put these pieces of information step by step into the Gantt chart.

ppt-icon Gantt Charts

SD U3O2-KK15 – security considerations influencing the design of solutions, including

  • data protection and
  • authentication

ppt-icon Still to come

SD U3O2-KK16 – styles of modern application architecture, including

  • mobile,
  • rich client,
  • peer-to-peer and
  • internet applications

ppt-icon Still to come

SD U3O2-KK17 – types of goals and objectives of organisations and information systems

 ppt-icon Goals and objectives

SD U3O2-KK18 – key legal requirements relating to the ownership and privacy of data and information.

These would especially include: Copyright Act, Privacy Act, Health Records Act

ppt-icon Still to come

 

SD U4O1

Remember – this is part 2 of the SAT that began in U3O2

“Apply stages of the problem-solving methodology to create a solution using a programming language that fulfils identified requirements and assess the effectiveness of the project plan in monitoring progress.”

Read details of the SAT

SD U4O1-KK01 – ways in which file size, storage medium and organisation of files affect access of data

 ppt-icon Still to come

SD U4O1-KK02 – uses of data structures to organise and manipulate data, including

  • associative arrays (or dictionaries or hash tables)

ppt-icon Associative arrays, hash tables, hashing functions

SD U4O1-KK03 – procedures and techniques for handling and managing files, including

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

ppt-icon Still to come

SD U4O1-KK04 – processing features of a programming language, including

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

ppt-icon Still to come

SD U4O1-KK05 – algorithms for sorting, including

  • selection sort and
  • quick sort

and their suitability for a given purpose, measured in terms of algorithm complexity and sort time.

Selection sort is inefficient when sorting large lists, but is relatively simple to implement, like bubble sort.

Method: the data to be sorted are divided into two parts: the data items that have already been sorted and moved to the start of the list; and the data items that have not yet been sorted.

Selection sort then finds the smallest (or largest, if sorting in descending order) data item in the unsorted items.  It swaps that item with the leftmost item in the unsorted list. It then moves the dividing line between sorted/unsorted items 1 place to the right.

ppt-icon Selection sort

Quicksort is a more complex algorithm, and its harder to code, but it is generally faster than selection sort – especially when the dataset is large.

SD U4O1-KK06 – characteristics of efficient and effective solutions

 ppt-icon Still to come

SD U4O1-KK07 – techniques for checking that coded solutions meet design specifications, including

  • construction of test data

ppt-icon Testing

SD U4O1-KK08 – validation techniques, including

  • existence checking,
  • range checking and
  • type checking

ppt-icon Validation

SD U4O1-KK09 – techniques for testing the useability of solutions, and forms of documenting test results

 ppt-icon Testing, test data etc

SD U4O1-KK10 – techniques for recording the progress of projects, including

  • annotations,
  • adjustments to tasks and timeframes, and
  • logs

ppt-icon Still to come

SD U4O1-KK11 – factors that influence the effectiveness of project plans

ppt-icon Still to come

SD U4O1-KK12 – strategies for evaluating the efficiency and effectiveness of solutions and project plans.

ppt-icon Still to come

SD U4O2

Analyse and explain the dependencies between two information systems and evaluate the controls in place in one information system to protect the integrity of its source data.

SD U4O2-KK01 – reasons why individuals and organisations use information systems

ppt-icon Still to come

SD U4O2-KK02 – goals and objectives of information systems

ppt-icon Goals and objectives

SD U4O2-KK03 – types of interactions (inputs and outputs) generated by information systems

ppt-icon Still to come

SD U4O2-KK04 – characteristics of data that has integrity, including

  • accuracy,
  • timeliness,
  • reasonableness,
  • authenticity,
  • correctness

ppt-icon Still to come

SD U4O2-KK05 – key legislation that affects how organisations control the storage, communication and disposal of their data and information:

  • the Privacy Act 1988,
  • the Privacy and Data Protection Act 2014,
  • the Copyright Act 1968,
  • the Spam Act 2003 and
  • the Charter of Human Rights and Responsibilities Act 2012

ppt-icon Privacy Act 1988 (plus amendments)

ppt-icon Copyright Act 1966

ppt-icon Charter of Human Rights and Responsibilities Act 2012

ppt-icon Spam Act 2003

The Privacy and Data Protection Act 2014 replaces the previous study design’s Information Privacy Act which – in brief – regulates only the way Victorian government and public service departments (including state schools, universities, police etc) handle data. It does not affect private companies or citizens.

SD U4O2-KK06 – data management practices that cause conflict between information systems, including

  • data mining

ppt-icon Still to come

SD U4O2-KK07 – advantages and disadvantages for stakeholders affected by the operation of information systems

ppt-icon Still to come

SD U4O2-KK08 – the impact of diminished data integrity on dependent systems

ppt-icon Still to come

SD U4O2-KK09 – the technical underpinnings of

  • intranets,
  • the internet and
  • virtual private networks

ppt-icon Web Servers

ppt-icon Intranet, internet, VPN (link fixed 1 Sept 2017)

ppt-icon Network Hardware

ppt-icon Still to come

ppt-icon Still to come

 

SD U4O2-KK10 – characteristics of

  • wired and
  • wireless networks

ppt-icon Still to come

SD U4O2-KK11 – types and causes of accidental, deliberate and events-based threats to the integrity and security of data and information shared between information systems

ppt-icon Security Threats

SD U4O2-KK12 – the physical and software controls used by organisations to secure the storage and communication of data in a networked environment

ppt-icon Network audits, error logs

ppt-icon Still to come

SD U4O2-KK13 – the role of

  • hardware,
  • software and
  • technical protocols

in

  • managing,
  • controlling
  • securing

data shared between information systems

Wow. You could write 3 entire books on this one KK.
Let’s try a table to expand all nine of the KK’s possibilities…

  Hardware Software Protocols
Managing – Switches, to connect LAN nodes and allow data exchange – File manager
– Batch renaming
– Media metatag editor
– 
– HTTP to manage web traffic
-FTP to manage file transfers
Controlling TO BE CONTINUED  –
Securing

– Routers to prevent unauthorised LAN access from outside the LAN.
– VPN box
– Dual-factor authentication code generator (security tokens)
– Biometric scanners (e.g. fingerprint scanner)
– Fibre optic cable (which is nearly impossible to tap into without being detected)
-Physical locks on server room doors, windows.
-Swipe card access to sensitive data or locations.
– Firewall hardware in router.
– Running data cables through conduit to hide and protect them.
-Kensington cables to lock down devices containing sensitive data.
– Burglar/fire alarms to identify physical threats to infrastructure.
– Backup hardware
– External drives with inbuilt hardware encryption
– UPS to protect servers from power cuts or surges
– Air conditioning to protect servers from heat or humidity.

 

– Antivirus
– Spyware scanners
– Malware scanners (e.g.  for Trojans, root kits)
– Network monitoring software to detect intrusion attempts (e.g. via wifi)
– File encryption (e.g. PGP)
– CAPTCHA to identify robotic logins
– Software firewall in operating system
– Software to lock out accounts after a given number of failed login attempts

– SSL or TLS (to allow HTTPS)
– VPN

ppt-icon Still to come

SD U4O2-KK14 – tools and techniques for tracing transactions between users of information systems.

ppt-icon Still to come

Page created : 2015-06-18 at 11:14:40 AM

VCE IT Lecture notes copyright © Mark Kelly 2001- now

VCE Computing Study Design copyright © VCAA. Used with permission. Thanks, VCAA!

Leave a Reply