<!-- 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. --> # Writing the Development Process Portfolio *How to turn analysis, design and development into a case study C10-2 can be marked from. Read it before class write 2.* > [!NOTE] > **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. ```mermaid flowchart LR A["Analysis<br/>what I discovered<br/>about the problem"] --> RA["retro<br/>went well ·<br/>was tricky ·<br/>next time"] RA --> B["Design<br/>how I planned<br/>the solution"] B --> RB["retro<br/>went well ·<br/>was tricky ·<br/>next time"] RB --> C["Development<br/>how I built<br/>the solution"] C --> RC["retro<br/>went well ·<br/>was tricky ·<br/>next time"] RC --> D["Evaluation<br/>how the three stages<br/>helped me meet<br/>the requirements"] ``` *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.* ## **What is this?** Your **development story** - a case study showing how you navigated the PSM stages, made critical decisions, and learned from challenges. **Purpose:** Tell the story of your journey through analysis → design → development, showcasing critical thinking and lessons learned. --- ## **📖 Write Your Development Story** ### **Think Case Study, Not Checklist** Instead of: _"I completed analysis stage"_ 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..."_ --- ## **🎯 Story Structure (C10-2)** ### **Stage 1: Analysis** - _"What I discovered about the problem"_ **Your Narrative:** - **The investigation**: How did you research the problem? - **Key discoveries**: What surprised you about user needs? - **Decision moments**: When did you change direction and why? - **Problem-solution pairs**: Challenge you hit → How you solved it **Evidence to Include:** - Research notes with captions: _"This interview revealed users needed offline mode"_ - Meeting minutes/user feedback - Requirements evolution screenshots **Mini-Retrospective:** - **What went well?** - **What was tricky?** - **Action for next time:** _"Next project I'll prototype earlier"_ ### **Stage 2: Design** - _"How I planned the solution"_ **Your Narrative:** - **Design evolution**: Show how designs changed and improved - **Choice explanations**: _"I chose React over vanilla JS because..."_ - **Alternative paths**: What other designs did you consider? - **User feedback integration**: How did feedback shape your design? **Evidence to Include:** - "Before" and "After" mockups showing evolution - Decision logs with reasoning - Annotated wireframes: _"Changed button layout after usability feedback"_ **Mini-Retrospective:** - **What went well?** - **What was tricky?** - **Action for next time:** ### **Stage 3: Development** - _"How I built the solution"_ **Your Narrative:** - **Technical journey**: Key coding decisions and challenges - **Problem-solving moments**: _"When I couldn't get the API to work, I..."_ - **Tool choices**: Why you picked specific technologies - **Scope adjustments**: How you handled changing requirements **Evidence to Include:** - Git commit examples with context: _"This commit fixed the login bug discovered in testing"_ - Code snippets with explanations - Bug fixes with problem-solving rationale **Mini-Retrospective:** - **What went well?** - **What was tricky?** - **Action for next time:** ### **Stage 4: Evaluation** - _"How PSM helped me succeed"_ **Your Analysis:** - **PSM effectiveness**: How did each stage contribute to meeting requirements? - **Critical thinking moments**: Key decisions that shaped the project - **Process improvements**: What would you do differently? - **Professional growth**: What did this process teach you? --- ## **📁 Portfolio Format Ideas** ### **Timeline-Based Story:** Week-by-week narrative with artifacts and reflections at each stage ### **Visual Case Study:** Annotated screenshots/mockups with decision explanations and lessons learned ### **Problem-Solution Journey:** Organize around major challenges faced and how you solved them ### **Decision Tree Format:** Show key decision points with reasoning and outcomes --- ## **📊 Evidence + Reflection Template** |**PSM Stage**|**Key Evidence**|**What I Learned**|**Next Time I'd..**| |---|---|---|---| |Analysis|Research notes, user interviews|Users needed offline mode|Interview users earlier| |Design|Wireframes, mockup evolution|Simple designs work better|Get feedback on every iteration| |Development|Git commits, code solutions|Testing early saves time|Set up automated testing from start| |**Overall**|**Complete journey reflection**|**PSM stages prevented major rework**|**Plan for more user feedback loops**| --- ## **✨ Pro-tips:** **Tell YOUR story** - Include personality, choices, and real experiences **Show evidence with context** - Each artifact needs a caption explaining why it matters **Be honest about struggles** - Challenges overcome demonstrate critical thinking **Connect to requirements** - Explain how your process helped meet FR/NFR **Use visuals** - Screenshots, diagrams, timelines make it engaging ## **🎯 Remember:** 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! --- ## Check Your Understanding **1.** Which of these two sentences can reach band 7–8, and why? (a) *"I completed the design stage, producing mock-ups and a data dictionary."* (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."* >| ### Answer >| (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. **2.** Band 9–10 asks you to justify improvements *by approaching the stages differently*. Why is "I would have coded faster" not enough? >| ### Answer >| 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. **3.** Every artefact you include needs a caption. What must the caption say? >| ### Answer >| 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.