VCE IT Lecture Notes by Mark Kelly , McKinnon Secondary College

VCE Software Development 2011-2014

Visit the ITA Theory Summary page

Details of the mandated problem solving methodology are here.

The VCE Software Development study design is here.

Click the icons to see the Powerpoint 2003 slideshows
Click the hyperlinked text to read the web page.

Also refer to the VCAA IT FAQ published for the new study design and the glossary

Exam Post Mortems

SD Unit 3 Outcome 1

SD U3O1 KK01 - stages of the problem-solving methodology

Analysis

Design

Development

Evaluation

SD U3O1 KK02 - key tasks associated with planning software projects, including

• identifying tasks, resources, people and time - a work breakdown structure (WBS) is good for this.
• scheduling tasks, resources, people and time - Gantt or PERT charts are typically used in real projects.
• monitoring tasks, resources, people and time - milestones (major points of progress) tell you whether you are on track.

Note - knowledge of Gantt and PERT charts, milestones, slack, predecessors, lag, critical paths etc is not required. Nor is the use of project management software. Students only need to know the need for such project management skills. If you're still keen, see Gantt and PERT

SD Unit 3 Outcome 2

SD U3O2 KK07- criteria for evaluating the efficiency and effectiveness of solutions

Read up on the difference between evaluation and testing.

SD U3O2 KK11- techniques for checking that coded solutions meet design specifications, including construction of test data.

Test data is data that is deliberately created to fully test a solution with normal, abnormal and faulty data. Test data is designed to be deliberately difficult for a solution to process: it often includes "boundary condition" data that tests whether the solution is behaving properly with values that are on the border between one state and another. e.g. if you created a spreadsheet formula to determine whether a person's birthdate made them 18 years old, you would want to include test data that included "boundary condition" data such as "one day short of 18", "18 exactly" and "one day past 18" and test if the solution handled the "tricky situations" accurately or not.

You use test data rather than real data to avoid the chance of destroying the real and valuable data with a solution that is not yet working properly.

Read up on the difference between evaluation and testing.

From the 2003 SD exam:

Q12. If the condition 'Sales are greater than or equal to 100' needs to be tested, what would be the best test data?

A. 90,95,99
B. 98,99,100
C. 95,100,105
D. 100,150,1000

[C]  To test properly, you need data that meets the condition, and data that does not meet the condition.

[A] and [B] cannot test for "greater than" and [D] can't test for "less than" yet 41% of students chose [D]!

SD Unit 4 Outcome 1

SD U4O1 KK02- types and characteristics of mobile computing devices, including:

• PDAs
• mobile phones
• laptops
• gaming consoles

SD U4O1 KK03- procedures and techniques for handling and managing files, including security, archiving, backing up and disposing of files

• Archiving makes a copy of data that is no longer needed regularly. The copy is stored offline and the original data is deleted.
• Backing up makes a copy of data and retains the original data.

SD U4O1 KK04- methods of organising files to suit particular software needs, including serial and random access

SD U4O1 KK07- factors affecting solution design, including

• user interface,
• user needs,
• processing efficiency,
• development time,
• technical specifications of mobile devices

SD U4O1 KK09 - methods and techniques of expressing software designs

Data Dictionary

database

Entity relationship diagram

Websites

DFD

SRS

Others for SD

SD U4O1 KK12- validation techniques, including

• existence checking - referred to as Null checking in the 2010 SD exam
• range checking and
• type checking

Note - To muddy the waters, the 2010 SD exam referred to:
Existence - to make sure that the number entered exists on Medicare's database
Null - to make sure something has been entered

SD U4O1 KK14- techniques for checking that coded solutions meet design specifications, including construction of test data

Testing, and test data

SD U4O1 KK15- forms and types of user documentation, including

FORMS:

• printed,
• online Internet site

TYPES:

• quick start guide,
• tutorial,
• content sensitive help
• manual

Writing good documentation for SD U4O1

SD U4O1 KK17- legal obligations of programmers

See Copyright

See Privacy Act

See Human Rights & Spam Act

SD Unit 4 Outcome 2

SD U4O2 KK02- characteristics of wired and wireless networks

Network hardware

Network protocols

Internet, Intranets, VPN

Measuring network reliability

Testing Network Security

Networking

Designing LANs

SD U4O2 KK03- techniques for measuring the reliability and maintainability of networks, including audits, error logs* and software tracking tools]

*6/6/2011 - After I queried, VCAA announced that it should say "error logs", not "errors". Another erratum will be published.

SD U4O2 KK05- characteristics of efficient and effective solutions

• The difference between efficient and effective
• Efficient processing

SD U4O2 KK06- strategies and techniques for acquiring evaluation data about the quality of solutions

