The Iterative Design Process

The College Board defines the development of computing innovations as an iterative process — one that incorporates implementation and feedback cycles, leaves room for experimentation, and is focused on the needs of the user. This is not a shortcut; it's the professional standard.

An iterative process looks something like this:

1. Investigate — understand the problem, the users, and the constraints
2. Design — plan a solution (brainstorm, storyboard, outline modules)
3. Implement — build a version of the solution
4. Test — run the program and evaluate whether it meets requirements
5. Refine — use test results and feedback to improve
6. Repeat — cycle back to any earlier stage based on what you learn

The key insight is that steps don't happen in strict order and each cycle produces a better product. A developer might finish implementing step 3, discover through testing that the original design was wrong, and loop back to redesign before implementing again.

Investigating User Needs

Before writing any code, effective developers investigate the people who will use their program. The CED identifies several investigation methods:

• Surveys — collecting data from many potential users at scale
• User testing — having real users try a prototype and observing what happens
• Interviews — in-depth conversations with potential users
• Direct observations — watching how people currently solve the problem the program will address

This investigation drives program requirements — a description of how a program should function and what user interactions it must provide. A specification is a formal document that defines these requirements. The design phase then outlines how to achieve that specification.

Design deliverables might include: brainstorming notes, wireframes or storyboards of the user interface, module diagrams showing how the program is organized, and a testing strategy.

Documentation and Comments

As programs are built, they accumulate complexity. Program documentation is how developers communicate the purpose and function of that complexity to future readers — including their future selves.

Documentation is a written description of what a code segment, event, procedure, or program does and how it was developed. Good documentation:

• Is written throughout development, not just at the end
• Helps new collaborators understand existing code quickly
• Makes maintenance and debugging faster
• Is required even when working alone

Comments are one specific form of documentation — text written directly into code that describes what the code does. The most important fact about comments for the AP exam:

Note that not all programming environments support comments, so other documentation methods may be required in some contexts.

Attribution: Crediting Code from Other Sources

Using code written by others is common and acceptable — but it must be acknowledged. When a program includes code written by someone else (from an open-source library, a collaborator, an online resource), the documentation must acknowledge the original source, including the origin or author's name.

This is a directly tested requirement in the Create Task. If your CPT program includes any code from outside sources, your documentation must credit them.

Key Vocabulary