AP CSP 1.3 Program Design and Development | Iterative Design
Program Design and Development
After this lesson, you will be able to:
- Explain why program design begins by investigating and reflecting on a need or problem
- Describe the development process as iterative and non-linear, cycling through investigating, designing, prototyping, and testing
- Define program requirements and identify how a design can be represented as requirements, a diagram or flowchart, or a prototype
- Explain how design decisions involve tradeoffs and sometimes require input from users or others
- Explain the purpose of program documentation and comments, and why documentation is added throughout development and used during maintenance
A student sits down to build an app, opens the editor, and starts typing code immediately with no plan. Halfway through they realize they never asked who the app is for or what it actually needs to do, and now large parts have to be thrown out and rebuilt. A second student spends the first hour investigating the need, sketching a design, and building a rough prototype to test one idea. Which student is following the process the AP CSP framework describes, and why does starting with the code so often cost you time later?
Design Starts With a Need, Not With Code
Good program design does not begin at the keyboard. It begins by investigating and reflecting on a need or a problem. Before writing anything, a developer studies the situation, often consulting or using multiple sources, and works to understand the needs of the intended users. The whole point of a program is to serve those users, so figuring out who they are and what they actually need is the first real step of development.
This is why "just start coding" is the wrong instinct. A program built without understanding the need often solves the wrong problem, or solves it in a way that does not fit how real users work. Investigating first, and reflecting on what you find, is what keeps the rest of the process pointed at something worth building.
When a question asks what a developer should do first, the credited answer is almost always about investigating the problem and understanding the users' needs, not about choosing a programming language or writing code. Understanding the need comes before implementation.
The Development Process Is Iterative and Non-Linear
The framework describes development as a cycle of four kinds of activity:
- Investigating and reflecting on the need, the users, and what you have learned so far.
- Designing a plan for how the program will work.
- Prototyping an early version to try out an idea.
- Testing to see whether it works and meets the need.
The key word is iterative. These steps are not a straight line that you walk through once. The process is non-linear: you repeat steps and revisit earlier ones. Testing a prototype might send you back to redesign; a design choice might raise a new question that sends you back to investigate. You cycle through the activities as many times as the program needs, refining a little more each pass.
"Development is a fixed sequence: you finish investigating, then finish designing, then finish coding, then test once, and you are done." That waterfall picture is exactly what the framework says development is not. The tested idea is that development is iterative and non-linear, so you loop back to earlier steps whenever what you learn tells you to.
Requirements and Ways to Represent a Design
Program requirements describe how a program functions, and they may include the needs and expectations of the users. Requirements are the agreed-upon description of what the program has to do, so they give the team a shared target to build toward and to test against later.
A design can be represented in more than one form, and the framework names three:
| Representation | What it is |
|---|---|
| Requirements | A written description of what the program must do and how it should function, often including user needs and expectations. |
| Diagram or flowchart | A visual representation of the program's structure or the flow of steps, showing how parts connect before any code is written. |
| Prototype | An early, incomplete version of the program built to test an idea and get feedback. |
All three describe the design, not the finished program. A prototype in particular is an early version used to try out ideas: it is meant to be rough, and it exists so you can learn something before committing to the full build.
Know that a design can be shown as requirements, a diagram or flowchart, or a prototype. If a question describes a rough early version made to test whether an idea works, that is a prototype, and its purpose is to test ideas, not to be the final product.
Design Decisions and Tradeoffs
Building a program is a stream of design decisions: which feature to include, how a screen should behave, what to leave out. These decisions are sometimes made collaboratively, and they sometimes require input from the users or from other people who understand the need. A developer working alone still benefits from asking users what they expect.
Almost every design decision involves tradeoffs. Adding a feature might make the program more capable but harder to use; making it faster might make it more complex to build. There is rarely a choice that is better in every way, so developers weigh the options against the program's goal and the users' needs and pick the one that fits best.
Program Documentation and Comments
Program documentation is a written description of what a program or a segment of a program does, how it behaves, and how it was developed. It is written for people: the developer who will come back to the code later, and anyone else who has to read, use, or modify it.
Comments are documentation placed inside the code itself. In text-based languages a comment is ignored by the computer when the program runs, so it exists purely to explain the code to a human reader. Comments are one form of documentation, but documentation also includes descriptions kept outside the code.
Two facts the exam cares about:
- Documentation is useful during development, helping the team track how the program works and why decisions were made, and it is useful later for maintenance, when someone needs to fix or update the program.
- Documentation should be added throughout development, not saved for the very end. Writing it as you go keeps it accurate and useful while you are still building.
"Documentation is a final step you do after the program is finished." That is the wrong picture. The framework says documentation should be added throughout development and helps during the build as well as later during maintenance. Waiting until the end usually means the documentation is rushed, incomplete, or already out of date.
How This Shows Up on the Create Performance Task
The Create Performance Task is completed individually under current AP rules, so your program and your written responses must be your own. Topic 1.3 is the process you are expected to live out while you build. You do not write a program in one straight shot; you follow the iterative development process, cycling through designing, prototyping, and testing, and returning to earlier steps as you learn what works.
The written response asks you to describe how you developed the program. You will point to a part of the program you developed independently and explain the process of testing and refining it: what you tried, what a test revealed, what you changed in response, and how the program improved. That is the iterative process in miniature, so getting comfortable with investigate, design, prototype, test, and repeat here makes that written response far easier to write later. Documenting your process as you go, rather than reconstructing it at the end, is what makes the description accurate.
Get a free AP CSP question every day
Join 3,000+ students. Daily practice, study tips, and exam strategies.
A developer is beginning work on a new program. According to the AP CSP development process, which activity should come at the very start?
Which statement best describes the development process as presented in the AP CSP framework?
Consider these claims about program documentation:
- I. Documentation should only be written after the program is completely finished.
- II. Comments are a form of documentation placed inside the code to explain it to human readers.
- III. Documentation is useful both during development and later during maintenance.
A team writes code for weeks, adds no comments and keeps no written descriptions, and plans to document everything the night before submission. Which specific problem with their process does the framework most directly warn against?
Before building a full scheduling app, a developer creates a rough, incomplete version of just the calendar screen and shows it to a few intended users to see whether the layout makes sense. What is this rough early version best called, and what is its purpose?
A developer must choose between adding a powerful feature that makes the program harder to learn and keeping the program simple but less capable. Which idea from the framework does this choice most directly illustrate?
Design Sprint
Master the iterative development process: investigate, design, prototype, test, refine.
How to play: order the development steps, or pick the smartest next move. Feedback and testing drive every good build.
Frequently Asked Questions
🔗 Continue studying
Topic 1.3 is where students learn that real development loops instead of marching in a straight line. Have them keep a short development log as they build a small project, recording each investigate, design, prototype, and test cycle and the decisions they made. That log doubles as practice for the Create Task written response. The Superpack includes an iterative-process worksheet, a requirements-versus-prototype sorting activity, and a documentation checklist. View what's included →
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]