Capstone Software Development: Final Project Presentation

Active learning works for Capstone Software Development because students need to practice explaining technical work to real audiences, not just peers. These activities move students from private reflection to public presentation, mirroring the collaborative and communicative demands of professional software development.

• Grade 11
• Computer Science
• 4 activities
• 30 min–45 min

Learning Objectives

1. Synthesize project outcomes and technical details into a coherent presentation for diverse audiences.
2. Evaluate the effectiveness of different communication strategies in conveying software value to stakeholders.
3. Critique the design choices and implementation of a specific software feature, identifying reasons for its success or failure.
4. Analyze the role of technical documentation in facilitating future software maintenance and updates.

Expert Panel

⏱ 45 min·Pairs

Pecha Kucha Rehearsal: Project Highlights

Students prepare 20 slides, 20 seconds each, covering problem, solution, failures, and impact. Pairs time each other, noting jargon use and clarity. Groups share one slide for class feedback.

Prepare & details

How do we effectively demonstrate the value of a technical solution to a user?

Facilitation Tip: During Pecha Kucha Rehearsal, set a timer for each slide transition to keep student presentations disciplined and focused on key highlights.

Setup: Panel table at front, audience seating for class

Materials: Expert research packets, Name placards for panelists, Question preparation worksheet for audience

• Understand
• Apply
• Analyze
• Evaluate
• Self-Management
• Relationship Skills

Expert Panel

⏱ 35 min·Small Groups

Audience Switch: Dual Presentations

Individuals present 3-minute pitches to small groups acting as executives, then developers. Switch roles after first round. Debrief on adaptations made for each audience.

Prepare & details

What are the most important lessons learned from the failure of a specific feature?

Facilitation Tip: For Audience Switch, assign one student to play the technical audience and another the non-technical audience so students must adapt responses in real time.

Setup: Panel table at front, audience seating for class

Materials: Expert research packets, Name placards for panelists, Question preparation worksheet for audience

• Understand
• Apply
• Analyze
• Evaluate
• Self-Management
• Relationship Skills

Expert Panel

⏱ 30 min·Whole Class

Failure Story Circle: Lessons Shared

In a circle, each student shares one failed feature, its cause, and fix via documentation. Class votes on clearest story; winner explains to 'future maintainer' role.

Prepare & details

How does documentation serve as a bridge between the developer and the future maintainer?

Facilitation Tip: In Failure Story Circle, model vulnerability first by sharing your own project setback to normalize failure as part of the process.

Setup: Panel table at front, audience seating for class

Materials: Expert research packets, Name placards for panelists, Question preparation worksheet for audience

• Understand
• Apply
• Analyze
• Evaluate
• Self-Management
• Relationship Skills

Expert Panel

⏱ 40 min·Pairs

Documentation Demo: Peer Review

Pairs review each other's project docs, simulating maintainer role. Identify gaps, suggest visuals. Revise and present updates to the class.

Prepare & details

How do we effectively demonstrate the value of a technical solution to a user?

Facilitation Tip: For Documentation Demo, provide a sample bug report or README file to anchor peer review conversations in concrete examples.

Setup: Panel table at front, audience seating for class

Materials: Expert research packets, Name placards for panelists, Question preparation worksheet for audience

• Understand
• Apply
• Analyze
• Evaluate
• Self-Management
• Relationship Skills

Teaching This Topic

Experienced teachers approach this topic by coaching students to see communication as part of the development process, not an add-on. Research suggests that practice with mixed audiences builds both empathy and clarity. Avoid letting students rehearse only with peers who already understand the project. Instead, structure repeated opportunities to explain to strangers, whether through role plays or guest audiences.

What to Expect

Successful learning looks like students confidently translating technical details into plain language for mixed audiences. They should articulate both the problem solved and the lessons from setbacks, using artifacts like documentation to demonstrate professional habits of mind.

Watch Out for These Misconceptions

Common Misconception

During Pecha Kucha Rehearsal, watch for students defaulting to technical jargon.

What to Teach Instead

After the rehearsal, have peers flag any unclear terms on sticky notes and suggest plain-language alternatives using a shared word bank of student-generated definitions.

Common Misconception

During Audience Switch, assume students will naturally adjust their language for different listeners.

What to Teach Instead

During the activity, project a simple grid on the board with columns for 'Technical Audience' and 'Non-Technical Audience' and require students to write one phrase they used for each audience before switching.

Common Misconception

During Documentation Demo, treat documentation as a static artifact separate from the project.

What to Teach Instead

Have peers use the project's GitHub issues or bug tracker to simulate a real maintenance request, requiring students to locate and interpret existing docs to respond to a simulated user problem.

Assessment Ideas

Peer Assessment

After Pecha Kucha Rehearsal, students trade 2-minute pitches in small groups and use a checklist to assess each presenter on clarity of the problem solved, explanation of the core feature, and identification of one societal impact.

Exit Ticket

During Failure Story Circle, students write an index card with: one technical concept they simplified for a non-technical audience, one lesson learned from a failed feature, and one specific documentation piece they created for future maintainers.

Quick Check

After Documentation Demo, the teacher poses a scenario: 'Explain the primary benefit of your project's algorithm to a potential investor who knows nothing about coding.' Students write a one-sentence response and share with a partner before turning it in.

Extensions & Scaffolding

• Challenge students who finish early to present their 2-minute pitch to a teacher from another subject area, then bring back feedback on which terms or concepts confused the listener.
• Scaffolding for struggling students: provide sentence stems like 'The problem we solved was...' and 'Our algorithm works by...' to support clear explanations during Audience Switch.
• Deeper exploration: invite a local software developer to join the Failure Story Circle as a mentor, adding industry perspective on how failures are documented and shared in teams.

Key Vocabulary

Stakeholder	An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project. This includes users, clients, and management.
User Interface (UI)	The means by which the user and a computer system interact, in particular, the use of input devices and graphics. It is how a user interacts with a software application.
Technical Debt	The implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. This can manifest as poorly written code or missing documentation.
Value Proposition	A clear statement that explains how a product or service solves customer problems or improves a situation. For software, this highlights the benefits and unique selling points to users.