AP Computer Science Principles Unit 1 ReviewCreative Development

AP Computer Science Principles Unit 1, Creative Development, is about how computing innovations actually get built. The single biggest idea is that programs improve through an iterative process where teams with diverse perspectives design, prototype, test, and revise based on real user feedback. You'll learn how collaboration shapes innovations, what programs do with inputs and outputs, how a development process works, and how to find and fix the four major error types.

What this unit covers

Collaboration and why diverse teams build better software

• A computing innovation is anything that includes a program as an integral part of how it works. It can be physical (a self-driving car), nonphysical software (photo editing apps), or a concept (e-commerce).
• Effective collaboration produces innovations that reflect the talents and perspectives of everyone who built them. Diverse teams help catch bias before it gets baked into a product, like a facial recognition system trained only on one demographic.
• Pair programming is a common collaboration model where two programmers work at one computer, one writing code while the other reviews in real time.
• Online tools (shared documents, code repositories, feedback threads) let teams share ideas and give feedback without being in the same room.
• Good teams practice specific interpersonal skills, including communication, consensus building, conflict resolution, and negotiation. These show up by name on the exam.

What programs are and what they do

• A program (also called software) is a collection of program statements that performs a specific task when run by a computer. A code segment is just a piece of a program.
• Every computing innovation has a purpose, either solving a problem or pursuing creative expression. Understanding that purpose helps developers build the thing well.
• Inputs are data sent to a computer for processing. They can be tactile, audio, visual, or text. Outputs are data sent from a program to a device, in those same forms.
• Events drive a lot of program behavior. A key press, a mouse click, or a program starting up can each trigger an action and supply input data.
• Output is usually based on input or the program's prior state (internal values it's tracking). A program needs to work for a variety of inputs and situations, not just the one case you tested.

The development process: investigate, design, prototype, test, repeat

• Development can be ordered and intentional or exploratory in nature, but most processes share four phases. You investigate and reflect, design, prototype, then test.
• "Iterative" means you loop back. Feedback, testing results, or reflection can send you back to an earlier phase to refine and revise. Real programs are rarely right on the first pass.
• Investigation figures out what users actually need. You can collect data through surveys, user testing, interviews, and direct observation.
• Program requirements describe what the program must do, including constraints and the concerns of the people who will use it. Requirements also tell you which test inputs matter.
• Documentation is a written description of what a code segment, event, procedure, or program does and how it was developed. Comments are documentation written inside the program for humans to read. They never affect how the program runs.
• If you use code someone else wrote, acknowledge it in your documentation, including the origin or original author's name. This matters for the Create performance task too.

Errors and testing

• A syntax error breaks the rules of the programming language, like a missing parenthesis. The program won't run at all.
• A logic error is a mistake in the algorithm that makes the program behave incorrectly or unexpectedly. The program runs fine, it just gives wrong answers. These are the sneakiest.
• A run-time error happens during execution, like dividing by zero. Each programming language defines its own run-time errors.
• An overflow error occurs when a computer tries to handle a number outside the range it can represent.
• Testing uses defined inputs to check that a program produces expected outcomes. The best test inputs sit at or just beyond the extremes (minimum and maximum) of the input range, because edge cases are where programs break.

Unit 1, Creative Development at a glance

Why Unit 1, Creative Development matters in AP CSP

Creative Development is the foundation the whole course stands on. Every other unit assumes you know what a program is, why it exists, and how it gets refined. It also sets up the mindset AP CSP cares about most, that computing is a human activity where design choices, testing, and collaboration determine whether an innovation actually serves people.

• The input-process-output model you learn here is the lens for analyzing every program and code segment in the rest of the course.
• The iterative development process and documentation habits directly mirror what you'll do on the Create performance task, where you build a program and write about its development.
• The bias-and-diversity thread starts here and becomes a major topic when you evaluate the effects of computing on society.

How this unit connects across the course

