How do programmers move from an idea to a working program using an iterative design process?
Topic 1.3 Program Design and Development: programs are developed iteratively through investigating, designing, prototyping and testing, using tools such as program requirements, specifications and feedback.
A focused answer to AP CSP Topic 1.3, covering the iterative development process, investigating and reflecting, program requirements and specifications, designing and prototyping, the role of user feedback, and how the Create task documents the development process.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this topic is asking
The College Board (Topic 1.3) wants you to understand how a program is developed, not just written. Development is iterative and incremental: you investigate the problem, design a solution, build a prototype, test it, gather feedback, and refine, repeating as needed. You need to know the phases (investigating, designing, prototyping, testing), the role of program requirements and specifications, and how to document your own development process in the Create performance task.
The iterative development process
The CED frames development in phases that you cycle through:
- Investigating and reflecting. Understand the problem, the intended users and their needs. Reflect on what the program must achieve.
- Designing. Plan the structure: the parts of the program, how they connect, and the algorithms and data they use.
- Prototyping. Build an early, often partial version to try out an idea quickly.
- Testing. Run the program with a range of inputs to check it behaves correctly, and gather feedback.
You loop back: testing reveals problems, which send you back to design or investigation.
Requirements and specifications
The role of feedback
Feedback is central to iteration. It comes from:
- Users, who reveal whether the program actually meets their needs.
- Testing, which reveals whether the program behaves correctly across inputs.
- Peers and collaborators, who review design and code.
Acting on feedback is what makes each iteration better than the last.
Try this
Q1. Explain why software development is described as iterative. [2 points]
- Cue. It proceeds through repeated cycles of building, testing and refining, with feedback from each cycle improving the next, rather than a single straight-line process.
Q2. Distinguish a program requirement from a program specification. [2 points]
- Cue. A requirement states what the program must do (its goals/constraints); a specification states how it should behave to meet that requirement, including expected inputs and outputs.
Exam-style practice questions
Practice questions written in the style of College Board exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
AP 2022 (style)1 marksMultiple choice. A team releases an early, incomplete version of a program to a small group of users, gathers their feedback, and then improves the program based on what they learned. Which aspect of program development does this best illustrate?
(A) That a finished program must never be changed once released.
(B) An iterative development process driven by user feedback.
(C) That requirements should be ignored during development.
(D) That testing is unnecessary if users are happy.
Show worked answer →
The answer is (B).
Releasing an early version, gathering feedback and improving describes iterative development: developing in repeated cycles of building and refining, informed by feedback. (A) contradicts iteration. (C) is wrong: requirements guide the work. (D) is wrong: feedback is a form of testing, not a replacement for it.
Markers reward identifying the build-feedback-refine cycle as iterative development.
AP 2020 (style)3 marksCreate performance task (style). Write two to three sentences describing one difficulty you encountered while developing your program and how you resolved it through an iterative process.
Show worked answer →
A strong response names a specific difficulty and the iterative steps taken to resolve it.
Model response: "While developing my quiz program, I found that the score was always one too high because I was counting a question as correct before checking the answer. I tested the program with known inputs, traced the logic, moved the score increment inside the correct branch of the conditional, and retested until the score matched the expected value."
This earns credit because it (1) describes a specific difficulty (an off-by-one scoring bug), (2) shows an iterative process (test, trace, fix, retest), and (3) shows resolution. A vague answer ("it was hard but I fixed it") does not score.
Related dot points
- Topic 1.1 Collaboration: collaboration produces a program that reflects diverse perspectives, and effective collaboration uses defined roles, consensus building and tools such as pair programming.
A focused answer to AP CSP Topic 1.1, covering why collaboration improves a program, the inclusion of diverse perspectives, consensus building, communication and conflict resolution, pair programming, and how the Create performance task asks you to describe collaboration.
- Topic 1.2 Program Function and Purpose: a program is a sequence of instructions that accomplishes a goal; programs receive input, produce output, and their behavior is shaped by purpose and intended users.
A focused answer to AP CSP Topic 1.2, covering what a program is, function versus purpose, the input-process-output model, event-driven programs, program behavior and intended users, and how the Create task asks you to describe your program's purpose and function.
- Topic 1.4 Identifying and Correcting Errors: programs contain logic, syntax, runtime and overflow errors, and programmers find and fix them by testing with carefully chosen inputs and debugging.
A focused answer to AP CSP Topic 1.4, covering logic, syntax, runtime and overflow errors, testing with chosen inputs including edge cases, debugging strategies such as tracing and adding display statements, and how to describe testing in the Create task.
- Topic 3.12-3.14 Procedures and Libraries: procedures are named, reusable blocks with parameters and return values, and libraries and APIs package procedures so programmers reuse code through abstraction.
A focused answer to AP CSP Topics 3.12 to 3.14, covering defining and calling procedures, parameters and return values, procedural abstraction, modularity, libraries and APIs, and how reusing procedures manages complexity, with worked pseudocode.
- Topic 3.15/3.16 Random Values and Simulations: simulations are simplified, abstract models of real phenomena that often use random values to represent variability, trading detail for speed, safety and repeatability.
A focused answer to AP CSP Topics 3.15 and 3.16, covering the RANDOM procedure and generating random values, what a simulation is, why simulations are abstractions, their advantages and limitations, and using randomness to model variability, with worked pseudocode.
Sources & how we know this
- AP Computer Science Principles Course and Exam Description — College Board (2025)