Think about the last group project you did. Was the final product better or worse than what you'd have made alone? Be honest — sometimes it's worse! Now think about why. When teams work well, each person catches mistakes the others miss and contributes ideas nobody else had. When teams work badly, nobody's ideas fully develop.
The College Board cares about this because real software is never written alone. The AP CSP exam asks 2–3 questions per year about how collaboration affects computing artifacts — and your Create Performance Task has strict rules about what you may and may not collaborate on. Let's get both right.
Two terms you must keep straight:
Trap alert: an innovation without a program integral to it (a new bicycle frame design, even if designed using a computer) is not a computing innovation. The program has to be part of how the innovation works, not just how it was made.
The CED's claims about collaboration are specific, and the exam tests them close to verbatim:
Concrete collaboration practices the CED names:
Effective collaboration is a skill, not an accident: it needs communication, consensus-building, conflict resolution, and honest feedback both ways.
Purpose is about the human need. Function is about the program's behavior. One sentence each:
Purpose: why was it made? Function: what does it do?
The Create PT written responses ask you to state both about your own program, and passage questions routinely ask "which of the following best describes the purpose" — with a distractor describing the function instead. Know which is which.
A program input is data sent to a program for it to use. Inputs can come from: - the user (tapping a button, typing text) - a device or sensor (GPS location, accelerometer) - another program, a file, or the internet
A program output is any data the program sends back out: text on screen, sound, an image, a file, a signal to a robot motor. Outputs are usually determined by the inputs — change the input, and the output changes.
Modern programs are often event-driven: parts of the program run when an event happens (a click, a message arriving, a timer firing) rather than strictly top-to-bottom. If a question describes "code that runs when the user taps the screen," that's event-driven programming.
The exam (and your PT video) describes programs in a standard shape:
[DIAGRAM: Flow of a described program, three labeled boxes left to right:
INPUT (user enters a list of grocery items) → PROGRAM (groups items by store aisle,
using a stored aisle map) → OUTPUT (displays the reordered shopping list).]
When you read a program description, immediately tag: what's the input? what's the output? what's the purpose? what's the function? Four tags, every time. That habit converts fuzzy passage text into answerable questions.
Problem: A team builds an app described as follows: "FloodWatch alerts residents of low-lying neighborhoods when river sensors predict flooding within six hours." Which part of this sentence is the app's purpose?
Strategy: Purpose = the human problem being solved. Function = the behavior.
Solution: The purpose is protecting residents from flood danger (the "why"). The function is reading sensor data and sending alerts (the "what it does"). The sentence mostly describes function ("alerts residents when sensors predict flooding"); the purpose is implied: keep people safe from floods.
Interpretation: On the exam, a purpose answer sounds like a goal ("to help residents stay safe"); a function answer sounds like a behavior ("it sends an alert when a threshold is crossed"). Match the question word to the answer's grammar.
Problem: A fitness app displays a daily activity score. The score is computed from step counts (from the phone's motion sensor), the user's age (entered at setup), and weather data (retrieved from an online service). Which of these are program inputs?
Strategy: Inputs = all data sent to the program for use, regardless of source.
Solution: All three. Sensor data, user-entered data, and data from another system are all inputs. The daily activity score is the output.
Interpretation: Students often count only what the user types as "input." The CED is broader: sensors, files, other programs, and online services all provide inputs.
Problem: A four-person team is building a museum-guide app. Two members visit museums weekly; two rarely do. One member uses a screen reader due to low vision. Which is the best description of how this team's composition affects the project?
(A) The team will finish faster because tasks can be split four ways. (B) The diversity of perspectives will help the team design an app that serves a wider range of visitors. (C) The team members with less museum experience will slow down the design process. (D) The app will work correctly only if every team member tests it.
Strategy: Recall the CED's claim: diverse teams → artifacts that serve more users, less bias.
Solution: (B). The CED's core collaboration claim is that diverse backgrounds and perspectives improve the artifact and reduce bias — the screen-reader user, for example, will surface accessibility needs early. (A) is about speed, which diversity doesn't guarantee. (C) treats different experience as a defect — backwards. (D) is an overstatement ("only if every member") of testing value.
Interpretation: Notice the wrong answers aren't absurd — (A) is a real benefit of teamwork generally. But the tested claim links diversity → better, less-biased design. Answer what the CED claims.
1. (B). Function = observable behavior when executed. (A) is the purpose. (C) and (D) are facts about the program, not its function.
2. (B). The ride-sharing service has a program integral to its function (the matching app). (A) and (D) were made or tested using computers — the products themselves don't run programs. (C) has no program at all.
3. (C). The user supplies the zip code for the program to use — a user-provided input. (A): the forecast display is the output. (B): the purpose is helping users plan for weather. (D): entering text can trigger events, but the zip code itself is data, i.e., input.
4. (B). This is the CED's claim stated plainly. (A) overclaims — bias is reduced, never guaranteed eliminated. (C) restricts collaboration to one phase; the CED says it helps in brainstorming, design, and testing. (D) is a made-up trade-off.
5. (B). Driver types; navigator reviews, catches errors, and thinks ahead; roles swap. (A) misstates the driver as working alone. (C) and (D) describe other roles entirely.
6. (A). Code that runs in response to an event (shake) = event-driven. (B) and (C) are unrelated concepts. (D) is contradicted — the shake is an input.
7. (C). "Help elderly users remember..." is the goal (purpose); "sounds an alarm and displays..." is the behavior (function). Order matters — read carefully; (A) reverses it.
8. (C). The displayed arrival time is what the program produces — an output. GPS data (A), user uploads (B), and online data (D) are all inputs.
9. (A). Sharing work, collecting responses, revising = feedback and iteration. (B) is the opposite. (C) overclaims — feedback doesn't eliminate testing. (D) is a specific two-person practice not described here.
10. (A) and (C). Both are the CED's stated benefits: reduced bias and caught mistakes. (B) guarantees too much. (D) is false — documentation matters regardless of team size. (Multi-select discipline: you need BOTH correct answers for the point.)
11. (B). The scan is data sent to the program (input); the audio is what it sends back (output). The other choices confuse physical objects with data.
12. (Model answer.) Purpose: My weather app exists to help me decide what to wear and whether to carry an umbrella. Function: when I open the app, it reads my phone's location, retrieves forecast data online, and displays the hourly temperature and rain probability. — Any app works; graded on correctly labeling a goal-statement vs. a behavior-statement.
Answer letter distribution check: B, B, C, B, B, A, C, C, A, A+C, B — singles: A×2, B×5, C×3 + one multi-select (A,C). B-heavy but acceptable; monitor across lessons.
12 (short response, PT-style). In two sentences, describe the purpose and the function of a program you use regularly (a real app is fine). Label each sentence.
Everything in this lesson maps straight onto your Create Performance Task:
Mini practice (WR 1 style): "Describe the purpose of your program, then describe how a user interacts with it." Try answering for the FloodWatch example: Purpose: to protect residents of low-lying areas from flood danger. Interaction: a resident enters their neighborhood; when sensor data predicts flooding within six hours, the app sends the resident an alert.
1. (B). Function = observable behavior when executed. (A) is the purpose. (C) and (D) are facts about the program, not its function.
2. (B). The ride-sharing service has a program integral to its function (the matching app). (A) and (D) were made or tested using computers — the products themselves don't run programs. (C) has no program at all.
3. (C). The user supplies the zip code for the program to use — a user-provided input. (A): the forecast display is the output. (B): the purpose is helping users plan for weather. (D): entering text can trigger events, but the zip code itself is data, i.e., input.
4. (B). This is the CED's claim stated plainly. (A) overclaims — bias is reduced, never guaranteed eliminated. (C) restricts collaboration to one phase; the CED says it helps in brainstorming, design, and testing. (D) is a made-up trade-off.
5. (B). Driver types; navigator reviews, catches errors, and thinks ahead; roles swap. (A) misstates the driver as working alone. (C) and (D) describe other roles entirely.
6. (A). Code that runs in response to an event (shake) = event-driven. (B) and (C) are unrelated concepts. (D) is contradicted — the shake is an input.
7. (C). "Help elderly users remember..." is the goal (purpose); "sounds an alarm and displays..." is the behavior (function). Order matters — read carefully; (A) reverses it.
8. (C). The displayed arrival time is what the program produces — an output. GPS data (A), user uploads (B), and online data (D) are all inputs.
9. (A). Sharing work, collecting responses, revising = feedback and iteration. (B) is the opposite. (C) overclaims — feedback doesn't eliminate testing. (D) is a specific two-person practice not described here.
10. (A) and (C). Both are the CED's stated benefits: reduced bias and caught mistakes. (B) guarantees too much. (D) is false — documentation matters regardless of team size. (Multi-select discipline: you need BOTH correct answers for the point.)
11. (B). The scan is data sent to the program (input); the audio is what it sends back (output). The other choices confuse physical objects with data.
12. (Model answer.) Purpose: My weather app exists to help me decide what to wear and whether to carry an umbrella. Function: when I open the app, it reads my phone's location, retrieves forecast data online, and displays the hourly temperature and rain probability. — Any app works; graded on correctly labeling a goal-statement vs. a behavior-statement.
Answer letter distribution check: B, B, C, B, B, A, C, C, A, A+C, B — singles: A×2, B×5, C×3 + one multi-select (A,C). B-heavy but acceptable; monitor across lessons.
Exam tip: CRD questions are the cheapest points on the exam — they test whether you know the CED's exact claims. When two answers both sound reasonable, pick the one that repeats CED language ("diverse perspectives," "reduce bias," "purpose = problem solved") rather than a plausible real-world generalization ("teams are faster").