​Unit 3: Software development

Area of Study 2: Software development: analysis and design

Outcome 2

Analyse and document a need or opportunity, justify the use of an appropriate development model, formulate a project plan, generate alternative design ideas and represent the preferred solution design for creating a software solution.

Examples of learning activities

• Explain whether or not user authentication and data protection are important to consider during the design stage. Conduct a class discussion. Ask students to justify which security measure should be implemented and why.
• Discuss a range of data collection techniques. Justify how and when each technique would be used. Provide examples of a range of data that could be collected.
• Plan an activity where students prepare mini-case studies considering a range of opportunities or needs. Conduct a peer review session in the classroom where constructive feedback is provided by two classmates. Refine the mini-case study based on feedback.
• Analyse a mini-case study in order to identify functional and non-functional requirements and constraints. Discuss how these and other factors may impact the scope of the proposed solutions.
• Prepare a strategy to develop a software requirements specification, by analysing several software requirements specifications (SRS) examples. List and describe the key features required in the SRS.
• Identify the features of context, data flow and use case diagrams. Consider how entities differ from actors, data flows differ from interactions, and ‘includes’ differ from ‘extends’, in relation to their function within each of the relevant analytical tools.
• Prepare an activity where students examine parts of a data flow diagram and identify whether conventions have or have not been followed. In situations where conventions have not been followed, students must explain the issue with the part and provide an appropriate suggestion to correct the error. Prepare an activity where students examine parts of a data flow diagram and identify whether conventions have or have not been followed. In situations where conventions have not been followed, students must explain the issue with the part and provide an appropriate suggestion to correct the error.
• 
  Analyse a case study and construct or complete a context diagram, data flow diagram or use case diagram, applying relevant conventions as necessary.
  
• Provide software requirement specifications for students to examine. Students generate a range of design ideas for the proposed solutions using a range of software design tools, including data dictionaries, mock-ups, object descriptions and pseudocode.
• Provide students with examples of criteria that evaluate different aspects of the efficiency and effectiveness of designs, solutions, development models and project plans. These examples should also be provided in a number of forms (e.g. questions, statements, dot points).
• Prepare a presentation that explains each of the factors influencing the design of solutions. Discuss how existing solutions address (or do not address) these factors. Provide students with an opportunity to redesign solutions to address these factors and justify their modifications to their peers.
• Provide a range of needs or opportunities, requirements, constraints and scope statements for students to practise their use of design tools, such as mockups, pseudocode, object descriptions and data dictionaries to design solutions. Students then peer-evaluate their designs using teacher-provided or student-generated criteria to select or generate a preferred design.
• Analyse existing solution interfaces, identifying the key factors influencing the design of these solutions.
• Discuss positive or negative experiences with familiar existing solutions (such as POS systems, ticketing systems, social media, video games or mobile applications) and how these experiences contribute to user satisfaction, familiarity and the overall efficiency and effectiveness of the software solution.
• Prepare an activity where students research each of the development models, such as agile, spiral and waterfall. They focus on the key characteristics, links to the problem-solving methodology and advantages and disadvantages for use when developing a software solution.
  
• With a project in mind, students develop a Gantt chart using software that includes a range of project management features.
• Students explore the websites of healthcare, education, business and retail organisations in order to identify their goals. They propose a number of objectives that meet these identified goals.
• Explore how organisations meet (or do not meet) legislative requirements for ownership and privacy of data. This can be researched using anecdotes, media and online articles. For example:     
  
  
  • unpack privacy policies of social media organisations to understand who owns the data posted to social media
  • analyse how organisations protect user data to meet legislative requirements (two-factor authentication, encryption)
  • discuss how organisations that suffer data breaches have met legislative requirements.

Detailed example

Analytical tools

The VCE Applied Computing Study Design lists context, data flow and use case diagrams as the analytical tools that students must use when analysing existing processes and information systems. Each of these analytical tools contains distinct features (symbols and conventions) that students must understand the meaning of, and they must also know how to apply them within different scenarios. As part of the teaching of the use of these tools, students should be given time to analyse a number of case studies and produce analytical tools representative of the case study.

Teachers can prepare case studies around context-relevant scenarios that are accessible to students and provide students with opportunities to interpret, deconstruct and synthesise the information in front of them. Scenarios that teachers may consider using include:

• food or product ordering systems
• online services
• banking services
• school learning management systems/school intranets.

Teachers can provide students with incomplete representations of the information system described in the case studies, with students required to complete the diagram by drawing symbols or filling in the gaps. This approach also helps students to develop confidence in their abilities.

Once students have developed their abilities in working with the tools, they should be given opportunities to create entire diagrams from scratch. Teachers should provide students with a framework to develop context, data flow and use case diagrams. Below are examples of approaches that teachers may suggest to their students.

Context and data flow diagrams

1. Identify or highlight information within the case studies that describes entities and the system.
2. Construct a context diagram by drawing the system at the centre of the page, with the entities sitting outside of the system, linked by the incoming and outgoing data flows.
3. Identify or highlight information within the case studies that describes the processes within the system, the data flows and data stores.
4. On another page, draw the entities around the outer edge of the page.
5. Start the construction of the data flow diagram by drawing each of the processes (circles).
6. Draw the data stores in an appropriate part of the page.
7. Link the entities, processes and data stores using data flows as required, ensuring that outgoing data flows are different to the data flows entering a process and flow direction is depicted.

Use case diagrams

1. Identify or highlight information within the case studies that describe system roles and actions.
2. In a vertical manner, draw each of the system actions as use cases (ellipse).
3. Where actions are part of other actions, depict <<includes>> or <<extends>> relationships using the correct arrows (dashed and relevant direction). (The use of incorrect arrow directions is a common mistake made by students in examinations.)
4. Draw a box around the set of use cases to represent the system boundaries.
5. Around the box of use cases, draw each of the system roles as actors (stick figures).
6. Connect the use cases and relevant actors using solid lines. Where an actor initiates a use case, the interaction should have an arrow pointing to the use case.