VCE Applied Computing (Year 11) · Unit 2 — Software Development · 18m read

Software Development — Problem Solving and Design

Ever wondered why some apps crash constantly while others just work? It's because experienced developers spend time understanding what users actually need before they start coding. You'll learn how to break down messy, real-world problems into clear steps, sketch out your solution design, and test it thoroughly—the exact approach that companies like Apple and Google use to build reliable software.

Learning objective: Apply problem-solving and software design techniques to create software solutions.

By the end of this lesson you can:

• I can define a problem, identify requirements, and create a solution design.
• I can design algorithms using pseudocode and flowcharts.
• I can describe testing strategies for software solutions.

The PSM is a road map for building software. Analyse → design → develop → evaluate. Skipping a stage is like driving without directions.

Software development process

### The software development process

1. Problem definition:
- Identify the problem clearly — what does the user actually need?
- Gather requirements from stakeholders.
- Define scope: what will the software do AND what won't it do?
- Constraints: time, budget, platform, existing systems.

2. Requirements specification:
- Functional requirements: What the system must do (accept input, process data, produce output).
- Non-functional requirements: How it must perform (speed, security, accessibility, usability).

3. Solution design:
- Algorithm design (pseudocode or flowcharts).
- Data structure selection (arrays, lists, dictionaries, databases).
- User interface design (wireframes, mockups).
- Test plan.

4. Development:
- Write code following the design.
- Use version control (Git commits).

5. Testing:
- Unit testing (individual functions).
- Integration testing (components together).
- User acceptance testing (does it meet user needs?).

6. Evaluation:
- Does the solution meet the requirements?
- What could be improved?

### Algorithm design tools

Pseudocode: Human-readable description of algorithm logic.

FUNCTION calculate_average(scores):
total = 0
FOR EACH score IN scores:
total = total + score
RETURN total / LENGTH(scores)

Flowcharts:
- Oval = Start/End
- Rectangle = Process
- Diamond = Decision (Yes/No)
- Parallelogram = Input/Output
- Arrows = Flow

### Testing approaches

Trace table: Walk through an algorithm step by step with test values.

Test cases:

| Test case | Input | Expected output | Actual output | Pass/Fail |
|-----------|-------|----------------|---------------|-----------|
| Normal | scores = [75, 80, 90] | 81.67 | 81.67 | Pass |
| Empty | scores = [] | Error message | ? | ? |
| Single | scores = [100] | 100 | 100 | Pass |

Testing strategies:
- *Black-box testing:* Test only inputs and outputs; don't look inside the code.
- *White-box testing:* Test internal logic — ensure every path through the code is tested.
- *Boundary testing:* Test at the edges of valid input ranges.

AARI TIP: Ask Aari to help you design test cases for any algorithm you're working on.

Key ideas at a glance

• Analysis: Requirements and constraints.
• Design: Pseudocode, mock-ups.
• Development: Code and test.
• Evaluation: Against criteria.

Worked example (Medium)

Design an algorithm in pseudocode that: accepts a list of temperatures, finds the highest temperature, and returns both the temperature and the day it occurred.

1. Understand the problem. Input: list of temperatures (one per day). Output: highest temperature AND the day number it occurred. Edge case: empty list.
2. Algorithm design. FUNCTION find_hottest(temperatures): IF LENGTH(temperatures) = 0 THEN RETURN "No data" ENDIF max_temp = temperatures[0] max_day = 1 FOR i = 1 TO LENGTH(temperatures) - 1: IF temperatures[i] > max_temp THEN max_temp = temperatures[i] max_day = i + 1 ENDIF ENDFOR RETURN max_temp, max_day
3. Trace with test data. Input: [22, 28, 35, 31, 27]. Expected: max=35, day=3.

Answer: Algorithm iterates through all temperatures, tracking the highest seen so far and its position. Handles empty list edge case.

Worked example (Medium)

Apply the Software Development Lifecycle (SDLC) to a class problem: build an attendance recorder.

1. Analysis. Identify needs: teachers, end-of-class, mobile-friendly.
2. Design. Wireframe the UI; choose data store (CSV vs database).
3. Development. Code the prototype, test with sample data.
4. Evaluation. User-test with teachers; check usability heuristics.

Answer: SDLC works at any scale — even a small class project benefits from the cycle of analysis → design → development → evaluation.

Common mistakes

• Writing code instead of pseudocode in design questions Students default to Python or JavaScript syntax when the question asks for pseudocode. Fix: Pseudocode should be readable by anyone regardless of programming language. Use plain English keywords (IF, THEN, WHILE, FOR EACH, RETURN) with clear indentation.
• Forgetting edge cases in algorithm design Students test only with "normal" inputs and overlook empty inputs, single elements, or boundary values. Fix: Always consider: empty input, single element, maximum/minimum values, and invalid input. Include handling for these cases in your pseudocode and test plan.
• Confusing functional and non-functional requirements Students mix up what the system does (functional) with how it performs (non-functional). Fix: Functional: "The system must calculate the average" (what it does). Non-functional: "The system must respond within 2 seconds" (how it performs — speed, security, usability, accessibility).

Why design before coding matters — the cost of change curve

One of the most important insights in software engineering is the cost of change curve: fixing a problem becomes exponentially more expensive the later it is discovered.

Research from IBM and the National Institute of Standards and Technology (NIST) consistently shows:
- A requirements error caught during design costs 1× to fix
- The same error caught during development costs 10×
- Caught during testing: 15×
- Caught after deployment: 100× or more

This is why the software development process emphasises design before coding. Time spent understanding the problem, specifying requirements, designing algorithms, and planning tests is not wasted — it directly reduces total project cost and improves quality.

Pseudocode is a design tool precisely because it separates logical thinking from syntax concerns. When writing pseudocode, you focus on: What are the inputs? What transformations must occur? What are the outputs? What can go wrong? This logical clarity transfers directly to cleaner, more correct code.

Test plans created during design (before coding begins) are more effective than tests written afterward, because they are designed from the requirements — testing what the system SHOULD do — rather than from the code — testing what it actually does (which may be wrong).

For Unit 2 Applied Computing, demonstrating a clear design process — from problem definition through pseudocode to test plan — before writing any code is essential for your School-based Assessment and aligns directly with VCAA expectations.

Practice questions

1. "Boundary testing" in software means:

   1. Testing only the normal expected inputs
   2. Testing at the edges of valid input ranges (minimum, maximum, just outside)
   3. Testing the user interface borders
   4. Testing only one path through the code

   (1 marks)

2. Explain why testing is an essential part of the software development process.

   (3 marks)

Summary

• Software development: problem definition → requirements → design → develop → test → evaluate.
• Functional requirements: what it does. Non-functional: how it performs.
• Algorithm design tools: pseudocode (human-readable) and flowcharts (visual).
• Test cases: normal inputs, edge cases (empty, single, maximum), boundary values.
• Testing strategies: black-box (I/O only), white-box (internal logic), boundary testing.