• The idea that program output depends on input and internal state becomes concrete when you learn how data is represented and processed (Unit 2).
• Everything about code segments, errors, and testing pays off immediately when you start reading and writing actual algorithms, conditionals, and procedures (Unit 3). Logic errors in particular show up constantly in code-tracing questions there.
• Computing innovations like self-driving cars and e-commerce reappear when you study how devices communicate and how systems handle faults (Unit 4).
• Bias in development, introduced through collaboration here, expands into a full discussion of harmful and beneficial effects of computing, the digital divide, and computing bias (Unit 5).

Key syntax and algorithms

Unit 1 is lighter on code than later units, but a few concrete skills are tested directly:

• Comments: written into a program for people to read; they never change how the program runs. Know that documentation should happen throughout development, not just at the end.
• The four-phase development process: investigating and reflecting, designing, prototyping, testing. Be able to match a described activity (like running a survey) to its phase. Surveys, interviews, user testing, and observation all belong to investigation.
• Error classification: given a described bug, label it syntax (breaks language rules), logic (wrong results, runs fine), run-time (crashes during execution), or overflow (number too large to represent).
• Edge-case testing: choose defined inputs at or just beyond the minimum and maximum of the expected range. If a program accepts ages 1 to 120, test 0, 1, 120, and 121.
• Event-driven input: recognize that a key press or mouse click is an event that supplies input data and changes the flow of execution.

Unit 1, Creative Development on the AP exam

AP CSP assesses you two ways, a multiple-choice exam and the Create performance task you complete during the year, and Unit 1 feeds both.

• On the multiple-choice exam, Creative Development concepts appear as scenario questions. You'll classify an innovation's purpose, identify which development phase a team is in, explain how collaboration or diverse perspectives improved (or could have improved) a product, and pick which error type matches a described bug.
• Testing questions ask you to select inputs that would best check a program's correctness. The right answer almost always involves values at or just beyond the extremes of the valid range.
• The Create performance task is where this unit pays off most. You document your program's development, describe its function and purpose, explain how you tested it, and acknowledge any code segments from other sources. The vocabulary and habits from Topics 1.2 and 1.3 are exactly what the written responses expect.
• Questions about comments and documentation tend to test one specific fact, that comments are for humans and do not affect program execution.

Essential questions

• Why do diverse teams build better, less biased computing innovations than individuals working alone?
• How does an iterative process turn a rough idea into a program that actually meets user needs?
• What separates a program that works for one input from a program that works for all valid inputs?
• How do programmers find errors they can't see just by reading the code?

Key terms to know

• Computing innovation: anything that includes a program as an integral part of its function, whether physical, software, or a concept.
• Program: a collection of program statements that performs a specific task when run by a computer; also called software.
• Code segment: a collection of program statements that is part of a program.
• Pair programming: a collaboration model where two programmers work together at one computer, trading off writing and reviewing.
• Event: a defined action (key press, mouse click, program start) that supplies input data and affects the flow of execution.
• Program behavior: how a program functions during execution, often described by how a user interacts with it.
• Iterative development: a process requiring refinement and revision based on feedback, testing, or reflection, often revisiting earlier phases.
• Program requirements: descriptions of what a program must do, including constraints and the concerns of its users.
• Program documentation: a written description of the function of a code segment, event, procedure, or program and how it was developed.
• Comment: documentation written inside a program for people to read; it does not affect how the program runs.
• Syntax error: a mistake where the rules of the programming language are not followed.
• Logic error: a mistake in the algorithm that causes incorrect or unexpected behavior even though the program runs.
• Run-time error: a mistake that occurs during the execution of a program, defined by the programming language.
• Overflow error: an error when a computer attempts to handle a number outside the range it can represent.

Common mix-ups

• Logic errors vs. run-time errors. A logic error gives you wrong output but the program keeps running. A run-time error stops execution (like dividing by zero). If the question says "unexpected results," think logic. If it says "crashes" or "halts," think run-time.
• Comments do not affect execution, ever. A tempting wrong answer will suggest a comment changed the program's behavior. It can't.
• Investigation is not the same as testing. Surveys, interviews, and observation happen during investigation to learn what users need. Testing uses defined inputs to check whether the finished code produces expected outputs.
• Acknowledging borrowed code goes in your documentation with the origin or author's name. Using someone else's code segment isn't a problem; failing to credit it is.