Teaching computational problem design in grades 11-12 (level 2) does not have to be complicated. Picture a software architect designing one shared scheduling component instead of separate systems for classes, clubs, and practices. That kind of thinking is exactly what Oklahoma's grades 11-12 (level 2) computer science standard L2.AP.M.02 asks students to practice \u2014 and it is very teachable with the right materials. This post walks through what the standard means, the misconceptions students bring to it, and discussion starters you can use tomorrow, whether you teach in a classroom or at your kitchen table.<\/p>\n
\nDesign or redesign a solution to a large-scale computational problem by identifying generalizable patterns.\n\u2014 Oklahoma Academic Standards for Computer Science (February 2023)<\/em><\/p>\n<\/blockquote>\n
In plain language: This standard asks students to look at a large, many-part problem and figure out what stays the same across all its cases, then design (or redesign) one solution built around that shared pattern instead of solving each case separately.<\/p>\n
In student-friendly terms, the learning target is: "I can design, or redesign, a solution to a large-scale computational problem by identifying the generalizable pattern that a whole family of related cases shares, rather than solving each case separately."<\/strong><\/p>\n
What Students Should Be Able to Do<\/h2>\n
\n
- I can compare multiple related problem cases and sort their requirements into what stays the same and what varies.<\/li>\n
- I can design a component-based solution, with a clear interface, that scales to handle new cases fitting an identified pattern.<\/li>\n
- I can redesign an existing one-off solution into a generalized one and explain what limitation the redesign fixes.<\/li>\n
- I can explain the risk of overgeneralizing a design that does not actually need to scale.<\/li>\n<\/ul>\n
Along the way, students pick up the working vocabulary of the topic: generalization, abstraction, pattern, scalability, redesign, component, interface, duplication, maintainability, modularity, overgeneralization, efficiency, requirement, edgecase.<\/p>\n
Computational Problem Design: Misconceptions to Watch For<\/h2>\n
These are the wrong turns students reliably take with this standard \u2014 knowing them ahead of time is half the lesson plan. Each correction strategy below comes straight from the unit's teacher guide (the paragraph and activity references point into the unit itself).<\/p>\n
1. "If a solution works correctly for the case in front of you, there is no reason to design for other cases."<\/strong><\/p>\n
Return to paragraph 1's distinction between a one-off solution and a large-scale problem. Ask students to predict what happens to a working one-off solution once five more similar cases appear, and connect it to paragraph 4's discussion of duplication.<\/p>\n
2. "Generalizing a design just means making it as flexible and configurable as possible."<\/strong><\/p>\n
Revisit paragraph 6's discussion of overgeneralization. Have students identify the actual expected number and variety of cases before deciding how much flexibility a design truly needs.<\/p>\n
3. "Copying and slightly modifying existing code for a new, similar case is the same thing as generalizing a design."<\/strong><\/p>\n
Use the report-function example from the constructed response items. Show that copying code creates duplication, which is the opposite of generalization \u2014 a truly generalized design reuses one component instead of creating a new near-identical copy.<\/p>\n
4. "Redesigning an existing solution means throwing it away and starting over from nothing."<\/strong><\/p>\n
Connect to paragraph 9's discussion of redesign. Emphasize that a redesign must first identify which existing behaviors are essential and preserve them, then rebuild around the identified pattern \u2014 not discard the working solution's requirements.<\/p>\n
Discussion Starters You Can Use Tomorrow<\/h2>\n
\n
- Why might it be worth spending extra design time up front on a generalized solution, even when a quick one-off fix would technically work today?<\/li>\n
- Describe a real system you use that clearly handles many different but related cases with one underlying design. What do you think its generalizable pattern is?<\/li>\n
- How would you decide whether a new problem you are facing is genuinely large-scale, or whether it is truly a one-time, narrow case that does not need a generalized design?<\/li>\n<\/ul>\n
Bringing It Home<\/h2>\n
This topic is a natural one for families. One ten-minute activity to try: Together, pick something at home that currently gets handled a different way every time it comes up (packing different kinds of lunches, organizing different types of mail, planning different weekend activities) and have your student design one simple system that could handle every version of it. There are no wrong answers \u2014 the goal is hearing their reasoning about what pattern they found.<\/p>\n
Where This Leads<\/h2>\n
Students who can design, or redesign, a solution to a large-scale computational problem by identifying the generalizable pattern that a whole family of related cases shares, rather than solving each case separately are building skills used every day in software architecture, software engineering, UX \/ product engineering, data \/ machine learning engineering, and computer science education.<\/p>\n\n
See the Unit in Action<\/h2>\n\n