There are many ways to acquire data about a newly implemented system so it can be evaluated.
Of course, the data that needs to be acquired, depends on the criteria that need to be evaluated. These criteria would have been established during system analysis.

• interviewing users about their opinions of the system
• examining error logs to determine the reliability of the system
• timing its speed when carrying out a typical process
• load-testing the system to quantify its performance under pressure
• study its output to judge its readability, accuracy, attractiveness
• survey customers about the ease of use of the system
• refer to security logs to see if the system has been subject to successful hacking attempts
• pull the plug out and see if test data is lost or damaged, and how well the system recovers from power outage
• simulate other common errors, such as hard disk failure and see if the system copes as it should
• compare output from the new system with output from the old system and see if it is better
• check the financial figures to determine its total cost of ownership over a certain period
• refer to a log of complaints or suggestions for improvement by users or customers

More on evaluation criteria and methods.

SD U4O2 KK07- criteria and techniques for testing acceptance by users of solutions

Acceptance testing is black-box testing carried out on a system before it is delivered to its owner.

Black-box testing means that the tester is not concerned with how the system works internally. All the tester is concerned about is system inputs and outputs and whether everything works as it should. It's called black box testing because the interior of the system is invisible and mysterious as if it were in a black box, and only its outward behaviour is relevant and can be evaluated.

Acceptance testing may be carried out by the system provider to assure the client that the system performs in accordance with the logical design or system requirements specifications (SRS). This happens before ownership of the system is transferred to the client. It is a part of formal testing. It is a set of tests that conclusively proves that the system can satisfy the client's documented requirements of the system.

User acceptance testing (UAT) is carried out by the customer using typical users to ensure that the real user is satisfied that the system is usable. This is because the client is probably a manager who would not know whether the system was good or not from an expert daily operator's point of view. (Imagine your grandma choosing you a new phone for your birthday.)

UAT can also be known as end-user testing.

SD U4O2 KK11- suitability of setting codes of ethics, imposing sanctions, education programs and the use of decision-support frameworks as strategies for managing ethical dilemmas.

Unlike clear-cut legal issues, there are more areas of grey when dealing with ethical dilemmas (a dilemma is a situation where a decision needs to be made and the only options are equally unpleasant.) Since ethical decisions are so subjective (opinion-based) it is quite possible that there will not be consistency or perceived fairness in an organisation's decisions.

This is why some rules-based support is sometimes adopted in cases where ethical problems arise. They include:

Setting codes of ethics - if rules of conduct are formulated and enforced, it can prevent ethical problems arising in the first place. Organisations' acceptable use policies are such codes. e.g. if you are related to a person applying for a job in your organisation, you must disclose the fact before the person is employed and you may not be part of the candidate selection process.

Imposing sanctions - sanctions are actions taken (usually a form of punishment) to enforce a society's standards. Punishing those who transgress a group's accepted code of ethics makes them less like to repeat the behaviour, and reminds others of the consequences of such behaviour.

Education programs - if ethical problems arise because the person was not aware that certain behaviours were not allowed, education may be more effective than punishment. Once people are aware of what is expected, they have no excuse for future transgressions.

The use of decision-support frameworks - if leaders used only their personal ethics when judging ethical issues, the results may be inconsistent or may be seen to be unfair. For example, if a strongly religious boss severely punished a worker for blasphemy, but another boss merely chided another worker for the same offence, there would be understandable unquiet amongst workers. If there were strict procedures for making such decisions, the results would be predictable, consistent and fair. For example, in cases of ethical breaches, there may be established procedures for judging the case (e.g. a tribunal composed of bosses, co-workers, union reps), established methods of collecting evidence (e.g. sworn statements) and agreed levels of sanctions to choose from (e.g. a reprimand for a first offence, termination for a repeat offence.) Such frameworks also make it easier for decision makers to take actions that are unpleasant or unpopular.

Sample code of ethics from the ACS (Australian Computer Society)

Code of Ethics

As a member you must uphold and advance the honour, dignity and effectiveness of being a professional. This entails, in addition to being a good citizen and acting within the law, your adherence to the following Society values:

• The Primacy of the Public Interest
  You will place the interests of the public above those of personal, business or sectional interests.
  
• The Enhancement of Quality of Life
  You will strive to enhance the quality of life of those affected by your work.
  
• Honesty
  You will be honest in your representation of skills, knowledge, services and products.
  
• Competence
  You will work competently and diligently for your stakeholders.
  
• Professional Development
  You will enhance your own professional development, and that of your colleagues and staff.
  
• Professionalism
  You will enhance the integrity of the Society and the respect of its members for each other.
  

This Code of Ethics applies to all members regardless of their role or specific area of expertise in the ICT industry.