Design Review Presentation
Presented in class on 11/10, 11/12 & 11/17.
Your team will sign up for a 10-minute in-class presentation on the checkoff sheet shortly after your proposal debrief. The purpose of the presentation is to share the plan for your project with your classmates and solicit their feedback.
Your presentation should include a 3-minute overview of your project followed by an in-depth presentation of a specific technical problem your team is working on and has not yet solved. The goal is to get useful input from other students, so you must explain the problem clearly enough for them to give meaningful suggestions.
Requirements
You are free to structure your presentation however you like, but most successful presentations include the following components:
- Introduction: Introduce the problem statement and the objectives of the project. What are you trying to achieve? What inspired you to choose this project?
- Specifications: What will your project do?
- Implementation: Present a block diagram of your system.
- What is the role of the MCU and the FPGA?
- What new hardware are you using?
- What new MCU peripheral(s) are you planning to use?
- Feedback: Solicit feedback from your peers. This requires some thought and intentionality to do well. The goal is to solicit feedback on a technical topic, not a cosmetic detail (e.g., what color to paint the box). Some ideas to consider:
- What technical problem would you like feedback on from your peers?
- How would you like them to provide that feedback?
- Conclusion and Q&A: Briefly conclude the presentation and field questions from the audience (as time allows).
Grading Rubric
The design review presentation is worth 20% of your project grade, graded according to the rubric below.
| Category | Points | What We’re Looking For |
|---|---|---|
| Overview of Project & Status Update | 5 | Easy to understand goal of project and project architecture, and currently implemented subsystems are clear. Partial credit example: a project with a clear goal but only some representation of architecture, or incomplete understanding of what’s been implemented, earns around 2.5; little communication of either goal or architecture, where it’s unclear what’s done, earns 0. |
| Description of Subsystem | 5 | Subsystem described concisely, but in sufficient technical detail to ask questions. Partial credit example: a subsystem described confusingly or without technical depth earns around 2.5; an unintelligible subsystem earns 0. |
| Meaningful Feedback from Audience | 5 | Audience asks questions or offers advice that indicates understanding and helps advance the project. Partial credit example: an audience that only asks clarifying questions without advancing the project earns around 2.5; an audience that asks few questions or reaches no useful conclusions earns 0. |
| Presentation | 5 | Presentation is practiced and well ordered to facilitate audience understanding. Partial credit example: a presentation with reasonable organization but stiff delivery earns around 2.5; an unrehearsed, weakly organized presentation earns 0. |
Total: 20 points