# 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.

---

```mermaid
flowchart LR
    A["**1. Analysis**\n─────────────\nSolution requirements\nSolution constraints\nScope of solution"]
    B["**2. Design**\n─────────────\nSolution design\nEvaluation criteria"]
    C["**3. Development**\n─────────────\nManipulation (coding)\nValidation\nTesting\nDocumentation"]
    D["**4. Evaluation**\n─────────────\nSolution evaluation\nEvaluation 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.

---

## See also

- [Testing vs Validation vs Evaluation](/sd/C01/Testing%20vs%20Validation%20vs%20Evaluation) — disambiguation of three similar-sounding terms within PSM
- [Critical Path](/sd/C01/Critical%20Path)

---

← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9