AP Computer Science Principles Unit 1: Creative Development Notes

Introduction

Creative development connects a computing idea to a real purpose through collaboration, iteration, testing, and clear documentation.

The important habit is traceability. A purpose leads to a function; a user need leads to a revision; a test result leads to a decision; and an observed divergence leads to a repair. Current Create-task rules also determine which work may be collaborative and which submitted artifacts must be individual.

Purpose

state the need or opportunity before choosing features

Collaboration

use distinct perspectives and preserve ownership of decisions

Iteration

revise a small version in response to evidence

Testing

compare expected and actual behavior at normal and boundary inputs

Reference

AP CSP reference

Use these distinctions when explaining a program, revision, or error.

Current exam guidance: Aligned to the Fall 2023 AP CSP framework used in 2026–27. The May 14, 2027 digital exam includes 70 multiple-choice questions in 120 minutes plus two Create-related written-response questions in 60 minutes. The Create components are due April 30, 2027 at 11:59 p.m. ET; current College Board directions always control submission policy.

1.1

Collaboration

How does collaboration improve a computational solution without blurring responsibility?

Short answer

Collaboration works when different perspectives uncover requirements and risks, while a decision log preserves who changed what, why it changed, and what evidence supported the choice.

Know firstA stated program purpose · Respectful critique

Make disagreement useful and decisions traceable

Dividing a project into tasks is coordination, but it does not automatically create the benefit of collaboration. The benefit comes from comparing perspectives: one person may notice a missing user, another may find a boundary input, and another may recognize that a color-only signal is inaccessible. A team should test suggestions against the program purpose and explicit evidence instead of accepting the loudest opinion.

A short decision log preserves accountability. Record the proposed change, its owner, the reason for it, and the result of a relevant test. During the official Create task, current rules allow collaboration on program-code development, but the video and Personalized Project Reference are individual work. External or AI-assisted material must be acknowledged under current policy, and a student must understand the code they submit.

Development model trace

Follow one critique into a tested revision

purpose: alert a rider without requiring constant screen attention
proposal: show a red status dot
critique: color alone is not readable by every user
revision: add text status and optional vibration
test: status remains understandable with color hidden

Execution stateStep 1 of 4

stage: purpose
artifact: rider alert
evidence: need can be stated

Open complete trace table

Complete trace states
Step	stage	artifact	evidence
1	purpose	rider alert	need can be stated
2	proposal	red dot	visual state exists
3	critique	accessibility risk	color-only meaning fails
4	revision	text plus optional vibration	noncolor test passes

Output

accept: text status + optional vibration

The team retains the original purpose, rejects a color-only representation after an accessibility review, and accepts a text label with an optional vibration after a noncolor test.

Run a productive design review

Restate the shared purpose before judging a proposal.
Ask which user, input, or failure case the proposal addresses.
Record the owner, rationale, and test evidence for an accepted change.
Keep official-task artifacts within the current collaboration and attribution rules.

Keep these three ideas

Different perspectives should expose a specific requirement or risk.
A decision log ties changes to people, reasons, and evidence.
Create code collaboration does not make every submitted artifact collaborative.

1.2

Program Function and Purpose

What is the difference between a program’s purpose, function, input, and output?

Short answer

Purpose names the need or opportunity; function describes observable behavior; input enters the program; and output communicates a result produced by the program.

Know firstReading a short algorithm · Distinguishing an action from a goal

Describe the need separately from the behavior

A purpose statement answers why the program exists. A function statement answers what the running program does. “Help a rider compare fare categories” is a purpose; “read an age category and display a fare label” is a function. Repeating the code line by line usually describes implementation, not purpose.

Inputs and outputs belong to the information flow. Input may come from a user, sensor, file, or another program. An event—such as a selection, key press, or sensor update—can supply input and trigger a handler instead of waiting in one fixed sequence. Output can be text, sound, an image, a stored value, or a signal sent elsewhere. Do not invent a result the program does not compute: a fare label does not prove that a user saved money or chose a particular route.

AP pseudocode trace

Classify the parts of a fare-label program

category ← "youth"
IF category = "youth"
{
  DISPLAY("reduced fare")
}
ELSE
{
  DISPLAY("standard fare")
}

Execution stateStep 1 of 4

role: purpose
value: help compare fare categories

Open complete trace table

Complete trace states
Step	role	value
1	purpose	help compare fare categories
2	event and input	category selection supplies youth
3	function	select a label from the category
4	output	reduced fare

Output

reduced fare

The input category is youth, so the first branch runs and displays reduced fare. The output supports comparison but does not calculate a price or guarantee savings.

Write an accurate program description

Name the problem, interest, or opportunity as the purpose.
Describe the behavior a user can observe as the function.
Identify where each input originates.
State only outputs the program actually produces.

Keep these three ideas

Purpose answers why; function answers what.
Inputs enter the computation and outputs leave it.
Describe only behavior and effects supported by the program.

1.3

Program Design and Development

How does an iterative process turn a purpose into a dependable program?

Short answer

Developers build a small version, test it against a need, collect evidence, and revise; each cycle should reduce a named risk rather than merely add features.

Know firstProgram purpose and function · Basic test cases

Build in evidence-sized steps

