VCE Applied Computing: Data Analytics

The four stages

The problem-solving methodology is the method VCE Applied Computing uses for building any digital solution, and in Data Analytics the solution is a set of data visualisations that answers a question with data. It has four stages, and each stage has its own activities.

The stages can be run once, one after the other, or repeated in small cycles as in agile development, where a piece of the solution is analysed, designed, built and evaluated before the next piece is started. In either case the stages feed each other: the requirements found in analysis decide the designs, the designs decide what is built and the criteria written during design are the ones used in evaluation.

Skills that sit under each stage

Analysis depends on collecting data to find out what users need, on collecting both primary and secondary data, and on judging the reliability, validity and relevance of the sources used. It also depends on drafting good questions for surveys and interviews, and on preparing follow-up questions to clarify what was said.

Design depends on investigating existing solutions, generating several design ideas and linking them with text and diagrams, then producing a detailed design with annotations that describe the appearance and functionality of the solution. It includes planning contingencies, which are actions to take if something goes wrong, and writing evaluation criteria.

Development depends on choosing suitable software functions and techniques, applying formats and conventions to improve appearance, calculating descriptive statistics and identifying trends, patterns and relationships. It also includes validating and verifying data, developing a testing strategy, recording actual results against expected results and correcting errors. As the solution grows, the designs and the evaluation criteria are modified and refined.

Evaluation depends on proposing a strategy for evaluating the finished solution and then using the criteria to judge how well it met its requirements, in terms of efficiency and effectiveness. It also involves a critical look back at the analysis and design processes and at what could be done differently next time.

Solution requirements

A solution requirement states something the solution must have or do. Requirements are split into two kinds.

Functional requirements describe what the solution should do. For a data visualisation they cover the input it needs, the output it produces and the functions it performs, including how data is manipulated and validated. A requirement such as "the dashboard displays total monthly sales by region" is functional, as is "dates entered into the source spreadsheet are checked to be valid dates".

Non-functional requirements describe the quality attributes of the solution, meaning how well it does what it does. There are five.

Not every attribute fits every solution. A static infographic that is printed has no need for robustness against live data failures, for example, so the requirements that are written should be the ones that actually apply to the product and its users.

Requirements are often collected together in a software requirements specification, which brings together what the solution must do, its limits, who will use it (their skills and needs) and the technical environment it will run in, meaning the hardware and software.

Solution constraints

A constraint is a condition or limitation that has to be considered when designing the solution. Requirements say what is wanted; constraints say what limits how it can be delivered. They fall into five kinds.

A single limitation can sometimes be described in more than one way, so the useful skill is to name the constraint, say which kind it is and say what it forces the designer to do differently.

Solution scope

The scope describes the boundaries of the solution by stating what will be addressed and what will not. It stops a project from growing without limit. For a data project on local bike use, the scope might be "commuter trips in one city during 2024, shown as a dashboard of five charts" with "trips by recreational riders, other years and other cities" listed as outside it. Scope is tied to constraints, because a shortage of time or data is often the reason something is left out, and it is tied to the research question, because the question says what the data has to be able to answer.

Computational thinking

Interpreting requirements and designs, and building them into visualisations, draws on computational thinking: breaking a problem into smaller parts, looking for patterns in data, concentrating on the information that matters and discarding what does not, and describing the solution as a series of steps that can be followed in order. A requirement such as "show which suburbs have the highest recycling rates" is broken into finding the data, calculating a rate per suburb, sorting the results and choosing a chart that makes the ranking obvious.