Capstone Introduction

[jm1021]

PLTW Honors Capstone

The course is new to Del Norte, but many of the activities are familiar to former CSP and CSA students. If you were to dive straignt in you could look at this outline and my Cog Overload document and have an idea what this process migh look like...

Week 0

• Form into Teams of 2 or 3 - use Wayfinding Game and Tooling to get started.
• Think of preliminary Abstract (sample follows from my capstone)

Abstract
This capstone study investigated novice STEM learners’ experiences of cognitive overload during onboarding to JavaScript-based game development within the Open Coding Society (OCS) e-learning environment. The research focused on understanding how early exposure to multiple interacting systems—syntax, configuration, asset management, and spatial reasoning—affects learners’ cognitive load and progression. Two research questions guided the study: how learners experience cognitive overload during onboarding, and how instructional supports influence their ability to manage cognitive demands. Data were collected using a mixed-methods approach including a Likert-based cognitive load survey, structured microblog reflections, and platform behavioral analytics. Participants consisted of secondary students aged 14–16 enrolled in an introductory computer science course. Findings indicated that the GameBuilder and GameRunner tools reduced extraneous cognitive load by providing structured scaffolding and immediate visual feedback. Learners demonstrated strong conceptual understanding of object interactions and maintained productive engagement patterns. Conclusions support the effectiveness of the scaffolded e-learning design while identifying areas for refinement, including enhanced hitbox visualization and automated level integration.

• Think of using Technology, Gaming, LLM, and/or AI to aid your study. This should leverage former Project and system knowledge.

Introducton Week 1 / Section 1

• Answer and form answers to these sections of sample TOC

Instructional Problem

Current State – Introductory Scrummer KSAs

Desired State – Post-Onboarding KSAs

Gap Between Current and Desired States

Instructional Expectations

Research Topic

Research Topic Importance

Research Questions

RQ1 – Learner Experience

RQ2 – Learning Support and Progress

Research Purpose

Hardware Innovation

• My recommendation is to add hardware to the solution (sample is GPUs)

Lit Review - Week 2 / Section 2

Chapter 2: Literature Review

Introduction to the Literature Review and Organization of Themes

Literature Review Synthesis

Theme 1: Cognitive Load in Novice Learners

Theme 2: Tool-Supported Scaffolding

Theme 3: Visual and Asset-Based Support in Game Development

Theme 4: Immediate Feedback and Iterative Coding

Theme 5: Reflection, Monitoring, and Social Support

Conclusion / Summarize

Conclusion / Reflect

[jm1021]

PLTW Capstone: Engineering & Software Systems Design (2-Trimester Syllabus)

Part 1, Sprints 1 - 3, Iteration 1: Foundation & Proof of Concept (PoC)

Sprint 1: Weeks 0 - 4 (Problem Definition & Agile Initialization)

1. Project Management

• Design Process & Documentation: Initialize a professional engineering portfolio alongside a digital Kanban board (GitHub Projects or Jira) to log tasks, user stories, and acceptance criteria.
• Collaboration & Experts: Establish team norms, allocate individual technical ownership roles, and conduct an initial requirements-gathering interview with an industry mentor.
• Ethics & Intellectual Property: Conduct a patent and open-source license search (MIT, GPL, Apache) to ensure the proposed solution does not violate existing IP.

2. Research

• Problem Identification: Draft a formal problem statement backed by statistical data, market research, or direct observation from affected stakeholders.
• Literature Review: Analyze a minimum of three existing commercial, open-source, or academic attempts to solve the problem, highlighting their technical limitations.
• Design Specifications: Author a Product Requirements Document (PRD) defining strict, quantifiable target metrics (e.g., system latency < 200ms, weight < 5 lbs, accuracy > 90%).

Sprint 1 Assessment Matrix

• Core Deliverables: Setup GitHub repository/Project board; Finished PRD; Signed mentor agreement form.
• Grading Benchmarks: Problem statement validity (25%), Quantified design specifications (25%), Industry research depth (25%), Agile sprint setup (25%).

---

Sprint 2: Weeks 5 - 8 (System Architecture & MVP Construction)

3. Design

