1.3 Program Design and Development

What you need to know

• A development process can be ordered and structured or exploratory, but good ones share phases: investigating and reflecting, designing, prototyping, and testing.
• Iterative development means going through those phases repeatedly, improving with each cycle. Incremental development means building and testing one small piece at a time and adding to what already works.
• The investigating phase includes understanding the users: surveys, interviews, observation, and gathering requirements about what the program needs to do and for whom.
• The designing phase includes brainstorming, planning the user interface, and using tools such as flowcharts or pseudocode to lay out an algorithm before writing real code.
• Program documentation — comments inside the code plus external descriptions — explains what a program does and how, so it can be understood, maintained, and reused later by the author or others. Documentation should be written during development, not only at the end.
• Comments are the in-code form of documentation; the computer ignores them. Good comments explain why and what, not just restate the line.
• Abstraction underpins good design: managing complexity by focusing on what something does rather than how. Using a procedure or a list is a form of abstraction.
• Requirements can change during development — that's normal, and iteration is how developers accommodate it.

Worked example

Building a grade-calculator: (1) Investigate — ask three classmates what they want; they all want weighted categories. (2) Design — sketch the screen and write pseudocode for the weighted average. (3) Prototype — code just the average for one category and confirm it's right. (4) Test — try zero grades, a 100, a missing category. Then loop back: add the second category, test again. Each loop is an iteration; adding one category at a time is incremental. The comments you write during step 3 are documentation.

Going deeper

The nuance, edge cases, and connections that turn a 3 into a 5.

• The CED describes two development processes: iterative and incremental, and also notes that some processes are unstructured or exploratory — you try things and see what works. Exploratory development is legitimate, especially early; the exam won't call it wrong.
• The four phases — investigating and reflecting, designing, prototyping, testing — aren't strictly linear. Testing reveals design flaws, which sends you back to designing. That loop is what "iterative" means.
• Investigating includes understanding the users, not just the problem: who are they, what do they need, what constraints do they have? A program designed without investigating users tends to serve the developer's assumptions instead. This links to 5.3 (bias).
• Program specifications — a description of what the program must do — come out of the investigating phase. The exam may call them requirements. They can change during development, and accommodating change is part of the process, not a failure.
• Documentation serves future developers, collaborators, users, and your future self. The CED's specific claim: documentation is useful "during development" as well as after, because it helps you keep track of what you've done and why.
• Two kinds of abstraction appear in design: procedural (a named procedure stands in for its steps) and data (a list stands in for many values). Good design uses both to keep the program understandable.

Mistakes that cost points

• Treating iterative and incremental as synonyms. The exam tests them separately. Iterative = repeating the phases to refine. Incremental = building in small working pieces. A team that builds a rough full version, tests, and refines it is iterating. A team that builds feature 1, tests, then feature 2 is being incremental.
• Thinking documentation is written only at the end. Options saying "documentation is completed after the program is finished" are wrong per the CED. It's throughout.
• Believing comments affect the program. Comments are ignored by the computer. Any option claiming comments make code faster, slower, or fix errors is a distractor.
• Skipping investigation on the Create Task. Students jump to coding, then can't answer the written response about their program's purpose for a specific user. Decide who it's for first.

Practice questions

Written in the style of the real exam. Try each one before revealing the answer.