Skip to content

Software Tools and Outcome-Specific Requirements

This page consolidates the "2025 Applied Computing Unit 3 and 4 Software Development: Software tools and functions and outcome-specific requirements" document so the study-design rules are easy to find alongside the rest of the course site.

Assessment and update note

Students can use code repositories during normal teaching and learning to become familiar with key knowledge, but they must not use code repositories for work completed as part of assessment. The document also notes that these requirements may be revised for 2026 and later advice will be published in the VCAA Bulletin.

Course-wide notes

  • For 2025, schools must use the software tools, functions and outcome-specific requirements listed in the study design.
  • Government schools should refer to the Department of Education's "Generative Artificial Intelligence: Policy" on education.vic.gov.au.
  • Catholic and independent schools should refer to their sector authorities for advice on generative artificial intelligence.
  • This page is a site reference for students; always check teacher instructions and any later VCAA updates as well.

Required software tools by area of study

Area of study Students must study and use Students must use, but are not required to study
Unit 3 Area of Study 1: Software development - programming An appropriate object-oriented programming language -
Unit 3 Area of Study 2: Software development - analysis and design UML tools to create use case diagrams An appropriate tool for documenting and modifying project plans; appropriate tools for ideation and generating designs
Unit 4 Area of Study 1: Software development - development and evaluation An appropriate object-oriented programming language An appropriate tool for documenting and modifying project plans; programming tools and/or IDEs to facilitate programming and testing

Programming languages

The document lists these languages as suitable examples:

  • Python
  • Visual Basic .NET
  • C#
  • PHP
  • Swift
  • Ruby
  • Golang (Go)
  • TypeScript
  • Objective-C
  • Java
  • JavaScript
  • Kotlin

This list is not exhaustive. Any programming language that meets the programming requirements below may be used in the delivery of the study.

Programming requirements

In Unit 3 Area of Study 1 and Unit 4 Area of Study 1, the chosen object-oriented programming language should support development across the three conceptual layers of interface, logic and data source.

Interface

The language must allow students to build a graphical user interface (GUI) through one or more of the following:

  • an Integrated Development Environment (IDE) using drag-and-drop / WYSIWYG tools
  • code written in the same language
  • code written in a supporting language

Logic

The language must support:

  • instructions
  • program control structures: sequence, selection, iteration / repetition
  • arithmetic operators: addition, subtraction, multiplication, division, integer division, modulus, unary plus / minus, increment / decrement
  • logical operators: AND, OR, NOT
  • conditional / comparison operators: equality, inequality, less than, less than or equal to, greater than, greater than or equal to
  • functions and methods
  • classes and objects

Data source

The language must support:

  • initialising, setting and accessing local variables, global variables and constants
  • relevant data types: numeric, text, Boolean
  • reading data from external sources such as files and databases, whether local or cloud-based
  • writing data to external sources such as files and databases, whether local or cloud-based

Supported file formats named in the document:

  • delimited (CSV)
  • plain text (TXT)
  • XML

1. Using prompts to generate code

Generative AI platforms can generate code quickly from a single prompt or a sequence of prompts.

Benefits

  • increased productivity through reduced development and debugging times
  • reduced development costs
  • enables non-developers to generate functional code
  • reduced need to build deep expertise in multiple languages
  • automated code documentation and improved code quality
  • possible support for problem-solving and innovation

Disadvantages

  • bugs and errors may still be present
  • results often depend on trial and error and very specific prompts
  • vulnerabilities and threats can be introduced
  • copyright concerns can arise
  • limited context or situational understanding
  • human oversight is still required

Example prompt

Create a program in [chosen OOP language] that takes in two integer values and then outputs the sum, product and average of the values. The output should be labelled.

2. Automated debugging and testing of modules

Automated debugging and testing tools have long been part of IDE workflows.

Benefits

  • real-time identification of issues with code
  • suggested fixes
  • rapid feedback
  • more consistent debugging and testing approaches
  • improved code quality

AI-related improvements

  • increased productivity
  • enhanced accuracy
  • scalability
  • identification of issues before they occur

Challenges

  • incorrect flagging of valid code or failure to detect subtle issues
  • dependence on training data
  • reduced job opportunities for developers and testers

Examples from the document

  • Python IDEs: Behave, Lettuce, Robot, Pytest, TestProject
  • Visual Studio: Live Unit Testing, IntelliTest
  • PHP: Codeception, Selenium

3. Code optimisation

AI tools can analyse code performance and suggest improvements linked to runtime, memory use, security and other technical requirements.

Types of optimisation listed in the document:

  • resource optimisation (CPU and memory)
  • algorithm optimisation
  • code simplification
  • standardisation to organisational or industry rules
  • security optimisation
  • automated comment generation and summarisation

