Problem-Solving Methodology

Your SAT is structured around PSM — the four-stage framework VCAA uses to assess how you approach software development. Knowing the stage names and their activities isn't optional; they come up in the C1-2 writing test and the C1-3 interview.

flowchart LR
    A["**1. Analysis**<br/>─────────────<br/>Solution requirements<br/>Solution constraints<br/>Scope of solution"]
    B["**2. Design**<br/>─────────────<br/>Solution design<br/>Evaluation criteria"]
    C["**3. Development**<br/>─────────────<br/>Manipulation (coding)<br/>Validation<br/>Testing<br/>Documentation"]
    D["**4. Evaluation**<br/>─────────────<br/>Solution evaluation<br/>Evaluation strategy"]

    A --> B --> C --> D

The four stages

Analysis

You figure out what needs to be built — not how. This stage produces your Software Requirements Specification (SRS) and analytical diagrams (context diagram, DFD, use case diagram). Three activities:

Solution requirements — what the software must do
Solution constraints — limits on time, hardware, budget, or legal factors
Scope of solution — what is in and out of the project

Design

You work out how to build it — before you write a single line of code. Two activities:

Solution design — mock-ups, data dictionary, IPO charts, pseudocode, and other detailed design artefacts
Evaluation criteria — the measurable standards you'll use later to judge whether requirements were actually met (e.g., "90% of beta testers can complete onboarding in under 2 minutes")

Common mistake: evaluation criteria belong here, in Design — not in Evaluation. You set the goalposts now; you check the score later.

Development

You build, check, and record. Four activities:

Manipulation (coding) — writing the software from your designs
Validation — checking that input data is reasonable and accurate before processing
Testing — checking that the software works correctly (unit tests, alpha, beta)
Documentation — internal comments and any user-facing documentation

Common mistake: validation ≠ testing. Validation is about data; testing is about functionality.

Evaluation

You measure the solution against the criteria you set in Design. Two activities:

Solution evaluation — how well does the finished product meet the requirements?
Evaluation strategy — how did you collect evidence? (surveys, observation, usage data)

Common mistake: don't describe whether the app "works" here — that's testing. Evaluation asks whether it meets the needs of users and clients.

Why this matters at validation

The C1-2 writing test asks you to apply PSM concepts to your specific project — expect questions like "which PSM stage does task X belong to?" or "why must evaluation criteria be set before development begins?" Your project plan (set up in C012-Add-Tasks-and-Timeline.md) must have tasks mapped to each PSM stage with realistic dates. The marker checks that your task list reflects all four stages, not just Development.

At the C1-3 interview you bring your annotated project plan (see C013-Annotate-Project-Plan.md) and explain where you are in the PSM cycle, what's on your critical path, and how you've adapted the plan when things changed. Being able to name the stage, name the activity, and point to evidence in your GitHub Projects board is what separates a strong response from a vague one.