Computer Science · 11th Grade

Active learning ideas

Introduction to Software Development Lifecycle (SDLC)

Active learning works because students need to *feel* the friction of skipping steps or misaligned communication, just as real software teams do. By role-playing phases or comparing models through games, they connect abstract concepts to tangible consequences like delayed deadlines or buggy code.

• Common Core State Standards
• CSTA: 3B-AP-18

• 35–60 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Concept Mapping
• 45 min · Small Groups

Role-Play: SDLC Phases Simulation

Assign groups roles like analyst, designer, coder, tester. Provide a project brief for a school event app. Groups cycle through phases in 5-minute intervals, documenting decisions and passing artifacts. Debrief on phase dependencies.

Explain the different phases of the Software Development Lifecycle (SDLC).

Facilitation Tip

During the Role-Play: SDLC Phases Simulation, assign roles like project manager or tester so students experience delays when requirements change mid-phase.

What to look for

Present students with a scenario describing a software project (e.g., a simple mobile game, a school event registration app). Ask them to list the key activities they would perform in the Requirements Analysis and Design phases for this project.

• Understand
• Analyze
• Create
• Self-Awareness
• Self-Management

Activity 02

• Concept Mapping
• 50 min · Pairs

Model Comparison: Waterfall vs Agile Board Game

Create game boards showing project milestones. In Waterfall path, teams move sequentially but risk backtracking on changes. Agile path allows sprints with feedback cards. Play twice, track completion time and quality scores.

Analyze the importance of each phase in delivering a successful software product.

Facilitation Tip

For the Waterfall vs Agile Board Game, provide a one-page cheat sheet of rules and SDLC definitions to reference during play.

What to look for

Facilitate a class discussion: 'Imagine a project where the client keeps changing their mind about features halfway through development. Which SDLC model, Waterfall or Agile, would be more suitable and why? What are the potential risks of using the other model in this situation?'

• Understand
• Analyze
• Create
• Self-Awareness
• Self-Management

Activity 03

• Case Study Analysis
• 35 min · Small Groups

Case Study Analysis: Real-World SDLC Analysis

Distribute articles on software failures like a banking app glitch. Students map events to SDLC phases in a graphic organizer, identify missed steps, and propose fixes using Agile principles. Share findings class-wide.

Differentiate between various SDLC models (e.g., Waterfall, Agile).

Facilitation Tip

In the Case Study: Real-World SDLC Analysis, give each group a printout of a flawed app (e.g., TikTok’s early privacy issues) to trace back to skipped phases.

What to look for

Have students, in small groups, outline a basic SDLC plan for a hypothetical app. They then exchange plans. Each group reviews another's plan, answering: 'Are all core SDLC phases included? Is the chosen model (Waterfall/Agile) appropriate for the described project? Provide one suggestion for improvement.'

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 04

• Concept Mapping
• 60 min · Small Groups

Mini-Project: Agile Sprint Planning

Teams plan a 2-week sprint for a basic web tool using sticky notes on a board: backlog, tasks, daily stand-ups. Implement one feature, demo, and retrospect. Adjust for next sprint based on feedback.

Explain the different phases of the Software Development Lifecycle (SDLC).

Facilitation Tip

For the Mini-Project: Agile Sprint Planning, use a timer for 10-minute sprints so students feel the pressure of time-boxed work.

What to look for

Present students with a scenario describing a software project (e.g., a simple mobile game, a school event registration app). Ask them to list the key activities they would perform in the Requirements Analysis and Design phases for this project.

• Understand
• Analyze
• Create
• Self-Awareness
• Self-Management

A few notes on teaching this unit

Teachers should avoid lecturing the phases in order, as students need to *discover* the pain points themselves. Start with a relatable problem—like a broken school app—then let them map it to SDLC phases. Emphasize that documentation isn’t busywork; it’s the team’s memory. Research shows that analog simulations stick longer than slides, so prioritize tactile or visual activities over abstract discussions.

Successful learning looks like students confidently articulating why a phase matters, selecting the right model for a scenario, and critiquing their own or peers’ work against SDLC criteria. They should also recognize when shortcuts lead to problems in prototypes or plans.

---

Watch Out for These Misconceptions

• During the Role-Play: SDLC Phases Simulation, some students may assume SDLC only applies to large teams.

  During the simulation, assign small student projects (e.g., a class attendance app) and have teams present how SDLC phases helped them manage scope. Ask peers to identify which phase caught a critical error early.

• During the Mini-Project: Agile Sprint Planning, students might think Agile lacks structure.

  Use the sprint review board to show how Agile relies on backlog grooming and daily stand-ups. Point to the printed user stories and acceptance criteria as evidence of continuous planning.

• During the Model Comparison: Waterfall vs Agile Board Game, students may overgeneralize that Waterfall is always slower.

  After the game, display the results on a whiteboard and ask teams to compare turn-based (Waterfall) vs iterative (Agile) progress. Highlight scenarios where Waterfall was faster due to clear requirements.

---

Methods used in this brief

• Concept Mapping
• Case Study Analysis