A useful development cycle begins with users, constraints, and a testable purpose. A prototype need not contain every planned feature. It should expose one uncertain design choice quickly enough to gather evidence. Feedback then becomes a requirement or test case, not a vague instruction to “make it better.”

Processes may be ordered or exploratory. Incremental development builds and checks one small piece before adding it to the whole; iterative development revisits and improves earlier work after feedback or testing. Neither is an excuse for endless feature growth. Documentation should preserve the reason for a choice, data or media provenance, and what remains unresolved. Comments are documentation for people and do not change program execution; code from collaborators or external sources still needs acknowledgment.

Development model trace

Use evidence to choose the next version

v1: visual reminder only
feedback: reminder is missed when the screen is not visible
v2: add optional vibration
test: visual and vibration modes both trigger at the chosen time
proposal: collect continuous location
decision: reject; it does not support the stated reminder purpose

Execution stateStep 1 of 4

version: v1
feature: visual reminder
result: screen-away test fails

Open complete trace table

Complete trace states
Step	version	feature	result
1	v1	visual reminder	screen-away test fails
2	v2 plan	optional vibration	addresses observed failure
3	v2 test	two notification modes	both modes pass
4	scope review	continuous location	rejected as unrelated collection

Output

release candidate: v2

Version two responds directly to observed feedback and passes both notification tests. Continuous location collection is rejected because the reminder purpose does not require it.

Choose the next development step

State one uncertainty or failure in the current version.
Make the smallest revision that can address it.
Select a test whose outcome could change the decision.
Document the evidence and the remaining risk before expanding scope.

Keep these three ideas

Prototype the uncertain part first.
Turn feedback into a requirement or test.
Reject added scope that does not serve the purpose.

1.4

Identifying and Correcting Errors

How can a trace locate the cause of an error instead of merely showing a wrong result?

Short answer

Write the expected state, record the actual state after each step, and repair the first divergence; then rerun normal, boundary, and regression cases.

Know firstAssignments · Iteration

Debug from the first wrong state

A syntax error violates language rules, a runtime error occurs during execution, a logic error produces unintended behavior, and an overflow error exceeds a representation’s defined numeric range. The AP reference language does not impose a fixed integer bit width, so infer overflow only when a question specifies a bounded representation. For a logic error, the final wrong output is only a symptom. Hand traces, visualizations, debugger state, and temporary output can expose the earliest point where actual behavior first differs from the expected behavior.

The faulty loop below adds n repeatedly, so with n = 3 its first value is 3 instead of the expected 1. The repair introduces a counter that changes from 1 through n. After editing, test n = 0, n = 1, and larger values; a single passing example cannot expose every boundary or regression.

Debugging model trace

Find the first divergence, then verify the repair

faulty body:   total ← total + n
expected body: total ← total + counter

repair:
n ← 3
total ← 0
counter ← 1
REPEAT n TIMES
{
  total ← total + counter
  counter ← counter + 1
}
DISPLAY(total)

Execution stateStep 1 of 4

stage: specification
input: n = 3
expectedTotals: 0, 1, 3, 6

Open complete trace table

Complete trace states
Step	stage	input	expectedTotals	actualTotal	expectedTotal	firstDivergence	changingState	repairedTotals	testedInputs	result
1	specification	n = 3	0, 1, 3, 6	—	—	—	—	—	—	—
2	faulty pass 1	—	—	3	1	true	—	—	—	—
3	repair	—	—	—	—	—	counter = 1, 2, 3	0, 1, 3, 6	—	—
4	regression	—	—	—	—	—	—	—	0, 1, 3, 5	all match n(n + 1) / 2

Output

repaired output: 6; regression: pass

The faulty first pass produces three instead of one, locating the earliest divergence. A changing counter repairs the trace, and inputs zero, one, three, and five all match the stated triangular-sum specification.

Run an error-isolation pass

State expected output and intermediate states before changing code.
Trace the actual state after every statement or iteration.
Repair the first divergence, not the last line that looks suspicious.
Rerun boundary cases and all cases that passed before the edit.

Keep these three ideas

Classify logic, syntax, runtime, and overflow failures accurately.
Find the first expected-versus-actual divergence.
Regression tests protect behavior that already worked.

Cumulative review

Creative Development review

Explain how a program moves from a need to tested behavior while preserving evidence and responsibility.

Describe the program

Separate purpose from function.
Name each input source and observable output.
Avoid claims the program does not compute or demonstrate.

Develop the solution

Connect feedback to a concrete revision.
Compare versions with a relevant test.
Record attribution and remaining constraints.

Find and repair errors

Classify syntax, runtime, and logic failures.
Locate the first incorrect state.
Use boundary and regression cases after every repair.

Introduction

AP CSP reference

Make disagreement useful and decisions traceable

Follow one critique into a tested revision

Run a productive design review

Keep these three ideas

Describe the need separately from the behavior

Classify the parts of a fare-label program

Write an accurate program description

Keep these three ideas

Build in evidence-sized steps

Use evidence to choose the next version

Choose the next development step

Keep these three ideas

Debug from the first wrong state

Find the first divergence, then verify the repair

Run an error-isolation pass

Keep these three ideas

Creative Development review

Describe the program

Develop the solution

Find and repair errors

Practice AP Computer Science Principles in the real test engine.