Develop, test and evaluate a prototype that exchanges data between digital systems, applying iterative development, validation and a structured test plan against the solution requirements

What this dot point is asking

QCAA wants you to build and refine a working prototype that exchanges data between systems, then test and evaluate it against the requirements. This pulls together Unit 4: you take a data exchange format, transmit it, validate it, and prove it works with a structured test plan. A prototype is an early working version you improve iteratively, so the process and evidence matter as much as the final artefact.

Iterative development

You do not build the whole solution at once. You build a minimal working exchange, test it, then add capability in cycles. Each iteration:

1. implements one piece of functionality;
2. tests it against expected behaviour;
3. fixes defects and refines;
4. integrates it with what already works.

Working incrementally means defects surface early and in isolation, which is far cheaper to fix than debugging a large finished system. Keep a development log of each iteration as evidence for the assessment.

Building and parsing the exchange

A prototype exchange serialises data into a structured format, moves it, and reconstructs it. Even a local prototype can demonstrate the full round trip.

import json

# System A: serialise an object to JSON
record = {"sensor_id": 7, "temp_c": 24.6, "ok": True}
message = json.dumps(record)          # JSON text ready to transmit

# System B: parse and validate the received JSON
def receive(message):
    data = json.loads(message)        # parse text back into a dict
    if not isinstance(data.get("temp_c"), (int, float)):
        raise ValueError("temp_c must be numeric")
    if not (-50 <= data["temp_c"] <= 100):
        raise ValueError("temp_c out of range")
    return data

print(receive(message))               # validated record

The receiver validates type and range before trusting the data, which is the integrity safeguard from the data-exchange dot point applied in code.

Validation

Validation rejects data that would corrupt the system. Apply it at the boundary where data enters:

• Type check: the field is the expected data type.
• Range/limit check: numeric values fall within sensible bounds.
• Presence check: required fields are not missing or null.
• Format check: strings match the expected pattern (dates, emails, IDs).

A prototype that exchanges data without validating it is fragile and will fail the IA3 evaluation criterion.

Structured testing

Testing must be planned and documented, not ad hoc. Build a test plan as a table of cases, expected results and actual results.

Covering normal, boundary and erroneous cases is the standard QCAA expects, because it demonstrates the prototype handles the full range of real-world inputs.

Evaluating the prototype

Evaluation compares the prototype against the requirements and reaches a justified judgement. Address:

• Functionality: does it exchange the required data correctly?
• Reliability: does it handle errors and bad input gracefully?
• Security and privacy: is the exchange protected and the data handled lawfully?
• Fitness for purpose: does it meet the stated user and problem requirements?

Recommend specific refinements for the next iteration, tied to evidence from your testing.

How this appears in IA3

IA3 is a prototype digital solution for a complex data exchange. Markers reward a documented iterative process, a working exchange with validation, a structured test plan covering normal, boundary and erroneous data, and an evaluation that judges the prototype against the requirements and proposes justified refinements. Show the round trip, the validation step and the filled-in test table so the marker can see the prototype is both correct and reliable.