Project Presentations

The next two classes will be presentations of your projects.

23 November

Joseph Calandrino, Matt Spear
Patrick Graydon
Nora Soravel
Jing Yang

30 November

Tony Aiello
Michael Crane, Wei Hu
Nguyet Nguyen
Michael Spiegel

Each presentation will be strictly limited to twenty-two minutes with up to 5 additional minutes for questions. If you plan ahead and use your time wisely, this is plenty of time. You should endeavour to make your presentation interesting, informative and memorable.

The goal of almost all presentations is to get your audience interested enough in what you are talking about that they will want to learn more. For your project presentations, the goal is to make your audience understand and remember the most important idea from your project. You cannot expect to convey a lot of technical information, but you should be able to motivate your work and convince your audience why it is important and interesting, make it abundantly clear to your audience what you actually did. There should be some technical content in your talk, including an explanation of one nugget that came out of your work.

All talks should tell a story. Don't fall into the trap of reading a list. All good stories:

• Introduce characters (e.g., rabbit). Characters may be familiar creatures or abstract things. If your characters are not cute and furry, you need to give your audience a reason to care about them.
• Describe an important problem (e.g., fox wants to eat rabbit)
• Relate events related to resolving the problem (rabbit tells fox about thesis). Sometimes the problem is resolved, sometimes bigger problems are introduced.
• Draw a general conclusion that is supported by your story (moral)

Nearly all stories follow this model, and nearly all presentations should also.

• Introduction
  • Introduce characters: motivate your work
    • Convey why the problem you are solving is interesting, important and exciting
    • Place your work in context: how is it different from what others have done
  • Give the audience a reason to listen to the rest of your talk. Unlike stories, technical presentations should not (often) use suspense. State the main conclusion up front, so your audience knows the point you will be making.
• Guts
  • Explain what you did
    • Don't be comprehensive - get the big picture across
    • Use pictures, one clear example (maybe two if necessary).
  • Convey one technical nugget - show one neat concrete thing that came out of your work.
  • Analysis
    • Did your work solve the problem?
    • What are the important results of your work
• Conclusion - Summarize your project with one key point. If your audience remembers one thing from your talk, you have succeeded.

Project Reports Final project reports are due December 7. You should turn in a paper printout of your report at my office and emailing me a URL for your project report (which should be either .html or .pdf). I will read the paper you turn in, but make the web reports available from the course site.

Like talks, papers should also tell stories. Your reports should include substantial technical details, though.

The final report should motivate, describe and evaluate your work. You may organize your final report into sections as you see fit. It should include (but is not limited to):

• Problem: A clear description of the problem you are addressing. It should motivate your work by arguing that this is an important problem and that there is no satisfactory solution.
• Related work: A good summary and analysis of the work relevant to your project. Everything you describe should be related directly to your project:
  • Why is it relevant? (Don't assume the reader can read your mind.)
  • If it attempts to solve a similar problem, why is it not a satisfactory solution?
  • What ideas in the other project can be applied to your project?
• Solution: Describe what you did to address the problem. This section should make it clear what exactly you did, and how it relates to the problem you motivated in the first section.
• Evaluation: Analyze the success of your solution. This section should provide objective and subjective arguments showing how well your solution addressed the problem. You should have some substantial support for your arguments, but it is not unacceptable to conclude that more work needs to be done to produce a definite evalution, and describe what additional work is needed. (In many cases, I hope you will want to pursue this additional work after the seminar and work towards a publishable paper.)
• Conclusion: What can the security community learn from your work? Your conclusions should be supported by your evaluation section.

There are no length constraints for the final report, but you should aim to be as concise, clear and organized as possible. The writing and presentation should be at a high quality. It would be highly worthwhile to exchange reports with a classmate and review each others reports before submitting them. Your reports will be posted on the course website (unless you have a reason to object to this).

University of Virginia Department of Computer Science CS 851: Malware Seminar

evans@cs.virginia.edu