• Concept Generation: Sketch three distinct architecture designs or system topologies. Use a weighted Decision Matrix to select the final path based on cost, complexity, and timeline.
• STEM Application: Map the technical architecture. Define API endpoints, data flow diagrams, circuit schematics, or mechanical CAD mockups before writing core code or cutting materials.
• Viability Check: Perform a financial and technical feasibility audit, listing the complete Bill of Materials (BOM) and tracking the project's financial budget.

4. Prototyping and Testing

• Prototype Creation: Build a Minimum Viable Product (MVP) or functional Proof of Concept (PoC) demonstrating that the primary feature or core algorithm functions.
• Testing Plan: Write a formal testing protocol or software unit tests to isolate and evaluate the core functionality under nominal conditions.
• Analysis: Run the initial test suite and log the empirical output data directly against the target metrics established in the Sprint 1 PRD.

Sprint 2 Assessment Matrix

• Core Deliverables: Architecture/Data flow diagrams; Initial physical BOM or software tech stack; Working MVP/PoC code repository or prototype.
• Grading Benchmarks: Decision matrix logic (20%), Technical modeling precision (30%), Prototype functionality (30%), Baseline data logging (20%).

---

Sprint 3: Weeks 9 - 12 (Alpha Evaluation & Trimester 1 Defense)

5. Project and Process Evaluation

• Stakeholder Feedback: Demonstrate the MVP to your industry mentor and target end-users to gather structured qualitative feedback via surveys or interviews.
• Design Reflection: Conduct a post-mortem review to document technical debt, component failures, software bugs, and unexpected system bottlenecks.

6. Reflection and Presentation

• Portfolio Finalization: Compile all Sprint 1-3 artifacts into an organized, student-facing engineering portfolio.
• Formal Presentation: Deliver a formal technical presentation defending the Alpha prototype's architecture, test data, and performance gaps to an evaluation panel.

Sprint 3 Assessment Matrix

• Core Deliverables: User feedback datasets; Comprehensive engineering portfolio (v1.0); Trimester 1 presentation slide deck.
• Grading Benchmarks: Portfolio documentation thoroughness (40%), Presentation defense and communication (40%), Depth of failure analysis (20%).

---

Part 2, Sprints 4 - 6, Iteration 2: Refinement, Optimization & Enterprise Scaling

Sprint 4: Weeks 13 - 16 (Failure Analysis & Architectural Redesign)

1. Iterative Project Management

• Change Documentation: Log all Pass 1 failures, structural pivots, and architectural modifications in a version-controlled changelog (or Git release notes).
• Expert Consultation: Present Trimester 1 panel feedback to industry mentors to co-sign the technical optimization strategy.
• Risk Management: Construct a Failure Mode and Effects Analysis (FMEA) matrix to identify potential failure points in the new design and establish mitigation plans.

2. Failure Analysis & Optimization

• Root Cause Analysis: Perform rigorous debugging or physical stress tracking to isolate the root cause of errors logged in Sprint 3.
• Component Redesign: Refactor poorly optimized code blocks, upgrade structural components, or swap out inefficient hardware sensors to improve system performance.
• Revised Specifications: Update the PRD to establish stricter, high-fidelity performance constraints that push the project toward industry grade.

Sprint 4 Assessment Matrix

• Core Deliverables: Completed FMEA matrix; Updated system architecture diagrams; Product requirements revisions (PRD v2.0).
• Grading Benchmarks: FMEA risk analysis accuracy (35%), Root-cause diagnostics depth (35%), Code refactoring or physical redesign plans (30%).

---

Sprint 5: Weeks 17 - 20 (High-Fidelity Engineering & Stress Testing)

3. Advanced Fabrication

• High-Fidelity Prototyping: Construct the Beta prototype using durable materials or optimized software practices (e.g., continuous integration pipelines, robust error handling).
• System Integration: Fully integrate all sub-systems (unifying frontend/backend, or linking electrical sensors to mechanical housings) to eliminate interoperability errors.
• Manufacturing Viability: Calculate production costs at scale, detailing a theoretical plan for assembly line deployment, manufacturing constraints, or cloud hosting overhead.

4. Destructive & Parametric Testing

