CSTA 2017 Standards Reference
#AP Algorithms & Programming
#2-AP-10
A problem too complex to solve on the spot can still be organized into an algorithm using a flowchart or pseudocode, even before any real code gets written.
#2-AP-11
A variable is a named container whose contents can change, and naming it clearly is what makes the operations you perform on it make sense later.
#2-AP-12
Nesting loops inside each other, or combining conditions with AND/OR/NOT, lets a program handle situations a single loop or single condition never could, and getting there takes iteration, not one pass.
#2-AP-13
Breaking a problem into subproblems, and those into still smaller parts, is what lets a team, or just one person, focus on one piece of a program at a time.
#2-AP-14
A procedure that repeats the same instructions can be generalized with a parameter, so one instruction like "drawCircle" can produce circles of any size instead of just one.
#2-AP-15
A program only ends up meeting user needs if you actually go get feedback from teammates and users along the way and let it change your design.
#2-AP-16
Building on someone else's code, image, or library is a normal part of making something more interesting, as long as you credit where each piece came from.
#2-AP-17
Testing a program well means deliberately trying inputs you expect to break it, like zero or a negative number, not just the input you expect to work.
#2-AP-18
A team project runs on assigned roles and a shared timeline, not just everyone quietly working on whatever part they feel like.
#2-AP-19
Documentation, like a project overview or comments in the code, is what lets someone else actually follow, test, and debug a program you wrote.
#3A-AP-13
Building a prototype around a problem that actually interests you is a legitimate way to practice applying an algorithm, not just a classroom exercise.
#3A-AP-14
When several near-identical variables start to pile up, a list lets you generalize the pattern instead of repeating nearly the same code for each one.
#3A-AP-15
Picking one control structure over another, like a loop instead of recursion, is a real design decision with tradeoffs in readability and performance that you should be able to defend.
#3A-AP-16
An event, like a button press or a location change, can trigger a procedure, which is how real apps built for a practical purpose or a social issue actually respond to their users.
#3A-AP-17
Breaking a hard problem down systematically, into procedures, modules, or objects, is what makes it possible to reuse pieces that already exist instead of solving everything from scratch.
#3A-AP-18
A complex artifact is usually a system of smaller interacting pieces, whether that's procedures inside one program or several programs that work together, each with its own role.
#3A-AP-19
Designing for a broad audience means building in a systematic way to actually collect feedback from a range of users, then revising based on what you hear.
#3A-AP-20
Before you build on someone else's library, its license is worth reading closely, since different licenses restrict what you're allowed to do with the result in different ways.
#3A-AP-21
Testing and refining a program isn't just about fixing bugs, it's also the process that makes it more usable and accessible to the people who'll actually use it.
#3A-AP-22
Building something as a team means taking on a specific role and using real collaborative tools, like shared code or shared documents, not just splitting up the work informally.
#3A-AP-23
A complex program's design decisions need to be documented somehow, whether that's written notes, diagrams, a presentation, or a live demonstration, so the reasoning survives past the moment you made the choice.
#3B-AP-08
Level 3B: elective/specialty, not required of all students.
Artificial intelligence is already quietly running things like ad delivery, self-driving cars, and fraud detection, and it's worth being able to name where it shows up.
#3B-AP-09
Level 3B: elective/specialty, not required of all students.
Building even a simple AI algorithm, enough to play tic-tac-toe or guess a number, is a concrete way to understand what "artificial intelligence" actually means underneath the term.
#3B-AP-10
Level 3B: elective/specialty, not required of all students.
Classic algorithms like sorting and searching aren't just theory, adapting one to fit your actual problem is a normal, practical move.
#3B-AP-11
Level 3B: elective/specialty, not required of all students.
Comparing two algorithms for the same job means weighing all three of efficiency, correctness, and clarity, not just whichever one runs first.
#3B-AP-12
Level 3B: elective/specialty, not required of all students.
Fundamental data structures, strings, lists, stacks, queues, each fit some problems better than others, and choosing between them is a real design decision.
#3B-AP-13
Level 3B: elective/specialty, not required of all students.
Tracing exactly how a recursive algorithm calls itself and unwinds is what actually makes recursion click, more than just reading the definition.
#3B-AP-14
Level 3B: elective/specialty, not required of all students.
At this level you're expected to build your own components, procedures, modules, or objects, rather than only using ones handed to you.
#3B-AP-15
Level 3B: elective/specialty, not required of all students.
A large, messy problem usually contains a smaller generalizable pattern, and finding it is what makes the problem solvable at all.
#3B-AP-16
Level 3B: elective/specialty, not required of all students.
Reaching for an existing library or API instead of rebuilding it yourself is a normal, expected way to solve a problem, not a shortcut to avoid.
#3B-AP-17
Level 3B: elective/specialty, not required of all students.
Building software for a real audience benefits from following an actual life cycle process, like agile, spiral, or waterfall, rather than just starting to code.
#3B-AP-18
Level 3B: elective/specialty, not required of all students.
Common weaknesses like missing bounds checks or weak input validation are exactly the kind of thing that turns an ordinary program into a compromised one.
#3B-AP-19
Level 3B: elective/specialty, not required of all students.
The same program idea often needs real changes to run correctly across different platforms, like desktop, web, and mobile.
#3B-AP-20
Level 3B: elective/specialty, not required of all students.
A group software project runs on real tooling, version control, an IDE, and documented code, not just splitting up files and hoping they merge.
#3B-AP-21
Level 3B: elective/specialty, not required of all students.
Verifying a program against its own design spec means writing your own deliberate series of test cases, not just running it once and eyeballing the result.
#3B-AP-22
Level 3B: elective/specialty, not required of all students.
Adding a feature to existing code can quietly break something else that depended on the old behavior, and that unintended consequence is worth discussing, not just the intended one.
#3B-AP-23
Level 3B: elective/specialty, not required of all students.
A code review is where qualities like correctness, readability, and scalability actually get evaluated, not just assumed because the program runs.
#3B-AP-24
Level 3B: elective/specialty, not required of all students.
Different programming languages, block-based versus text, high-level versus low-level, genuinely suit different kinds of problems, and that's a real basis for choosing one.
#CS Computing Systems
#2-CS-01
Watching how people actually use a device, like a laptop or a controller you design yourself, is what turns "this feels clunky" into a specific, arguable improvement.
#2-CS-02
A project that collects and exchanges data needs hardware and software chosen together, weighing things like cost, size, speed, and how the pieces will actually connect.
#2-CS-03
A broken device might be failing because of something connected to it, not the device itself, so troubleshooting needs a structured process, not a guess.
#3A-CS-01
Devices you use every day, like a car stereo or a medical monitor, hide the implementation details behind a simpler interface, and you can reason about one without needing to understand the other.
#3A-CS-02
A computer's software stacks in layers, from the app you're using down through the operating system to the physical hardware, and each layer only needs to talk to the ones right next to it.
#3A-CS-03
Troubleshooting a hard problem is itself a skill worth writing down, so someone else can follow the same systematic process instead of guessing.
#3B-CS-01
Level 3B: elective/specialty, not required of all students.
An operating system juggles several distinct jobs at once, like memory management, storage, running processes, and access control, and it helps to be able to name which job is which.
#3B-CS-02
Level 3B: elective/specialty, not required of all students.
Logic, input, and output aren't abstract ideas, they're implemented in real hardware components like logic gates and I/O pins, and you can trace how.
#DA Data & Analysis
#2-DA-07
The exact same piece of data, like a color, can be written down as binary, as an RGB value, as a hex code, or in plain words, and switching between those representations is a skill in itself.
#2-DA-08
Data collected with a computational tool is rarely ready to use as-is; cleaning it up, like removing irrelevant responses from a survey, is what makes it actually useful and reliable.
#2-DA-09
A computational model gets better by comparing what it predicted against what actually happened, then adjusting the model based on that gap.
#3A-DA-09
The same real-world thing, a letter, a number, a color, can be represented in more than one bit-level encoding, and you should be able to convert between them.
#3A-DA-10
Where and how you store data, like locally versus in the cloud, involves real tradeoffs in cost, speed, and privacy, not just a technical preference.
#3A-DA-11
A good interactive visualization, built with the right software tool, can make a real-world pattern clear to someone who'd never see it in a raw data table.
#3A-DA-12
A computational model built from real data can capture how its pieces actually relate to each other, then be tested against more data to see if it holds up.
#3B-DA-05
Level 3B: elective/specialty, not required of all students.
The right data analysis tool can surface a real pattern, like a trend in social media activity or shopping behavior, that's invisible in the raw numbers.
#3B-DA-06
Level 3B: elective/specialty, not required of all students.
Which data collection tool or technique you choose should be driven by the claim you're trying to support, not picked out of convenience.
#3B-DA-07
Level 3B: elective/specialty, not required of all students.
A model or simulation is only useful for testing a hypothesis if you can actually judge how well it does that job, which is its own skill.
#IC Impacts of Computing
#2-IC-20
A new computing technology, like a driverless car, is never purely good or purely bad for daily life and careers, and naming the actual tradeoff is the point.
#2-IC-21
A technology tested mostly on one kind of user, like facial recognition trained on lighter skin tones, can end up biased or inaccessible in ways worth discussing directly, not glossing over.
#2-IC-22
Gathering ideas or content from a large group, whether that's a classroom or an online community, is a real strategy for building something, not a shortcut around real collaboration.
#2-IC-23
Sharing information publicly can build an audience or a reputation, but it also opens the door to the kind of personal information that makes social engineering attacks work, and weighing that tradeoff is the actual skill.
#3A-IC-24
Computing doesn't just change what's technically possible, it reshapes personal, ethical, social, economic, and cultural practices, and those effects are worth evaluating directly.
#3A-IC-25
An artifact can carry bias or leave some users out without anyone intending it, which is why testing specifically for that and refining the design is its own step.
#3A-IC-26
The same algorithm can often solve problems in more than one field, and showing that connection is part of understanding what the algorithm actually does.
#3A-IC-27
The right collaboration tools can connect a project team across cultures and career fields that would otherwise never cross paths.
#3A-IC-28
Intellectual property law cuts both ways: it can protect a creator's incentive to innovate, and it can also be used to block others from building on that work.
#3A-IC-29
A lot of data gets collected automatically, without a user ever noticing, which raises privacy concerns that are easy to miss if you only think about the data you knowingly hand over.
#3A-IC-30
Privacy isn't just a personal preference, it has social and economic consequences that show up in debates over safety, law, and ethics.
#3B-IC-25
Level 3B: elective/specialty, not required of all students.
Building something isn't neutral, and evaluating it for both its benefits and its potential harms to society is part of finishing the job.
#3B-IC-26
Level 3B: elective/specialty, not required of all students.
Who actually gets access to computing resources worldwide is shaped by equity and influence, not just availability, and that unevenness has real consequences.
#3B-IC-27
Level 3B: elective/specialty, not required of all students.
Looking at how computing has already reshaped a field, like healthcare or entertainment, is a reasonable basis for predicting where it goes next.
#3B-IC-28
Level 3B: elective/specialty, not required of all students.
Laws and regulations around software aren't settled facts, they're genuinely debatable, and forming a position on one is part of understanding it.
#NI Networks & the Internet
#2-NI-04
Protocols are the rules that decide how a message actually gets across a network quickly, correctly, and with errors handled, and modeling that role is different from just naming the protocol.
#2-NI-05
Keeping electronic information safe takes both physical safeguards, like locked doors, and digital ones, like firewalls and HTTPS, and explaining how each actually protects the data is the point.
#2-NI-06
Trying out more than one encryption method yourself, from a simple letter-substitution cipher up to modeling public-key encryption, is how the idea of "securing a message" stops being abstract.
#3A-NI-04
How well a network scales and holds up depends on how its routers, switches, servers, layout, and addressing all work together, not any one piece alone.
#3A-NI-05
Real attacks like ransomware or phishing show concretely how sensitive data can be exposed or destroyed, which is why studying actual incidents teaches more than an abstract warning.
#3A-NI-06
Choosing a security measure for a given situation means weighing more than just how well it works -- its efficiency, feasibility, and ethical impact matter too.
#3A-NI-07
Tighter security almost always costs something in usability, and picking a security measure means being honest about that tradeoff.
#3A-NI-08
Every cybersecurity recommendation trades something away, and justifying a choice means being able to explain that tradeoff to whoever has to live with it.
#3B-NI-03
Level 3B: elective/specialty, not required of all students.
A network's real-world performance comes down to concrete factors like bandwidth, load, delay, and topology, and a network simulator is a reasonable way to see how each one bites.
#3B-NI-04
Level 3B: elective/specialty, not required of all students.
Developers protect a system from unauthorized access with several different tools working together -- encryption, authentication, secure coding, key management -- and each has its own strengths.