Teaching Building Software Solutions in Grades 9-10 (Level 1): Oklahoma Standard L1.AP.PD.01

Teaching software development process in grades 9-10 (level 1) does not have to be complicated. Picture a UX designer interviewing several types of hospital staff before designing a scheduling app. That kind of thinking is exactly what Oklahoma's grades 9-10 (level 1) computer science standard L1.AP.PD.01 asks students to practice — 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.

What Does Standard L1.AP.PD.01 Actually Ask?

Create software that will provide solutions to a variety of users using a software development process. — Oklahoma Academic Standards for Computer Science (February 2023)

In plain language: This standard asks Level 1 students (grades 9-10) to create software that solves a real problem for a variety of users, using a software development process — gathering what different users need, designing a solution, building it, and testing whether it actually works.

In student-friendly terms, the learning target is: "I can create software that provides a solution for a variety of users by working through a software development process, and explain how each phase shaped the final result."

What Students Should Be Able to Do

• I can name the phases of a software development process and describe what happens in each one.
• I can gather requirements from more than one type of user and explain how their needs differ.
• I can turn requirements into a design and explain a design decision that serves a specific user's needs.
• I can describe how testing and feedback lead a team back into another iteration of the process.

Along the way, students pick up the working vocabulary of the topic: software, requirement, design, prototype, coding, testing, debugging, deployment, update, iteration, stakeholder, usability, feedback, interface.

Software Development Process: Misconceptions to Watch For

These are the wrong turns students reliably take with this standard — 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).

1. "Software development means writing code, and the other phases are optional extras."

Return to paragraph 2. A team that skips requirements or design and jumps straight to code often builds something that works technically but fails the users it was meant to serve.

2. "Once software is tested and it runs without crashing, the process is complete."

Point back to paragraph 5's distinction between technical testing and usability testing. Software can pass every technical test and still confuse or exclude real users.

3. "All users of a piece of software need the same thing from it."

Revisit paragraph 7's discussion of accessibility and varied stakeholder needs. A solution built for one type of user can genuinely fail another type of user, even if it works perfectly for its designers.

4. "Once software is deployed, the project is finished."

Emphasize paragraph 6: deployment exposes software to a larger, more varied group of real users, and maintenance and further iteration almost always follow.

Discussion Starters You Can Use Tomorrow

• Think of a piece of software you use daily. Which phase of the process — requirements, design, implementation, testing, or deployment/maintenance — do you think its creators spent the most time on, and why?
• Why might a team deliberately test software with people very different from the development team, instead of only testing it themselves?
• Describe a real-world example where skipping the requirements phase would waste significant time and effort, even if the implementation phase were done perfectly.

Bringing It Home

This topic is a natural one for families. One ten-minute activity to try: Together, pick an app or website your family uses often. Ask your student to imagine they are on the team that built it: who are two different kinds of people who use it, and what might each of them need from it that's different from what your family needs? There are no wrong answers — the goal is hearing their reasoning about different users.

Where This Leads

Students who can create software that provides a solution for a variety of users by working through a software development process, and explain how each phase shaped the final result are building skills used every day in software engineering, UX / product design, quality assurance, and project management.

See the Unit in Action

Get the Complete L1.AP.PD.01 Unit

I built a complete, no-prep unit for this standard — Building Software Solutions: The Software Development Process — covering 3-4 days of instruction across 43 pages:

• Teacher guide — day-by-day pacing, misconceptions to watch for, discussion questions, differentiation for support / ELL / extension, and a 4-point rubric
• Student learning target page — a kid-friendly "I can" statement with success criteria
• Full content lesson with 3 embedded "Check Your Understanding" checkpoints
• 12-question assessment (6 multiple choice, 4 true/false, 2 short answer) with a complete answer key, explanations, and exemplar responses
• Group activity — "Prototype a Solution: The Software Development Process Challenge" (25-30 minutes)
• Individual activity — "My Software Development Process Log" (20 minutes)
• Crossword and word search built from all 14 vocabulary terms (with answer keys)
• Family connection letter — a plain-language page for parents, with dinner-table questions and a 10-minute home activity
• Certificate of achievement — ready to sign and send home
• User Persona Card Set: Prototype a Solution (separate printable, 2 pages)
• Reference Sheet: The Software Development Process (separate printable, 2 pages)
• My Software Development Process Log (separate printable, 2 pages)

Get Building Software Solutions on Teachers Pay Teachers →

Also aligned to CSTA 3B-AP-16: Use a software life cycle model to plan and organize the design, development, and testing of a software artifact.

Every Sooner Standards resource is built directly from the official Oklahoma Academic Standards for Computer Science (February 2023) — standard text verified, never paraphrased from memory.