• Rigorous Testing Protocols: Execute edge-case testing, load testing, or physical destructive testing to determine the absolute operational limits of the system.
• Comparative Data Analysis: Generate mathematical models or data visualizations (using Python, Excel, or MATLAB) comparing the performance metrics of Prototype 1 vs. Prototype 2.
• Regulatory & Safety Compliance: Audit the system against relevant real-world standards (e.g., FCC, OSHA, GDPR, or ISO guidelines) appropriate for the problem domain.

Sprint 5 Assessment Matrix

• Core Deliverables: Fully assembled Beta prototype; Parametric testing datasets; Performance comparison charts (V1 vs. V2).
• Grading Benchmarks: System integration quality (30%), Testing rigor and edge-case coverage (40%), Comparative data analysis quality (30%).

---

Sprint 6: Weeks 21 - 24 (Validation, Deployment & Capstone Defense)

5. Operational Validation

• User Acceptance Testing (UAT): Conduct blind or structured user acceptance testing with external participants, measuring usability metrics and user error rates.
• Final Product Reflection: Write a final engineering assessment documenting unresolved technical trade-offs, constraints, and a "future roadmap" for the product.

6. Professional Pitch & Expo

• Technical Portfolio Closure: Package the repository, CAD files, schematics, testing logs, and user documentation into a polished, public-facing technical portfolio.
• Commercial Pitch & Defense: Deliver a venture-style presentation or capstone expo defense to an external panel of industry engineers, proving the system's absolute real-world viability.

Sprint 6 Assessment Matrix

• Core Deliverables: Final engineering portfolio (v2.0); UAT feedback report; Live project demonstration; Final presentation slide deck.
• Grading Benchmarks: Prototype final performance against target specs (30%), UAT implementation (20%), Final portfolio closure (20%), Capstone presentation defense (30%).

[jm1021]

Sprint 1 Deliverable: Project Initialization & Systems Research Package

Week 0: Team Formation & System Scope

1. Team Directory

• Team Name: [Insert Name]
• Member 1 (Technical Owner / Git Lead): [Insert Name]
• Member 2 (Project Owner / Kanban Lead): [Insert Name]
• Member 3 (System/Hardware Integration Lead - Optional): [Insert Name]
• Kanban Board Link: [Insert URL to GitHub Project Board]
• Target Tech Stack: [e.g., Software Stack, Open Coding Society Elements, Custom Sensor Hardware, AI/LLM Orchestration APIs]

2. Preliminary Abstract

Draft a single paragraph (150–250 words) summarizing your engineering objective. State the real-world problem, your technical solution path, your system integration strategy (software/hardware/AI), and how you plan to gather data to prove your system works.

Example Frame: This capstone project investigates [Core System Problem/Friction Point] within the context of [Target Domain]. The system architecture integrates a [Software Stack/Algorithm Layer] with a [Hardware Innovation/AI Coprocessor Layer] to optimize [Quantifiable System Target]. System evaluation will combine platform behavioral metrics with automated user telemetry...

---

Week 1: Section 1 — System Introduction & Problem Design

1. The Core Instructional / System Problem

What is the exact technical bottleneck or real-world problem you are targeting? Explicitly define why the current ecosystem causes friction, inefficiency, or cognitive overload.

• Problem Statement:

2. Knowledge, Skills, and Abilities (KSA) Baseline Mapping

Define the performance state of your system users or environment before and after your engineering intervention.

Current State Baseline

• Knowledge Limitations: [What do users struggle to understand or what variables are missing from the system architecture?]
• Skill Gaps: [What processes are manual, slow, or prone to user/syntactic error?]
• Capability Constraints: [What can the target environment not do right now?]

Desired Post-Intervention State

• Knowledge Targets: [What mental models or structural parameters will be unlocked?]
• Skill Enhancements: [What automated or optimized workflows will the user master?]
• System Capabilities: [What functions will now execute flawlessly?]

3. Gap & Technical Expectations

• The System Gap: [Describe the exact delta between your Current and Desired states.]
• Operational Expectations: [How must your solution regulate complexity? Why is your specific technical path matched to this gap?]

4. Hardware Innovation & Infrastructure Integration

If you are integrating physical hardware nodes (e.g., array deployments, sensory monitors, or dedicated processing units), paste your structural blueprint or wireframe photo here. Explain how this component offloads processing from abstract software loops into high-performance execution blocks.

• Hardware Node/Component Description:
• System Offloading Strategy:

