Overview

The design review is a mechanism for periodically presenting the design team's progress on the project, focusing on current perceptions of the problem and their ideas regarding solutions. It is a formal process that includes the customer, the project manager, and other relevant parties. The design review is both a status reporting mechanism and a quality assurance mechanism.

As status reporting mechanism the design review should provide the audience with an up-to-the-minute view of the tasks accomplished, design decisions made, and plans for future progress. As a quality assurance technique the design review should provide the audience with as much insight into design quandaries, pros and cons, and current thinking on solution --- and should explicitly invite input and critique on these matters. If you have a problem that you're not sure how best to tackle, this is a great chance to get some general input.

Two design reviews will be held during the EGR 486 project cycle. The first will occur during the design phase; the second will occur roughly halfway through the implementation phase. The audience at these reviews will include (hopefully) the customer, the technical advisor and the project manager --- plus of course the other members of the Capstone class. The general public will be excluded.

Specifications

Each presentation will have a maximum total time of 25 minutes: 15 minutes for presentation, 10 minutes for questions and answers. The time limit of 25 minutes is subject to change pending available time. Plan to keep your talk efficient and compact.

1. Objectives

• Enhance presentation skills
• Practice public speaking skills
• Report on the current state of your design process
• Engage in open forum design critique

2. Presentation Requirements

• Professional appearance. This is a public appearance of your team; looks/impressions matter.
• Use of presentation graphics software (e.g., Microsoft PowerPoint)
• It is not mandatory that EVERYONE in the team present; put your BEST speakers on stage --> professional image is everything. . If possible, however, it is impressive if your can serve up multiple high-quality presenters. This demonstrates that you have a thoroughly well-rounded team.

3. Presentation Outline

Overview: As I've said many times in our meetings, all project presentations are essentially the same --- it's just that the focus of your talk shifts with each talk. In the first intro talk (last fall) it's mainly about the team and the problem, for your proposal you still talk about team and problem but main focus is on requirements and solution statement. These design reviews continue this trend --- you still cover all the intro stuff, but in compressed format, to allow a main focus on the most recent development activities and project status.

1. Introduction (team, sponsor, etc.) - Keep it brief --- this isn't the first time your team has appeared -- simply introduce your team, the sponsor's name, and the sponsor's company and move on.
2. Task Definition - Be brief but compelling here. You should be getting very good and making a strong case for your project by now! Review what business your client is in, and restate the specific problem they have, then introduce your solution, as in "In Dec 2002, Team Foobar proposed a comphrehensive solution to this problem, in the form of a software transmogrification simulator." Go on to give the highlight features of your solution, maybe a nice screenshot to cement the idea.
3. Design Methodology and Rationale - Be brief. This is just to show that you aren't just gunning from the hip. Simply explain which design paradigm you are using --- and why you are following this paradigm --- in order to establish the context for the rest of your presentation.
4. THE MEAT - This is your primary focus for this review. Assuming you have covered your main project requirements in #2, start with a nice architecture overview --- just a sketch of your major modules, how they interact, and what they do -- which should jive closely with the product requirements you just talked about. With this clear picture of your overall product function and architecture, you can then go through the Functional Specs. Then go on with your Implementation Details, which could sketch a few details of hacking process (algos, who coded what, order of coding) but should focus primarily on.....THE PRODUCT. We should see full demos/screenshots of working alphas or betas with clear reference to what you have left to do.
   
   Regardless of the stage of design, your goal is to use the audience to help you review your progress and identify flaws in your design. You no longer have to sell them on the design concept per se --- assume they are on your side and you are showing this to capable and critical friends. They want you to succeed! Your job is to give them an accurate picture of what you are trying to do so that they can help! But remember: you are the experts --- the help the audience can give is high-level feedback -- so don't bother trying to numb us all with technical details!
5. Challenges past and present. Give us an update on particular challenges that (a) have come up, been tackled, and how and (b) challenges that remain, that you might have a plan on, but wouldn't mind having some input on. Present your current plans for dealing with it, along with a rationale of why you think your plan is good (versus any other options you've thought of). This is a critical piece of the review --- the part where you show that you have been successfully dealing with challenges and where you are honest about what you haven't quite licked yet. Makes it all more satisfying to report the solutions you found at Capstone!!
6. Schedule Report showing tasks completed and tasks to be completed - This is also important. You should present up-to-the-minute Gantt and PERT views of your schedule. Your goal here is to give the audience a clear picture of whether you are ahead-of-schedule, on-schedule, or behind-schedule. You should highlight the impact of any tasks that are behind schedule, and you should make predictions about the team's ability to deliver a complete project on schedule.
7. Conclusion as usual. Summarize you experiences and progress. Say something positive.

5. Rules: Each team should stay within the 15 minute time limit; serious transgressions will mean lower score.