## Criterion 5: Producing Detailed Designs Guide This guide provides an in-depth explanation of **Criterion 5 (Skills in producing detailed designs)** for the School-assessed Task (SAT) in **VCE Software Development Unit 3 Outcome 2**. It incorporates specifications and requirements from the following official VCAA documents: * **VCE Software Development Administrative Information for School-based Assessment (2026)** (rubric & assessment indicators) * **VCE Applied Computing Study Design (From 2025)** (course structure, concepts & skills) * **VCE Applied Computing: Unit 3 and 4 Software Development: Software tools and functions and outcome-specific requirements** (design tool conventions & samples) --- ## 1. Criterion 5 Overview * **Assessment Task:** School-assessed Task (SAT) Unit 3 Outcome 2. * **Focus:** Students generate design ideas using ideation tools, establish evaluation criteria, select a preferred design, and then fully develop it into **detailed designs** addressing the appearance, structure, and functionality of the software solution. * **Score Allocation:** Ranked from **0 to 10 marks** across five performance levels (Very Low, Low, Medium, High, Very High). * **Problem-Solving Methodology Stage:** **Design** (specifically producing detailed designs and documenting critical/creative thinking). --- ## 2. Assessment Rubric Breakdown (Observation 5) To achieve a high score, students must understand the three distinct indicators evaluated in Criterion 5. The table below outlines what is required at each level of achievement. | Performance Level | Marks | Indicator 1: Detailed Design Tools | Indicator 2: UX & Design Principles | Indicator 3: Critical & Creative Thinking | | :---------------- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------ | | **Very High** | **9–10** | Uses **object descriptions** and **pseudocode** to represent the functions and methods used within objects and classes. Designs are **feasible and complete**. | Uses annotations and written explanations to **demonstrate and justify** how selected design principles and characteristics of user experience (UX) have been applied. | Documents **possible contingencies** when developing solution designs, and documents **possible solutions to mitigate issues**. | | **High** | **7–8** | Uses a detailed **data dictionary** (referencing data types, data structures, and data sources). Uses **IPO charts** and **multiple modules of pseudocode** to represent functionality. Applies design tools correctly. | Uses annotations and written descriptions to **document** how relevant **characteristics of user experience (UX)** have been applied. | Documents the **connections** between design ideas, solution requirements, and the detailed designs. | | **Medium** | **5–6** | Uses a detailed **data dictionary** (referencing data types and data structures). Uses an **IPO chart** and **pseudocode** to represent functionality. Applies relevant features of design tools. | Uses annotations or written descriptions to **describe** how **design principles** have been applied, with reference to appearance and functionality. | Documents the **connections** between the design ideas and solution requirements. | | **Low** | **3–4** | Uses **annotated mock-ups** to represent user interfaces. Uses a **data dictionary** with reference to data types. | Uses **brief annotations** to **identify** how design principles have been applied. | Outlines the **connections** between design ideas using annotations. | | **Very Low** | **1–2** | Uses a **mock-up** to represent the user interface. | **Lists** design principles and characteristics of user experience that have been considered. | **Identifies** existing and possible solutions to inform design ideas. | | **Not Shown** | **0** | Insufficient evidence. | Insufficient evidence. | Insufficient evidence. | --- ## 3. Required Detailed Design Tools (VCAA Specifications) Under the VCAA Software Tools and Functions document, there are specific templates, conventions, and examples that students must use for each design tool. ### A. Data Dictionaries Data dictionaries design the data requirements of a software module, including variables, constants, objects, and interface controls. * **VCAA Requirement:** Must be represented as a table. * **Minimum Fields:** `Name` and `Data type`. * **High/Very High Fields (Recommended):** `Description`, `Field size`/`Length`, `Validation rules`, and `Data sample`. #### VCAA Format & Example: | Name | Data Type | Description | | :--- | :--- | :--- | | `strGivenName` | String | User's given name | | `strFamilyName` | String | User's family name | | `intAge` | Integer | User's age (calculated based on the provided date of birth and rounded down) | > [!TIP] > Use standard prefix conventions for variable names (e.g., `str` for String, `int` for Integer, `bool` for Boolean, `obj` for Object, `btn` for button control, `txt` for text box control) to show high-level technical skills. --- ### B. Interface Mock-ups A mock-up is a detailed layout diagram illustrating how the user interfaces within the software solution will look. * **VCAA Requirement:** Must represent all key interfaces. * **Annotations Required:** Must cover: 1. **Appearance:** Fonts (family, style, size), text/background colors, element sizes, alignment, images to be sourced, and control properties. 2. **Structure & Functionality:** Required controls (text boxes, buttons, drop-downs), default values, sizes, and what happens when they are interacted with. 3. **Justifications:** Annotations must justify design choices by linking them to **design principles** and **UX characteristics**. --- ### C. Object Descriptions An object description defines the blueprint (class/object) to be used within the object-oriented software solution. * **VCAA Requirement:** Must include the class name, required properties/attributes (with data types), and methods (behaviours) including parameters where necessary. #### VCAA Example: * **Name:** `Dog` * **Properties/Attributes:** * `strName` (String) * `strBreed` (String) * `intAge` (Integer) * `strColour` (String) * **Methods:** * `bark()` * `eat(food)` * `wag_tail()` --- ### D. Input-Process-Output (IPO) Charts IPO charts provide an overview of the inputs and outputs of a system task, detailing the process (transformation steps) required to convert the inputs to the outputs. * **VCAA Requirement:** Represented as a table with columns for **Input**, **Processes**, and **Outputs**. Separate IPO charts must be used for separate tasks. #### VCAA Example: | Input | Processes | Output | | :--- | :--- | :--- | | User uploads file containing a series of numbers | Calculate sum and average of the numbers | Display sum and average of numbers. Output values to file. | --- ### E. Pseudocode Pseudocode is a structured English representation of algorithms using logical control structures and reserved keywords. #### VCAA Pseudocode Conventions: 1. **Enclosure:** Blocks must start with `BEGIN` and end with `END`. 2. **Reserved Words:** Keywords must be **capitalised** and in **bold** (e.g., **`BEGIN`**, **`END`**, **`IF`**, **`THEN`**, **`ELSE`**, **`WHILE`**, **`FOR`**, **`REPEAT`**, **`UNTIL`**). 3. **Indentation:** Must be used to show control structure nesting and hierarchy. 4. **Assignment:** Assign values using a left arrow ($\leftarrow$) or the **`SET`** keyword. 5. **Input/Output:** Use **`READ`** or **`INPUT`** for input; use **`PRINT`**, **`RETURN`**, or **`OUTPUT`** for output. 6. **Control Structures:** * *Selection:* **`IF-THEN`**, **`IF-THEN-ELSE`**, **`IF-ELSEIF`**, **`CASE/SWITCH`**. * *Iteration/Repetition:* **`DO-WHILE`**, **`REPEAT-UNTIL`**, **`WHILE`**, **`FOR`**. * *Logic Operators:* Use **`AND`** and **`OR`** to join conditions. #### VCAA Example: ```pascal BEGIN a <- 7 b <- 1 REPEAT c <- a * b a <- a - 1 b <- b + 1 UNTIL a < 4 PRINT c END ``` --- ## 4. Design Principles and User Experience (UX) To get marks in the high-to-very-high band, students cannot just list these concepts; they must annotate their designs to explain **how** and **why** they were applied. ### A. Design Principles (Visual & Functional) These principles influence the user interface's appearance and operational design: * **Alignment:** Arranging text and graphics so they line up on a grid. This establishes a clean visual pathway and organization. * **Balance:** The distribution of visual weight (size, color, space) across the UI. This can be symmetrical (formal/structured) or asymmetrical (dynamic). * **Contrast:** Emphasizing differences between elements (e.g., dark text on a light background, or a primary colored button for the main action) to improve readability and draw focus. * **Space:** Utilizing "white space" or negative space around elements to prevent clutter, separate distinct sections, and make the interface breathable. * **Text Formatting:** Choosing clear fonts, appropriate sizes, and styling (such as bold headers) to establish a clear typographic hierarchy. * **Usability:** Structuring the interface so it is easy to learn, efficient to use, and prevents user error. * **Navigation:** Providing intuitive paths (menus, breadcrumbs, back buttons) for the user to traverse the system easily. --- ### B. Characteristics of User Experience (UX) These characteristics define how a user feels and interacts with the software: * **Affordance:** Visual clues that indicate an element's function (e.g., a button with a shadow and rounded border "affords" clicking; a text box with a flashing cursor "affords" typing). * **Interoperability:** Designing interfaces or logic to support exchange and communication with external data sources or systems (e.g., importing CSV/XML data). * **Security (Authentication & Data Protection):** How the UI and system protect user data (e.g., password masking, clear error prompts for invalid logins, HTTPS indicators). * **Usability:** The overall speed, accessibility (screen readers, color blindness considerations), and recovery from errors within the solution. --- ## 5. Critical and Creative Thinking Requirements Criterion 5 places significant weight on documenting the **design process** and **contingency planning**. Students should include: 1. **Traceability (Connections):** Clear documentation (using tables, matrices, or annotated lines) showing how their chosen detailed designs directly address the **solution requirements** outlined in the **Software Requirements Specification (SRS)**. 2. **Contingency Planning:** Identify potential issues or roadblocks that could occur during the upcoming development stage (Unit 4 Area of Study 1) and document mitigation strategies. > [!NOTE] > *Example Contingency:* "If the selected external API is deprecated or offline during development, a mock local CSV data file structured in the same format will be used to simulate and test data queries." --- ## 6. Student Checklist for a Very High Score (9–10 Marks) Students can use this checklist to verify their detailed designs meet all requirements for the top mark band: - [ ] **Interface Designs (Mock-ups):** - [ ] Every screen and popup window is designed. - [ ] Annotations detail font sizes, families, alignments, and Hex/RGB colors. - [ ] Visual elements are annotated with design principles (e.g., "Contrast is used here with white text on a navy button to highlight the 'Submit' action"). - [ ] Controls are annotated with UX characteristics (e.g., "This input field uses a placeholder text 'e.g., John' to provide affordance for what data to enter"). - [ ] **Data Dictionary:** - [ ] Includes all variables, constants, objects, and GUI controls. - [ ] Specifies descriptive names, data types, descriptions, field sizes, validation rules, and sample values. - [ ] Specifies data structures (e.g., lists, arrays, records) and links them to external data sources (CSV, TXT, XML). - [ ] **Functional Logic (IPO Charts & Pseudocode):** - [ ] Every major function, module, and algorithm has a corresponding IPO Chart. - [ ] Pseudocode represents all classes and helper functions. - [ ] Pseudocode strictly follows VCAA conventions (bold capitalized keywords, `BEGIN`/`END` blocks, left arrow for assignment, indented control blocks). - [ ] **Object-Oriented Design:** - [ ] Includes complete Object Descriptions for all classes. - [ ] Clear listings of private attributes (with types) and public methods (with arguments/parameters). - [ ] Visual model or text showing relationships like Inheritance (e.g., `Dog extends Pet`). - [ ] **Process and Contingencies:** - [ ] Clear documentation linking the detailed designs back to the SRS requirements. - [ ] A dedicated "Contingency Table" listing at least 3-4 potential technical issues (e.g., database connection failure, GUI layout rendering errors, sorting performance bottlenecks) and their corresponding mitigation solutions.