Software Development
Writing code is only part of building software. The work around the code decides whether a project succeeds: understanding what people actually need, designing before you build, testing on purpose rather than by luck, writing down how the thing works, and making it usable for real people. This section is about that craft.
These pages are deliberately not tied to one exam. The habits here (talk to your user, design first, test the awkward cases, write the guide you wish you had) apply to any software project, at school or at work. They also line up closely with what a good IB Computer Science Internal Assessment needs, so a callout on each page points to where it helps.
Note for IB CS learners: the Internal Assessment rewards exactly these skills. Each page below flags the IA criterion it supports (consultation, the design model, the test plan, documentation, the interface). Nothing here is a separate syllabus topic to memorise; it is process knowledge that makes the project you build genuinely better.
What This Section Covers
| # | Topic | What it covers | Where it helps most |
|---|---|---|---|
| 1 | Requirements Gathering | Talking to a client, turning wants into clear requirements, functional vs non-functional, success criteria, and deciding whether a project is worth building (feasibility / TELOS) | Understanding the problem (IA Criterion A) |
| 2 | Design Representations | Flowcharts, data flow diagrams, structure charts, data dictionaries, and UML: what each one shows and how to choose the right one | The design model (IA Criterion C) |
| 3 | Testing Strategy | Types of testing, choosing test data (normal, boundary, invalid), and writing a test plan that proves your solution works | The test plan (IA Criterion C) |
| 4 | Documentation and User Guides | READMEs, user guides, code comments that earn their keep, and citing your sources honestly | Documentation (IA guidelines) |
| 5 | UI/UX and Accessibility | Usability basics, designing for accessibility, and ergonomics, so software works for everyone who has to use it | The interface (IA Criterion C) |
The Shape of a Project
Most software follows the same broad journey, whatever process a team names it:
- Understand the problem and the people who have it (Requirements).
- Design a solution on paper before writing code (Design Representations, UI/UX).
- Build the solution (that is the rest of this site: the Programming Layer).
- Test it deliberately against what could go wrong (Testing Strategy).
- Document and evaluate so others can use it and you can judge whether it worked (Documentation).
These stages overlap and loop back on each other in practice. You will learn something while testing that sends you back to the design, and that is normal, not a failure. The point of naming the stages is not to march through them once, but to make sure none of them gets skipped.