Home A - Z
Page Index

An Otter Wiki

Blame

5c1696 lisa 2026-08-29 16:39:27
Add sd/C10: hub + guides for the in-class model Seven curated learning pages plus the C10 home hub, generated by the shared port script (new c10 config): the C100-* cluster, the tick sheet, the solutions booklet and the assessment paperwork stay out of the wiki. Each page gains a skill title, a lead naming the rubric band it serves, one earned mermaid visual and a Check Your Understanding fold. The git-log examples are anonymised (prior-cohort names, hostnames and repo URL removed). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RxqgYbTNNYrPNuko6xfbKs
1 
<!-- Generated from applied-computing-au vic/unit3-4/sat/C10-2026 by port-reference-godot-to-wiki.py — do not hand-edit; re-run the port. -->
2
# Writing the Development Process Portfolio
3
4
*How to turn analysis, design and development into a case study C10-2 can be marked from. Read it before class write 2.*
5
6
> [!NOTE]
7
> **The bands this serves.** C10-2, 5–6: *evaluates the use of the analysis, design and development stages*. 7–8: *critically evaluates the process … from start to finish … and how this process assisted in meeting requirements*. 9–10: *discusses and justifies improvements that could be made … by approaching the stages differently*. Describing what you did stops at 3–4.
8
9
```mermaid
10
flowchart LR
11
A["Analysis<br/>what I discovered<br/>about the problem"] --> RA["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
12
RA --> B["Design<br/>how I planned<br/>the solution"]
13
B --> RB["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
14
RB --> C["Development<br/>how I built<br/>the solution"]
15
C --> RC["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
16
RC --> D["Evaluation<br/>how the three stages<br/>helped me meet<br/>the requirements"]
17
```
18
19
*The retrospectives are not decoration between the stages — they are the material the final evaluation is built from. Skip them and stage 4 has nothing to evaluate.*
20
21
## **What is this?**
22
23
Your **development story** - a case study showing how you navigated the PSM stages, made critical decisions, and learned from challenges.
24
25
**Purpose:** Tell the story of your journey through analysis → design → development, showcasing critical thinking and lessons learned.
26
27
---
28
29
## **📖 Write Your Development Story**
30
31
### **Think Case Study, Not Checklist**
32
33
Instead of: _"I completed analysis stage"_
34
Write: _"During Week 2 analysis, I discovered users actually needed X when I assumed they needed Y, so I updated my requirements and interviewed 3 more users..."_
35
36
---
37
38
## **🎯 Story Structure (C10-2)**
39
40
### **Stage 1: Analysis** - _"What I discovered about the problem"_
41
42
**Your Narrative:**
43
44
- **The investigation**: How did you research the problem?
45
- **Key discoveries**: What surprised you about user needs?
46
- **Decision moments**: When did you change direction and why?
47
- **Problem-solution pairs**: Challenge you hit → How you solved it
48
49
**Evidence to Include:**
50
51
- Research notes with captions: _"This interview revealed users needed offline mode"_
52
- Meeting minutes/user feedback
53
- Requirements evolution screenshots
54
55
**Mini-Retrospective:**
56
57
- **What went well?**
58
- **What was tricky?**
59
- **Action for next time:** _"Next project I'll prototype earlier"_
60
61
### **Stage 2: Design** - _"How I planned the solution"_
62
63
**Your Narrative:**
64
65
- **Design evolution**: Show how designs changed and improved
66
- **Choice explanations**: _"I chose React over vanilla JS because..."_
67
- **Alternative paths**: What other designs did you consider?
68
- **User feedback integration**: How did feedback shape your design?
69
70
**Evidence to Include:**
71
72
- "Before" and "After" mockups showing evolution
73
- Decision logs with reasoning
74
- Annotated wireframes: _"Changed button layout after usability feedback"_
75
76
**Mini-Retrospective:**
77
78
- **What went well?**
79
- **What was tricky?**
80
- **Action for next time:**
81
82
### **Stage 3: Development** - _"How I built the solution"_
83
84
**Your Narrative:**
85
86
- **Technical journey**: Key coding decisions and challenges
87
- **Problem-solving moments**: _"When I couldn't get the API to work, I..."_
88
- **Tool choices**: Why you picked specific technologies
89
- **Scope adjustments**: How you handled changing requirements
90
91
**Evidence to Include:**
92
93
- Git commit examples with context: _"This commit fixed the login bug discovered in testing"_
94
- Code snippets with explanations
95
- Bug fixes with problem-solving rationale
96
97
**Mini-Retrospective:**
98
99
- **What went well?**
100
- **What was tricky?**
101
- **Action for next time:**
102
103
### **Stage 4: Evaluation** - _"How PSM helped me succeed"_
104
105
**Your Analysis:**
106
107
- **PSM effectiveness**: How did each stage contribute to meeting requirements?
108
- **Critical thinking moments**: Key decisions that shaped the project
109
- **Process improvements**: What would you do differently?
110
- **Professional growth**: What did this process teach you?
111
112
---
113
114
## **📁 Portfolio Format Ideas**
115
116
### **Timeline-Based Story:**
117
118
Week-by-week narrative with artifacts and reflections at each stage
119
120
### **Visual Case Study:**
121
122
Annotated screenshots/mockups with decision explanations and lessons learned
123
124
### **Problem-Solution Journey:**
125
126
Organize around major challenges faced and how you solved them
127
128
### **Decision Tree Format:**
129
130
Show key decision points with reasoning and outcomes
131
132
---
133
134
## **📊 Evidence + Reflection Template**
135
136
|**PSM Stage**|**Key Evidence**|**What I Learned**|**Next Time I'd..**|
137
|---|---|---|---|
138
|Analysis|Research notes, user interviews|Users needed offline mode|Interview users earlier|
139
|Design|Wireframes, mockup evolution|Simple designs work better|Get feedback on every iteration|
140
|Development|Git commits, code solutions|Testing early saves time|Set up automated testing from start|
141
|**Overall**|**Complete journey reflection**|**PSM stages prevented major rework**|**Plan for more user feedback loops**|
142
143
---
144
145
## **✨ Pro-tips:**
146
147
**Tell YOUR story** - Include personality, choices, and real experiences
148
149
**Show evidence with context** - Each artifact needs a caption explaining why it matters
150
151
**Be honest about struggles** - Challenges overcome demonstrate critical thinking
152
153
**Connect to requirements** - Explain how your process helped meet FR/NFR
154
155
**Use visuals** - Screenshots, diagrams, timelines make it engaging
156
157
## **🎯 Remember:**
158
159
This isn't about having a perfect process - it's about **demonstrating thoughtful reflection** on your development journey and **showing what you learned** along the way!
160
161
---
162
163
## Check Your Understanding
164
165
**1.** Which of these two sentences can reach band 7–8, and why?
166
(a) *"I completed the design stage, producing mock-ups and a data dictionary."*
167
(b) *"Designing the data dictionary before coding meant the save-file format was settled early, so the two save bugs found in alpha testing were format bugs, not design bugs."*
168
169
>| ### Answer
170
>| (b). It evaluates *the use of* the stage — it says what the stage did for the project and ties it to a requirement being met. (a) outlines what was produced, which is band 3–4 territory.
171
172
**2.** Band 9–10 asks you to justify improvements *by approaching the stages differently*. Why is "I would have coded faster" not enough?
173
174
>| ### Answer
175
>| It is not a change to a stage. An answer that opens the band names a different way of running analysis, design or development — prototyping before finalising the SRS, say — and then justifies it against something that actually went wrong.
176
177
**3.** Every artefact you include needs a caption. What must the caption say?
178
179
>| ### Answer
180
>| Why the artefact matters — the decision it evidences — not what it is. *"Wireframe v2"* is a label; *"Changed the button layout after two testers missed the hold control"* is a caption.