What Does an Operating System Actually Do? (A High School Notes + Discussion Lesson)

At a Glance

Lesson Plan Notes What Does an Operating System Actually Do? (A High School Notes + Discussion Lesson)

This lesson wasn’t my favorite to teach because I didn’t have much “hands-on” time to show how operating systems work, beyond using applications built into the operating systems on students’ personal devices and school computers. Often, school computers block system-level software for students, so it’s easier for students to learn by interacting with their own phones. For Intro to Software Tech, I really didn’t need to go much deeper than giving students a high-level familiarity of what an operating system is and some examples. I didn’t use this worksheet in my class, but I did something similar with slides and notes. The goal of this lesson is to show that the operating system bridges hardware and software and enables them to communicate.

How I taught operating systems

Students interact with operating systems constantly but rarely think about what one actually does—tying the concept to a device they already own (their phone, their laptop) makes an abstract “traffic cop” idea concrete fast. Students often don’t realize that brand names like Android and iOS are actually operating system names. High school students have smartphones that require upgrades. I like to open with a quick poll.

• “How many of you have a smartphone?”
• “Who has an iPhone?”
• “Who has an Android device?”
• “How about a Windows phone?”

Definitely allow the banter and back-and-forth about the phones they have; it keeps things light and holds student interest. Talk about how you can tell the difference in an operating system from the design. You may be using the same app, but it looks a little different on an iPhone vs. an Android. That said, the operating system is more than design choices. Operating systems may be written in different programming languages across brands, each with its own pros and cons.

At the risk of distraction, ask them to take out their phones and go to “Settings” to see what OS versions they’re running. Acknowledge that their operating systems are always upgrading, and that this is different from the phone versions that marketers promote, and the OS is required for the many apps (applications) on their phones to work properly. Tell them that when they use applications on a phone or a computer, they automatically use the operating system the app depends on.

Keep the momentum going as you talk through the worksheet using common scenarios like turning on your phone, using an application, monitoring your activity on your computer (or screen time on iOS), to help students understand that they are constantly interacting with the operating system or software that is built directly into the operating system. Letting students view the activity monitor on their computers or personal devices gives them ownership of their learning and creates memories that stick beyond simply copying notes. Though this can distract some students. But if you make it clear that this lesson involves interacting with your device and that you’re counting on them to stay on task and keep taking notes, it can work. You know your students best, though. If you need to make screenshots and display them in slides instead, do that.

Again, this is deliberately the lightest-touch lesson in the unit — high-level conceptual understanding and vocabulary, not OS internals. That’s a scope decision, not a shortcut: deep technical mechanics would be a poor fit for where this unit is going. In my class, this came after the Components lesson, the IPOS-C Flow lesson, and the Maze retrieval-practice activity — it’s the first genuinely new content since the maze, shifting students from hardware to the software layer running on top of it.

What this lesson actually is

1. As mentioned before, I introduce the OS as the “traffic cop” that lets hardware and software talk to each other.
2. Then it covers the major operating systems (device-to-OS matching) plus BIOS/firmware (what loads before the OS) and the monitoring tools every OS ships with (Task Manager on Windows, Activity Monitor on Mac).
3. After that, we move to applications—desktop, smartphone, web, and cloud-based—with students supplying their own real examples, then connect that to why a developer has to care which OS they’re building for.
4. Next is a genuine step toward “real” computer science — bits, bytes, and the high-level-vs-low-level distinction, including naming (not performing) the compiler/interpreter translation step.
5. Finally, it closes with quick questions asking students to determine whether the described functionality is from the Operating System or an App.

Teachers need to keep the conversation flowing throughout as students fill the notes. Creating complementary slides that suit your class, plus examples for them to try on their phones or other devices, is key.

Why grounding this in students’ own devices matters

The single biggest risk with this topic is that it’s abstract and easy to zone out on — there’s no physical component to point to like earlier lessons in the unit. But anchoring every new idea to a device a student already owns (their phone, their laptop) is what keeps “operating system” from staying a vocabulary word with no real referent. The same approach extends to BIOS/firmware and bits/bytes — rather than teaching these as isolated trivia, they’re framed as “what’s happening on the device in your pocket right now, underneath the apps you already use. The note-taking worksheet itself is part of the design, not just a record of the lecture — giving students something concrete to do with their hands throughout a conceptually heavy lesson. Remembering that if it helps you connect the dots to the lesson, it will probably help the students, and that’s why I stand by allowing students to explore operating systems via their personal devices.

What I look for when I grade it

This is a pretty easy grade because you can see at a glance whether students filled in the notes. See my straightforward breakdown below.

• Notes Completeness (10 pts) - all six note-taking sections filled in across the 5 pages.
• Device↔OS Matching (5 pts) - all 5 pairings correct.
• BIOS/Firmware & Monitoring Notes (10 pts) - definitions in the student’s own words, roughly accurate, plus both OS-to-monitoring-tool pairings correct.
• App Category Examples (5 pts) -one accurate real-world example per category.
• Bits/Bytes & High-/Low-Level Notes (10 pts) -definitions given, 8-bits-per-byte recalled, and the missing translation step correctly named (compiler or interpreter).
• OS vs. App Sort (10 pts)- all 8 items correctly classified.

I treat this as practice/formative: low-stakes completion plus accuracy, consistent with this lesson’s high-level, vocabulary-first intent rather than deep mastery.