AP CSP Create Performance Task Guide
Your complete step-by-step roadmap from idea to submission. Plan, code, test, and write with confidence.
π¦ What You Will Produce
- β A working program with clear purpose
- β Video demo showing input/output (typically ~1 minute)
- β Written responses explaining code, algorithm, and abstraction
- β Testing evidence with documented test cases
- β Properly acknowledged sources
The development process follows: \( \text{Plan} \rightarrow \text{Design} \rightarrow \text{Build} \rightarrow \text{Test} \rightarrow \text{Document} \)
π Your Progress
Step 1: Choose Your Idea & Purpose
Your program must have a clear purpose and solve a problem or provide value to a user.
π― Questions to Answer
- What problem does my program solve?
- Who is the intended user?
- What will users be able to do that they couldn't before?
- Is this achievable in the time I have?
β Step 1 Checklist
- I have a clear program idea
- I can state the purpose in one sentence
- I know who my target user is
- The scope is realistic for my timeline
Step 2: Plan Inputs, Outputs & User Interaction
Define how users interact with your program. Remember: \( f(\text{input}, \text{state}) \rightarrow \text{output} \)
π₯ Input Examples
- Text entered in fields (names, numbers, responses)
- Button clicks or menu selections
- File uploads or data from sensors
π€ Output Examples
- Calculated results displayed on screen
- Sorted/filtered lists
- Generated text, graphics, or sounds
β Step 2 Checklist
- I identified at least one form of user input
- I identified the program's output(s)
- I can explain how input affects output
- User interaction is intuitive
Step 3: Design Requirements & Decomposition
Break your program into smaller, manageable parts before coding.
π Requirements List
Write down WHAT your program must do:
- Must accept [specific input]
- Must store data in a list
- Must process data using [algorithm]
- Must display [specific output]
π§© Decomposition
Identify the procedures/functions you'll need:
- Input handler β gets data from user
- Processing procedure β your algorithm (must include sequencing, selection, iteration)
- Output display β shows results to user
- A clear name
- At least one parameter
- Sequencing (step-by-step instructions)
- Selection (if/else decisions)
- Iteration (a loop)
β Step 3 Checklist
- I wrote a requirements list
- I identified my main procedure
- My procedure has a parameter
- Algorithm includes sequence + selection + iteration
- I know what data my list will store
Step 4: Build Iteratively (Incremental Development)
Don't code everything at once! Follow: \( \text{Build} \rightarrow \text{Test} \rightarrow \text{Revise} \)
π¨ Incremental Strategy
- Start with core input/output β Get basic interaction working
- Add your list β Store and retrieve data
- Implement main procedure β Build your algorithm step by step
- Add remaining features β Polish and enhance
π Code While You Build
- Write comments explaining what each section does
- Use clear, descriptive variable names
- Test after adding each feature
β Step 4 Checklist
- Basic input/output works
- List is implemented and used meaningfully
- Main procedure is complete with parameter
- Procedure includes sequence + selection + iteration
- Code is commented
- I saved backup versions
Step 5: Test & Debug (Evidence)
Systematic testing catches errors and provides evidence for your write-up.
π§ͺ Create Test Cases
| Test Type | Example |
|---|---|
| Typical input | Age: 25, Score: 85 |
| Minimum boundary | Age: 0, Score: 0 |
| Maximum boundary | Age: 120, Score: 100 |
| Just beyond min | Age: -1 (invalid) |
| Just beyond max | Age: 121 (invalid) |
π Debugging Methods
- Print statements β Output variable values at key points
- Hand tracing β Step through code on paper with sample inputs
- Debugger tools β Use breakpoints to inspect state
- Isolate the problem β Comment out sections to find the bug
β Step 5 Checklist
- Tested with typical inputs
- Tested boundary cases (min/max)
- Tested edge cases beyond boundaries
- Fixed syntax errors (program runs)
- Fixed logic errors (output is correct)
- Documented test results
Step 6: Document & Acknowledge Sources
Proper documentation makes your code understandable and credits others appropriately.
π¬ What to Comment
- What each major section or function does
- Why you made key design decisions
- Any complex algorithms explained simply
- What parameters mean and return values represent
π Acknowledging Sources
If you used any code from:
- Online tutorials
- Stack Overflow or forums
- Classmates or teachers
- Libraries or frameworks
You MUST acknowledge the source β include origin, author if known, and what you used.
β Step 6 Checklist
- Code has comments explaining key parts
- All external code is acknowledged
- My main procedure is my original work
- Variable/function names are descriptive
Step 7: Write the Responses
Your written responses explain your program clearly and demonstrate understanding.
π Typical Response Areas
- Purpose β What does your program do and for whom?
- Input/Output β What input does it take? What output does it produce?
- List Usage β What data does your list store? How is it used?
- Procedure/Algorithm β What does your procedure do? Explain the algorithm step by step.
- Abstraction β How does your procedure help manage complexity?
- Testing β What inputs did you test? What were the results?
- Be specific, not vague
- Use the actual names of your variables/functions
- Explain the WHAT and HOW, not just that it works
- Keep sentences clear and direct
π οΈ Draft Write-Up Template Builder
β Step 7 Checklist
- Purpose is clearly stated
- Input and output are explained
- List usage is described
- Algorithm is explained step by step
- Abstraction/procedure purpose is explained
- Testing evidence is documented
Step 8: Final Submission Checklist
Before submitting, verify everything is complete and correct.
πΉ Video Checklist
- Video shows program receiving input
- Video shows program running
- Video shows output being produced
- Video is within typical length guidelines
- No audio/narration required (typically)
π» Code Checklist
- Program runs without errors
- List is used meaningfully
- Student-developed procedure exists
- Procedure has at least one parameter
- Procedure includes sequencing + selection + iteration
- Code is commented
- Sources are acknowledged
π Written Response Checklist
- All required questions answered
- Responses are clear and specific
- Within any word/character limits
π‘ Real Classroom Examples
Example 1: Quiz Score Tracker
Purpose: Helps students track quiz scores and see progress.
Input: User enters quiz name and score.
List: Stores all quiz scores.
Algorithm: calculateAverage(scores) loops through list, sums scores, divides by count.
Output: Displays average, highest, lowest scores.
Example 2: Vocabulary Flashcard App
Purpose: Helps users learn new words through flashcards.
Input: User adds words/definitions, clicks to reveal.
List: Stores word-definition pairs.
Algorithm: shuffleCards(deck) randomizes order; checkAnswer(guess, correct) compares input to answer.
Output: Shows flashcard, reveals definition, tracks correct count.
Example 3: Simple To-Do List
Purpose: Helps users organize tasks.
Input: User types task, clicks add/complete/delete.
List: Stores all tasks with completion status.
Algorithm: filterTasks(taskList, status) loops through, selects matching status, returns filtered list.
Output: Displays tasks, shows completed count, allows filtering.
β οΈ Common Mistakes That Cost Clarity
- Vague purpose statement β "My program does stuff" vs. "My program calculates..."
- Not using the list meaningfully β Just having a list isn't enough; you must process it
- Procedure without a parameter β Your procedure MUST take at least one parameter
- Missing selection OR iteration β Algorithm needs BOTH if/else AND loops
- Not explaining HOW the algorithm works β Step-by-step, not just what it does
- Forgetting to acknowledge sources β Credit ALL external code
- Video doesn't show input AND output β Must demonstrate both
- No testing evidence β Document what you tested and results
- Confusing procedure name with algorithm explanation β Explain the LOGIC, not just the name
- Submitting with syntax errors β Program must run; test before submitting
π©βπ« What Reviewers Look For (Teacher Checklist)
- β Clear, specific purpose statement
- β Program runs without crashing
- β Input and output clearly demonstrated
- β List is used and its purpose is explained
- β Procedure has name, parameter(s), and is called
- β Algorithm includes sequencing + selection + iteration
- β Algorithm explanation is step-by-step and specific
- β Abstraction is explained (how procedure manages complexity)
- β Testing evidence with specific inputs and outputs
- β All external code is acknowledged
β Frequently Asked Questions
π About This Guide
Created by NUM8ERS Institute & Education LLC Dubai to help AP CSP students succeed on the Create Performance Task. Our materials align with typical AP CSP expectations and best practices.