AP CSP Big Idea 1 (Creative Development): Artifacts, Process, Requirements, Collaboration, Debugging, Documentation, and IP

Computational artifact

Anything created with a computer (or computing tools) that communicates something to an audience (e.g., program, video, infographic, simulation).

Program

A set of instructions that a computer can execute.

Purpose

The goal of an artifact—what it is trying to accomplish (the “why,” not just the features).

Audience

The intended users or viewers an artifact is designed for; defining it helps you make good design tradeoffs.

Criteria

Measures of success used to evaluate how well an artifact meets its goals (e.g., “create an account in under 30 seconds”).

Constraints

Limitations you must work within (e.g., time, platform, offline-only, free assets).

Accessibility

Design choices that help more people use the artifact (e.g., color contrast, text size, captions).

Iterative development

Building, testing, learning, and improving repeatedly rather than trying to get it perfect in one attempt.

Ideation

The stage where you generate ideas and choose a direction for what to build.

Planning

Deciding what to build, for whom, and how you’ll measure success (criteria/constraints/requirements).

Prototyping

Creating an early version to answer questions quickly and reduce risk before full development.

Prototype

A preliminary version of an artifact used to learn and test ideas; it can be incomplete.

Low-fidelity prototype

A rough, quick prototype (e.g., paper sketches, slide mockups, wireframes) used to test concepts cheaply.

High-fidelity prototype

A more realistic, detailed prototype (often partially functional) that looks/feels closer to the final product.

Implementation

The stage where you build the actual artifact or program.

Testing

Running an artifact/program to check whether it behaves as intended and meets requirements/criteria.

Feedback

Information from users/teammates/stakeholders used to improve an artifact; patterns matter more than one opinion.

Refinement

Improving an artifact based on evidence from testing/feedback (includes bug fixes and UX/design improvements).

Requirement

A specific statement of what the artifact must do or be; connects purpose to implementation.

Testable requirement

A requirement written so you can verify it clearly (e.g., “sort by due date automatically”).

Vague goal

A broad, hard-to-measure objective (e.g., “make it user-friendly”) that needs translation into testable requirements.

User story

A requirement format: “As a [type of user], I want [goal], so that [reason]” to clarify audience and purpose.

Tradeoff

A compromise where improving one aspect of a design often reduces another (e.g., simplicity vs. features).

Justification chain

Explaining a design decision by linking audience needs, criteria/constraints, and the chosen solution.

Feature creep

Adding extra features that don’t support the purpose, making it harder to finish or meet key requirements.

Collaboration

Working with others throughout development to combine strengths, improve creativity, and reduce errors.

Peer instruction

Students working in pairs/small groups to discuss concepts and solve problems, often catching misunderstandings early.

Single source of truth

One agreed place for the latest requirements/tasks/version to reduce confusion and overwritten work.

Versioning

Keeping track of which project version is current and being able to recover older versions if needed.

Version control system

A tool/process for managing changes when multiple people edit files and for restoring earlier versions.

Test case

A specific input and situation used to check whether a program meets an expected behavior.

Normal case

A test case representing typical expected use (standard inputs and common user actions).

Edge case

A test case using unusual but possible inputs/situations (boundary values like 0 or very large numbers).

Error case

A test case using invalid/unexpected input (e.g., blank, negative numbers, wrong data type) to see how the program handles it.

Syntax error

An error where the programming language’s rules aren’t followed (often prevents the code from running).

Runtime error

An error that occurs during execution and stops the program (e.g., division by zero).

Logic error

An error in the algorithm/conditions that makes the program behave incorrectly even though it runs.

Overflow error

An error that occurs when a computation produces a number outside the representable range for its data type.

Design flaw

A problem where the program works as coded but fails to meet user needs or criteria (a usability/UX issue).

Debugging

A systematic process of finding and fixing the cause of bugs (not random guessing).

Logging (extra output statements)

Temporarily displaying/printing variable values or messages to inspect program state while debugging.

Documentation

Written information explaining how something works and why choices were made (supports collaboration, maintenance, and evaluation).

README

A document that describes what the project is, how to run/use it, and often includes notes like requirements and citations.

Intellectual property

Creations of the mind (e.g., music, writing, images, code) that may be legally protected.

Copyright

Automatic legal protection that gives creators exclusive rights over their original work (e.g., copying/distributing).

License

Rules/permissions that specify how a resource may be used, modified, and shared (often with conditions).

Creative Commons (CC)

A set of standardized licenses commonly used for media that allow reuse with conditions like attribution or no derivatives.

Open source

Software whose source code is available under a license that allows others to view, use, modify, and share under conditions.

Plagiarism

Presenting someone else’s work as your own (e.g., copying code/media without required attribution).

Attribution

Giving proper credit to reused resources (typically creator, title, link, license, and note about changes).