Skip Ribbon Commands
Skip to main content
Sign In Skip to Content

Advice for teachers -
Applied Computing

​Unit 3: Software development

Area of Study 1: Software development: programming

Outcome 1

Interpret teacher-provided solution requirements and designs, and apply a range of functions and techniques using a programming language to develop and test working software modules.

Examples of learning activities

  • Identify and describe specific uses for a range of data types. For example:
    • Telephone numbers are best stored as strings because often characters such as parentheses or spaces are usually required to be stored and no numerical processing is required.
    • Sorting numeric values or numbers as text achieves a different outcome – 1, 3, 5, 15, 101 (numeric values) vs. 1, 101, 15, 3, 5 (numbers as text) – due to text sorting not taking into account place value.
    • Australian currency should be stored as floating point values to two decimal places, rather than integers, because currency uses dollars and cents.
  • Compare a variety of data structures, such as arrays and records, in relation to their structural characteristics (single data type, integer index compared to multiple data types and field index), and discuss how each may be applied in a range of scenarios. Demonstrate how these data structures may be implemented within the selected programming language.
  • Develop a presentation that explains the concept of key-value pairs and the use of hashing functions. Prepare a practical activity where students are applying provided hashing functions to an existing data set or are creating their own hashing functions.
  • Lead students in practising the development of writing problem statements and documenting problems that can be solved using a software solution. For example:
    • The PE department at the school is loaning out sports equipment to the students at lunchtime but not all students are returning the equipment. The Head of PE would like a software solution to be developed that can help keep track of the sports equipment being loaned out at lunchtimes.
  • Examine familiar software solutions (such as POS systems, ticketing systems, social media, video games or mobile applications) in order to identify solution requirements and constraints.
  • Using mini-case studies, identify solution requirements, constraints and how these considerations impact the scope of solutions. For example:
    • The Head of PE wants the borrowing solution to be an internet application that works in multiple browsers and able to be used on mobile phones.
      Functional requirements:
      -  to record who has borrowed equipment
      -  to record who has returned equipment
      -  to provide a report of students who have not returned equipment after two days
      Non-functional requirements:
      -  reliability
      -  usability
      -  portability
      Constraints:
      -  usability
      -  technical
      How these impact scope:
      -  solution may be released across several versions where compatibility with one browser is ensured first, before mobile access or additional browser compatibility is developed.
  • Discuss a range of teacher-provided requirements and software designs so that students can identify key features of the software design, the structure of each of the provided design tools, and the relationship between the designs. For example:     

    • Teacher provides students with a small set of requirements, a data dictionary and a block of pseudocode. From the provided requirements and designs, students unpack where the requirements are present in the designs. They could also identify structural characteristics of designs, such as indenting of pseudocode or column headings within a data dictionary. Students could also identify how the designs are linked to each other within the given scenario.
  • Using the interfaces of a familiar software solution, annotate key aspects of the solution’s interface, in relation to appearance and functionality, design features, and validation.
  • Compare the formatting and structural differences between plain-text (TXT), delimited (CSV) and XML files. Provide examples. Discuss situations where one particular format may be preferred over the others.
  • Using a range of exercises and resources, provide opportunities for students to practise developing solutions using their programming language. Incorporate a range of processing features, appropriate data types and data structures.
  • Provide students with two sets of code for the same algorithm or application: one using a consistently applied naming convention, and one that does not use a naming convention. Discuss the algorithm or application, with reference to ease of understanding.
  • Demonstrate the key features of the selected programming language’s associated development environment. Describe and give examples of the processing features of the programming language.
  • Example icon for advice for teachers
    Conduct a role-play with students to demonstrate the algorithmic behaviour of sorting, involving selection sort and quick sort and searching involving linear and binary searching.
  • Compare the differences between a selection sort and a quick sort in terms of complexity and efficiency. For example:     

    • Selection sort works by moving the smallest (or largest) value to its sorted position on each pass, compared to quick sort which uses a pivot and sorts the data into two sub-lists; this process repeats until values are in the correct position. The algorithm for quick sort is more complex and more efficient than selection sort.
  • Discuss and justify the use of a searching technique (linear or binary) based on solution requirements, the search algorithm and the structure of the data (sorted/unsorted).
  • Demonstrate the development of a simple software solution that incorporates the validation techniques of existence, range and type checking.
  • Provide students with a series of algorithms and ask them to trace the variables within each algorithm using a trace table. These algorithms may, or may not, contain errors.
  • Demonstrate how to construct appropriate and reasonable test data for different features of a programming language, and for the purpose of identifying issues with solutions. Use a table and include columns for the expected and actual output.
  • Document practice programming exercises through the application of appropriate internal documentation, explaining the purpose of the modules, key features of the modules and the justification of the use of the selected processing features.
Example icon for advice for teachers

Detailed example

Role-playing algorithms

The key knowledge requires that students know two sorting (selection and quick sort) and two searching (linear and binary search) algorithms. Providing verbal descriptions or showing a video/animation of these algorithms may help students to compare their algorithmic behaviour. However, many students may not fully grasp the concepts. Role-playing the algorithmic behaviours of these algorithms provides an approach to understanding these concepts and comparing the algorithms. The process for each is outlined below.

Linear and binary search

  1. Explain to students the algorithmic behaviour of both linear and binary search.
  2. On a piece of paper, ask students to write an appropriate random word. Teachers can choose whether the word is related to a particular context.
  3. Have students stand up in a random order showing the word on their piece of paper to the rest of the class. Act out the process of searching for the word using the linear search algorithm.
  4. Have students line up in alphabetical order of the words. Act out the process of searching for words using the binary search algorithm.
  5. Take a student’s place in line and ask them to perform the linear search algorithm again, searching for a different word. The rest of the class should be counting the number of comparisons being made.
  6. Take another student’s place in line and ask them to perform the binary search algorithm (searching for the same value as the previous student). The rest of the class should be counting the number of comparisons being made.
  7. Discuss what students observed as part of the process, in relation to differences in the algorithms and their efficiency.

Note: Teachers could extend this process to observe best and worst case scenarios for searching for items (for example, item being searched is first or last item in the list, or not in the list at all).

Selection and quick sort

  1. Explain the algorithmic behaviour of both selection and quick sort to students.
  2. On a piece of paper, ask students to write an appropriate random word. Teachers can choose whether the word is related to a particular context.
  3. Have students stand up in a random order showing the word on their piece of paper to the rest of the class. Remind them to take note of who is standing next to them on either side (important part of the reset). Act out the process of sorting words into alphabetical order using the selection sort algorithm. Have one student counting the number of passes, another counting the comparisons and the remaining students counting the number of swaps.
  4. Students should then reset back to their original order. Act out the process of sorting words into alphabetical order using the quick sort algorithm.
  5. Take a student’s place in line and ask them to perform the selection sort algorithm. Have one student counting the number of passes, another counting the comparisons and the remaining students counting the number of swaps. Swap places with the student (who performed the selection sort).
  6. Take another student’s place in line and ask them to perform the quick sort algorithm. Again, the class should be counting the number of passes, comparisons and swaps being made.
  7. Discuss what students observed as part of the process, in relation to differences in the algorithms and their efficiency.

Note: Teachers could extend this process to observe best and worst case scenarios for sorting lists (for example, list already in order or in total reverse).