![Hardware Topology Wireframe](https://placeholder-for-student-diagram-url.com)

5. Formal Research Framework

• Core Research Topic: [A clear, formal one-sentence declaration of your engineering inquiry.]
• System Topic Importance: [Why is this worth solving? Quote statistical data, market demands, or technical constraints.]

Explicit Evaluation Questions

• Research Question 1 (User / Interface Mechanics): How do system users interact with [Scaffold/Feature X], and where are the remaining friction points?
• Research Question 2 (System Performance / Progression): To what extent does the integration of [Core Component Y] optimize overall system throughput or completion rates?

6. System Purpose Statement

The primary purpose of this development lifecycle is to engineer an architecture that... [Complete this with focus on your optimization targets and evaluation methods].

---

Week 2: Section 2 — Literature & Prior-Art Review

Smith ScholarWorks

Locate, analyze, and cite a minimum of three existing implementations (commercial products, open-source repositories, or academic engineering papers) that address your problem statement.

1. Categorized System Themes

Map your solution down into specific technical disciplines or themes based on your stack.

• Theme 1: [e.g., Cognitive Load and Tool-Scaffolded Onboarding Environments]
• Theme 2: [e.g., High-Throughput Hardware Array Topologies]
• Theme 3: [e.g., Live Feedback Loops in Iterative Engineering Systems]

2. Prior-Art Decomposition Matrix

Prior-Art Node 1: [Name of Project/Paper/Repo]

• Source Citation/Link:
• Engine Capabilities: [What did they build right?]
• Architectural Challenges: [Where did their system stall out, crash, or create user friction?]
• System Traransfer Insight: [What specific logic pattern, circuit, or library are you adapting from them?]

Prior-Art Node 2: [Name of Project/Paper/Repo]

• Source Citation/Link:
• Engine Capabilities:
• Architectural Challenges:
• System Transfer Insight:

Prior-Art Node 3: [Name of Project/Paper/Repo]

• Source Citation/Link:
• Engine Capabilities:
• Architectural Challenges:
• System Transfer Insight:

3. Synthesis & Engineering Justification

• Prior-Art Summary: [Analyze the common structural patterns found across all three systems.]
• Your Technical Pivot: [State how your system explicitly combines or improves upon these baseline designs to eliminate the problem defined in Week 1.]
• What products or systems already attempt to solve this problem?
  -- Product A
  -- Product B
  -- Open-Source System C
• What technology or architecture could be adapted?
  -- Event-driven architecture
  -- Vector database
  -- Computer vision
  -- REST API
  -- Embedded sensor
  -- Machine learning model
• What does the research community already know about the problem?
  -- Cognitive load
  -- Human-computer interaction
  -- Learning analytics
  -- Network performance
  -- Material strength

---

Weeks 3 & 4: Initial Product Requirements Document (PRD v1.0)

1. Functional System Constraints

Define exactly what your system must do to achieve a stable Alpha release.

• Constraint 1: Must ingest data from [Hardware Sensor/API Node] with latency under [X]ms.
• Constraint 2: Must execute [Core Automation Algorithm] without manual user intervention.
• Constraint 3: Must auto-generate and version-control configuration files within the GitHub file structure.

2. Quantifiable Success Metrics

System Component	Baseline Metric (Current State)	Target Metric (Sprint 2 MVP)	Target Metric (Sprint 5 Production)
Execution Latency	Manual / Arbitrary	< 500 ms	< 50 ms
User Onboarding Friction	Multiple stalls observed	Under 10 mins	Zero intervention
Hardware Node Stability	Overheats / Unstable	1-hour continuous run	24-hour uptime
Data Fidelity	Corrupts on large payloads	> 90% ingestion accuracy	> 99.9% error-free

3. Evidence Chain

OBSERVATION
↓
EVIDENCE
↓
PROBLEM
↓
USER NEED
↓
REQUIREMENT
↓
METRIC
↓
TEST

Layer	Example
Observation	Users repeatedly stop at the same workflow step
Evidence	18 of 25 observed users required assistance
Problem	The workflow does not provide sufficient guidance
User Need	Users need a clear next action
Requirement	System shall provide a contextual next-action prompt
Metric	80% of users identify their next action without assistance
Test	Give 20 users a task and measure independent completion