AP CSP Unit 1 Cheat Sheet: Creative Development

The basics

What it covers: How programs are created to serve a purpose — collaboration, program function and purpose, the iterative development process, and identifying and correcting errors.

Exam weight: Big Idea 1 is about 10–13% of the AP CSP multiple-choice exam.

The big question: How do people collaborate to design, build, document, and debug programs that serve a purpose?

Computational thinking practices: Computational Solution Design, Algorithms & Program Development, Abstraction, Code Analysis, Computing Innovations, and Responsible Computing.

Key topics at a glance

Program Function & Purpose

Function = what the program does (its behavior). Purpose = why it was made and who it serves. Describe both when explaining a program.

Inputs & Outputs

Input: data received while running (user, device, sensor, file, another program). Output: data produced (visual, audible, tactile, text). Programs can be event-driven.

Collaboration

Diverse perspectives make programs better and more inclusive and catch errors. Effective collaboration needs communication, consensus, and shared responsibility.

Iterative Development

A repeating cycle: investigate & reflect → design → prototype → test. Use feedback each pass. Incremental: build and test small pieces.

Requirements & Prototypes

Requirements describe what the program must do. A prototype is an early version used to test ideas and gather feedback before finishing.

Documentation

Comments are notes ignored by the computer that explain code to people. Good documentation aids collaboration, maintenance, and debugging.

Types of Errors

Logic: runs but wrong output. Syntax: breaks the rules, won't run. Run-time: fails while running (e.g., divide by zero). Overflow: value too large for the bits available.

Debugging & Testing

Debugging = finding and fixing errors. Testing = running with varied inputs (and edge cases). Use test cases, hand-tracing, and display statements.

The key terms you must know

Program — statements that together perform a task when run.
Function vs. purpose — what a program does vs. why it exists and who it serves.
Input / output — data received while running vs. data produced.
Event-driven program — actions run in response to events (clicks, keys, sensors).
Collaboration — teamwork with diverse perspectives that improves programs.
Iterative development — repeating investigate → design → prototype → test.
Incremental development — building and testing a program piece by piece.
Requirements — a description of what the program must do.
Prototype — an early version built to test ideas and get feedback.
Comment / documentation — notes that explain code to people.
Logic error — runs but produces incorrect results.
Syntax error — breaks the language's rules; usually won't run.
Run-time error — occurs while running (e.g., divide by zero).
Overflow error — a value too large for the available bits.
Debugging / testing — finding and fixing errors; running with varied inputs.

Key themes to remember

Every program has a purpose. Be able to state what a program does and why, plus its inputs and outputs.
Development is iterative, not one-and-done. Investigate, design, prototype, test — then repeat with feedback.
Collaboration and diverse perspectives improve software. More viewpoints mean fewer blind spots and better ideas.
Errors are normal; handling them is a skill. Classify the error, then test and debug systematically.
Document as you go. Comments and clear descriptions make programs maintainable and shareable.

Common exam traps

Function ≠ purpose. Function is the behavior; purpose is the reason and audience. Questions often test the difference.
Syntax vs. logic errors. Syntax errors usually stop the program from running; logic errors let it run but give the wrong answer.
A program that runs is not necessarily correct. It may still have logic errors — testing is what reveals them.
Run-time vs. overflow. Run-time errors happen during execution generally; overflow specifically means a value exceeds the available bits.
Comments are for people, not the computer. They do not affect how the program runs.
Collaboration is more than dividing work. It requires communication, consensus, and crediting contributors.
Prototypes are meant to be incomplete. Their job is to test ideas and gather feedback, not to be the finished product.