Example tools named in the document:

  • GitHub Copilot
  • Tabnine
  • TensorFlow
  • Codeium

4. Responsible and ethical use of AI tools

Developers should use AI tools responsibly and ethically by:

  • understanding the technical limitations of each tool
  • being transparent about AI use
  • conducting thorough code reviews on AI-generated code
  • being aware of possible bias introduction
  • avoiding over-reliance on AI tools
  • understanding the environmental impact of AI usage
  • respecting intellectual property, copyright and licensing agreements

Unit 3: Analytical tools

For worked examples already on this site, see Analytical Tools.

Context diagrams (Level 0)

Context diagrams show the data flows between a system and external entities.

Components and symbols

  • System: represented by a circle containing the system name
  • External entity: represented by a labelled square or rectangle; duplicated entities can be shown with a diagonal line across the top-left corner
  • Data flow: represented by a labelled, unidirectional line with an arrowhead

Rules

  • data cannot flow directly between two entities
  • data flows cannot cross each other
  • each data flow should represent a single set of information being transferred

Data flow diagrams (Level 1)

Data flow diagrams depict how data is provided, processed, stored and output within a system. They should stay consistent with any context diagram for the same system.

Components and symbols

  • Process: represented by a circle containing the process name
  • External entity: represented by a labelled square or rectangle; duplicated entities can be shown with a diagonal line in the top-left corner
  • Data flow: represented by a labelled, unidirectional line with an arrowhead
  • Data store: represented by horizontal parallel lines with the stored data named between them

Rules

  • data cannot flow directly between entities
  • data cannot flow directly between data stores
  • data cannot flow directly between an entity and a data store
  • data flows cannot cross each other
  • each data flow should represent a single set of information being transferred
  • a process must have at least one input and one output
  • a data flow leaving a process should have a different name from the input received
  • a data store must have at least one input and one output
  • every process must connect to at least one data store, process or external entity
  • every external entity must provide at least one input or receive at least one output from the system

Use case diagrams

Use case diagrams visually represent interactions between users and a system.

Components and symbols

  • System boundary: a rectangle containing the use cases, associations and relationships, labelled with the system name in the top-left corner
  • Actor: a person icon or stick figure labelled with the role underneath or above the figure
  • Use case: an ellipse with the use case name inside
  • Association: a line between an actor and a related use case
  • Relationships: dashed unidirectional lines

Relationship types

  • <<includes>>: a base use case always incorporates the behaviour of another use case; the arrow points from the base use case to the included use case
  • <<extends>>: one use case extends the behaviour of another when certain conditions are met; the arrow points from the extending use case to the base use case

Unit 3: Ideation techniques and tools

For design-idea advice already on this site, see Design Ideas and Evaluation Criteria.

Mood boards

Mood boards collate imagery, colours, typography and code samples to explore the overall direction of a software solution. Samples can be annotated to show:

  • possible relevance to the solution
  • features to include
  • features to exclude
  • reasoning behind those decisions

Brainstorming

Brainstorming is an unstructured collection of related ideas around a central theme or concept. It can be documented as a list or as a diagram.

When it is shown as a diagram:

  • the central theme can be represented by a rectangle, cloud shape or ellipse
  • related ideas are connected to the central theme using straight lines

The document's example brainstorm ideas include:

  • design
  • user experience
  • design tools
  • interoperability
  • usability
  • colour
  • affordance
  • pseudocode
  • design principles
  • security

Mind maps

Mind maps are a structured collection of related ideas built around a central theme or concept. They use:

  • a central rectangle, cloud shape or ellipse
  • connected idea branches
  • extra sub-branches as needed

Sketches

Sketches are unrefined illustrations that briefly show an interface or how parts of a solution could link or interact. They can be drawn by hand or created with digital drawing tools.

Annotations

Annotations help organise thoughts, highlight or justify design considerations, and propose or establish links between design ideas.

Unit 3: Design tools

For detailed-design advice already on this site, see Detailed Designs.

Data dictionaries

Data dictionaries are used to design the data requirements of a software module, including variables, constants, objects and interface controls.

Minimum fields

  • Name
  • Data type

Possible extra fields

  • Description
  • Field size
  • Validation rules
  • Data sample

Sample data dictionary

Name Data type Description
strGivenName String User's given name
strFamilyName String User's family name
intAge Integer User's age, calculated from date of birth and rounded down

Mock-ups

A mock-up is a detailed diagram that shows how a software module's interface will look.

Annotations may describe:

  • appearance: font, text colour, text size, alignment / justification, images to source, control properties
  • structure: required controls, functionality, default values, control size, control properties
  • design principles and user-experience choices
  • justification for design decisions

Object descriptions

An object description is used to design an object that will be used in a software module.

It should include:

  • the object name
  • the required attributes / properties (data)
  • the required methods (behaviours)
  • data types for attributes when needed
  • parameters for methods when needed

