Guidelines for Design Conference Presentation
CS486: Senior Capstone Design

Overview

The objective of the design conference presentation is to publicly communicate the engineering problem solved by your team, the methods and strategies used to solve the problem, pitfalls encountered, as well as areas of success and enlightenment. You are presenting to a mixed audience and should tailor your presentation accordingly. You may assume that the nominal audience member is at least an undergraduate engineering student.

Guidelines

All teams will be required to give a dry-run presentation to the rest of the class in the week before Capstone. At the Capstone Conference, each team gets a total time slot of 30 minutes, including questions and transition to the next team. What this means practically is that you will have 20-23 minutes for your presentation, leaving about 5mins for transition, and anything remaining for questions after your talk. So shooting for a 20 minute talk is a realistic objective.

Although you may organize your presentation however you see fit, the following is a recommended general outline:

1. (30 seconds) Introduce team, technical advisor, sponsor and discipline
2. (4 minutes) Introduce the problem - At a relatively high level get everyone on-board by helping them to understand the problem that you are trying to solve. This is the 30K foot overview I keep stressing: you should lay out what your client's business is, describe the problem they need solved, and then overview your solution.

   2. 1 Give your "sales pitch". Your goal is to make it glaringly obvious to everyone in the audience that your client really does have a big problem, one that needs you to solve it. If you fail here, the rest of your talk will be worthless!!! After your first slide(s), everyone should be thinking "wow, definitely a huge problem; I wonder how it could be solved?"
   2.2 No technical jargon at this point. Describe it like to your mother. You want everyone to follow you on this big picture --- then they'll at least be able to understand, in principle, the more technical material to follow. A great tool here is to use one or two simple examples to help audience understand the problem. Focus on graphical representations of the problem that you narrate, not on big nests of text and bullets! Summarize the discussion with a short list of key challenges or shortcomings in the present state of things.
   2.3 Now describe your solution vision. Again, this is at the "grandma gets it" level: use simple diagrams that you narrate, or if appropriate, a screenshot of your application that you walk through, highlighting the key elements. The goal is to just give them a "taste", a broad idea, of what you are proposing to solve the problem. Summarize this discussion with a check-marked list, showing the key challenges/shortcomings from the previous (2.2) step, and saying how your solution addresses each and every one of them.

3. (4 minutes) Design Process and solution architecture - Now that we get what you're doing, show us how you did it.

   3.1 Present your overall design paradigm (spiral, incremental, etc.), plus your actual development methodology (Agile, Scrum, whatever). Follow with a timeline to show how it all was laid out.
   3.2 Now talk about your implementation itself. This is the geeky part, but if you've done a good job with the big picture earlier, even non-geeks will be able to hang on somewhat.
   3.3 Describe any tools and frameworks you may have used in implementing your system. A nice graphic showing how they all fit together, plus a tool-by-tool walkthrough of this graphic is a nice way to go.
   3.4 Now show the software architecture that you embodied it all in. Stay at the high-level: a abstract graphic showing high-level modules/classes and how they are interconnected provides an excellent basis for narrating your way through the key highlights of the architecture. Make sure you state why this architecture is the best one, i.e., what made you choose it over other options.
   3.5 Avoid getting too stuck in deep technical digressions. Avoid using esoteric symbols, acronyms, and geek jargon in your diagrams and dialogue. You are sketching this out for an engineering --- but not necessarily CS --- audience, so go ahead and talk technical, but try to keep descriptions comprehensible.

4. (7 minutes) Project Results- Here is where you present your solution!

   3.1 Go ahead and introduce the software product that you produced. Most are complicated, with many screens, so it's good to start with a high-level overview of the product; a nice sketched graphics showing the connected conceptual parts or modules of the product is a great way to get across the big picture.
   3.2 Now that we have the big idea, go through and talk about each major module. You could do a live demo here, but a much better (safer!) idea is to have screen shots of key screens that you first point out a few highlights on, then maybe a short movie clip showing that screen/module in action.
   3.3 Watch the time! It's easy to get caught up in gushing about cool small little implementation details or features. You don't have to explain/show EVERYTHING...your goal is to impress and convince people that this product is truly a great solution to the problem.
   3.4 At the end, it's great to summarize with a list of specific features that directly address the problems/shortcomings that you identified and used to motivate your project at the start.

5. (5 minutes) Project Outcomes and Conclusion

   4.1 Difficulties - Discuss the main software engineering hurdles that you encountered, and (briefly!) how to tackled each of them.
   4.2 Successes - Discuss the positive teaming/learning experiences or challenges that you encountered.
   4.3 Value - A really "wow" wrap-up is to summary the time you spent on the project. Break it out into categories: requirements acquisition, design, coding, team meetings, whatever. Sum up the person-hours at the bottom. Then, in the last line, use a going consulting rate (modest would be $100/hr) to calculate a monetary project value provided to the client.
   4.3 End Result - Discuss the delivery status of the project. How successful were you? How happy is the client? Is there more work that a future design team could do?

6. Announce exhibit building, room, and time (closing slide)
7. (5 minutes) Q/A

Here is a draft of the grading sheet I'll use for Capstone. I do NOT expect you to specifically have slides for each category; your presentation does NOT have to follow or conform to this outline --- indeed, it's best if you just do what it takes to make a flowing, effective presentation. Then **I** will fit what you present into my little grading categories. What counts is that you cover the content --- the order and how you best accomplish this will vary by project.

Table 1: OVERALL Grading Emphases (roughly) --- across all specific categories of content