Short on time? This page is the recap. For explanations and worked examples, use the full study guide.
Recap
- A development process can be ordered and intentional or exploratory.
- Common phases: investigating and reflecting, designing, prototyping, testing.
- Iterative: refine and revise based on feedback, testing or reflection; may revisit earlier phases.
- Incremental: break the problem into smaller pieces and make sure each piece works before adding it.
- Investigation methods: surveys, user testing, interviews, direct observation. They reveal constraints and users’ concerns.
- Requirements describe how the program must function; the specification defines them; the design outlines how to meet them.
- Design may include brainstorming, planning and storyboarding, modules, interface diagrams and a testing strategy.
- Documentation describes what code does and how it was developed; comments are documentation inside the program and do not affect how it runs.
- Acknowledge code from other sources, including the origin or author’s name.
Key relationships
| Idea | How to recognise it |
|---|---|
| Iterative | “Revised after feedback”, “went back to the design” |
| Incremental | “One feature at a time”, “made sure it worked before adding the next” |
| Requirement | “The program must…” |
| Specification | The set of requirements, in writing |
| Design | “How will the program meet the requirements?” |
| Documentation | Comments, written descriptions of code and development |
| Acknowledgement | Names the origin or author of borrowed code |
Assumptions and conventions
- A project may be both iterative and incremental. Judge each statement separately.
- Comments are shown here between
/*and*/, Marlbridge’s convention; follow the official reference sheet in the exam. - For acknowledgement questions, always include who or where the code came from.
Mistakes to avoid
- Saying “iterative” when the scenario describes adding verified pieces (incremental).
- Treating the phases as a one-way sequence.
- Writing comments that merely repeat the code instead of explaining purpose.
- Believing comments change program behavior.
- Forgetting to acknowledge a borrowed code segment.
- Describing requirements and design as the same thing.
Two quick worked examples
1. A team interviews shoppers, sketches the screens, builds one screen, tests it, then redesigns it. Interviews are investigating; sketches are designing; the built screen is prototyping; showing it to users is testing; redesigning is a return to design, so the process is iterative.
2. A comment above a loop says “Counts quiz answers that are correct; the idea for skipping blank answers came from Jo Lin.” It documents the purpose and acknowledges the source by name. If a question asks whether it changes how the program runs, the answer is no.
Quick self-check
- A team builds the login page, checks it fully works, then starts the profile page. Iterative or incremental? (Incremental.)
- After a user test the team redraws the menu layout. Which phase do they return to? (Design; this is iterative.)
- Name two ways to investigate user needs. (For example, interviews and direct observation; also surveys and user testing.)
Next: practice questions.