Sample object description

  • Name: Dog
  • Properties / attributes: Name (string), Breed (string), Age (integer), Colour (string)
  • Methods: bark(), eat(food), wag_tail()

Input-process-output (IPO) charts

IPO charts summarise the inputs, the processing and the outputs of a task. They are usually shown in a table with columns for Input, Processes and Outputs. Use separate IPO charts when representing multiple tasks.

Sample IPO chart

Input Processes Output
User uploads file containing a series of numbers Calculate the sum and average of the numbers Display the sum and average of the numbers; output values to file

Pseudocode

Pseudocode represents algorithms using structured English and common symbols.

Conventions

  • blocks must start with BEGIN and end with END
  • reserved words are capitalised and shown in bold in presentation material
  • indentation is used to show hierarchy and nested control structures
  • values can be assigned using the left-arrow symbol (<-) or the SET keyword
  • input can be shown with READ or INPUT
  • output can be shown with PRINT, RETURN or OUTPUT
  • selection structures can use IF-THEN, IF-THEN-ELSE, IF-ELSEIF, CASE or SWITCH
  • repetition structures can use DO-WHILE, REPEAT-UNTIL, WHILE and FOR
  • conditions can be joined using AND and OR
  • lines may or may not be numbered

The source document includes a short REPEAT-UNTIL example. Rendered in a cleaner plain-text style, it looks like this:

BEGIN
SET a <- 7
SET b <- 1
REPEAT
    SET c <- a * b
    SET a <- a - 1
    SET b <- b + 1
UNTIL a < 4
PRINT c
END

Unit 3: Principles of OOP

Abstraction

Abstraction hides complex implementation details and exposes only the necessary and relevant parts of a class or object. It helps users focus on what an object does rather than how it does it.

The document's Dog example highlights:

  • relevant properties such as name, breed, age and colour
  • common behaviours such as bark(), eat() and wag_tail()

Encapsulation

Encapsulation bundles data and the methods that operate on that data into one class. It also restricts direct access to some components so the integrity of the data is protected.

The Dog example in the document uses:

  • private attributes such as strName, strBreed, intAge, strColour and boolTrained
  • public getters and setters such as getName() / setName(name)
  • methods stored with the data inside the same class

Generalisation

Generalisation extracts shared attributes and behaviours from two or more classes into a more general superclass. This promotes reuse and reduces redundancy.

The document's example turns Dog and Cat into subclasses of a Pet superclass:

  • shared attributes move into Pet
  • shared methods such as eat() and getter / setter methods move into Pet
  • class-specific behaviours remain in the subclasses, such as bark(), wag_tail(), purr() and catch_mouse()

Inheritance

Inheritance allows a subclass to inherit attributes and methods from a superclass, extend its functionality, and build a hierarchy between classes.

The document's example uses:

  • a Shape superclass
  • Circle and Rectangle subclasses
  • overridden behaviour such as drawing, perimeter and area calculations

Units 3 and 4: Key legislation and frameworks

Legislation

Industry frameworks to study in Unit 4

Unit 4: Established and innovative approaches to software development

Code repositories

Code repositories support version control, collaboration and transparency. They also let developers work on new or changed functionality without affecting the main codebase until changes are tested and reviewed.

Examples named in the document:

  • Git
  • GitHub
  • BitBucket
  • SourceForge

APIs and libraries

APIs and libraries are both important tools in software development.

APIs

  • allow different systems and solutions to interact and communicate
  • examples named in the document: REST, SOAP, operating system APIs, GraphQL, webhooks, serverless APIs, API gateways

Libraries

  • provide pre-written code that developers can reuse for specific tasks and functions
  • let developers focus on the unique parts of their own solution
  • can come from standard libraries or third-party open-source sources such as NumPy
  • examples named in the document: modularisation, micro-libraries, AI-generated libraries, community-driven libraries

Challenges with APIs and libraries

  • complexity
  • dependency on APIs or libraries
  • security risks from APIs and outdated libraries
  • versioning and compatibility

AI-based assistants

AI-based assistants are increasingly integrated into development environments. They use artificial intelligence, natural language processing and machine learning to observe developer actions and respond to prompts.

Benefits

  • increased productivity and efficiency
  • support for problem-solving and innovation
  • reduced development costs
  • code generation and suggestions
  • automated debugging and testing, including automatic generation of test data and test cases
  • automated generation, maintenance and improvement of internal documentation

Challenges

  • lack of accuracy and context awareness
  • over-reliance on AI assistants
  • cost of integration
  • accidental introduction of security vulnerabilities
  • copyright and intellectual property theft
  • bias in training data
  • environmental impact

Examples named in the document:

  • GitHub Copilot
  • Tabnine
  • Synk
  • TensorFlow
  • Codeium