Written Project Report, Presentation and Demo

Project Presentation due: during week 14 of classes
Final written report is due: Thurs May 12 before noon
Project Code due: Thurs May 12 before 11:59pm
Project Demo due: during final exam week, and before May 12

Counts towards 30% of your final grade
Overview: Report, Presentation, Demo
The final part of your course project consists of a presentation, a written report and a project demo. You should prepare a final report of 10-15 pages that describes your project. Your report may not be more than 20 pages long (including references). It should be similar in style and organization to the research papers that we read this semester (the well-organized ones that is). This is your opportunity to describe in detail what problem you were solving, how you solved it, how you tested your solution, what your results show, difficulties you encountered along the way, what you would have liked to have done (or done differently), and what you learned from your project.

You will also submit all your project code and give me a demo of your project. However, your grade is almost exclusively determined by your written report and oral presentation. This models the real research world where the research paper is the primary, and usually only, mechanism through which your work is evaluated, and where written conference proceedings and conference presentations are the main mechanism through which others learn about your work. Therefore, you should spend a significant amount of effort making sure that you have a complete, and well-written final report and presentation; don't do a fabulous project and then fail to present it well.

See the "Detailed Requirements for the Written Report" section below for how to structure your written report.

Project Presentation
You will give a 25 minute class presentation of your work.

Project Presentation Schedule for Week 14

Add a .pdf of your talk slides to the course page wiki prior to the class meeting when you will give your presentation.


Your talk should include, the following: Your talk should also have a logical narrative flow to it, so think about structuring your presentation in a logical way. Striving for a top-down approach will help with this. Using lots of figures and diagrams will help explain your project. Simplify, at least at first. And make it clear where the parallel/distributed focus is in your project.

You should use the rubrics I passed out in class to help you structure your talk and determine good slide content. Also, see my Oral Presentation Guide for more information on structure and preparing for a talk and talk slides.

Project Demo
During final exam period, your project group will give me a 30 minute demo of your project. You should sign-up for a demo slot outside my office door.

It is up to you to decide what you are going to demo. Before we meet, decide what you are going to show me, come up with a simple demo script, and run through it several times to make sure that there are no glitches during the demo. This is your chance to show off all your hard work; you want to convince me that you did something interesting and that you did a substantial amount of work.

Detailed Requirements for Project Written Report
Paper Organization
Writing Style Guidelines
What to handin

Paper Organization

You should have the following main sections in your paper:
  1. Abstract
    The abstract is a brief summary of your work. It should be written to make the reader want to read the rest of your paper. Briefly state the basic contents and conclusions of your paper: the problem you are solving, why the reader should care about this problem, your unique solution and/or implementation, and the main results and and contributions of your work.

  2. Introduction
    The introduction is the big picture of your work: what, why, and how. It includes a definition of the problem you are solving, a high-level description of your solution including any novel techniques and results you provide, and a summary of the main results of your paper. In addition, motivates the problem you are solving (why should a reader find your work important), and describes your contribution to the area (this may not be applicable to your project).

    The first paragraph of the introduction should contain all of this information in a very high-level. Subsequent paragraphs should discuss in more detail the problem you are solving, your solution, and your results and conclusions.

    • Statement of Problem Being Solved
    • Motivation
    • Problem Solution
    • Results and Conclusions

  3. Related Work
    This is an essential part of a research paper; discussing related work is a good way to put your work in context with other similar work, and to provide a way for you to compare/ contrast your work to other's work.

    You should use feedback on the annotated bibliography from your project proposal to structure this section; it should be written as a re-write of your annotated bibliography in a single Related Work section.

  4. One or more sections describing your Solution
    • Details of the problem you are solving
    • Details of your solution and the project's implementation
      Even though you may have spent an enormous amount of time writing code, this should not include a listing of any code you wrote. Only if your project is about developing an algorithm or a new language, may code examples be appropriate here.
    • Discussion of how your solution solves the problem.

  5. Experimental Results demonstrating/proving your solution
    • Explain the tests you performed (and why)
    • Explain how you gathered the data and details of how your experiments were run (any system/environment set up)
    • Present your results
      Choose quality over quantity; the reader will not be impressed with pages and pages of graphs and tables, instead s/he wants to be convinced that your results show something interesting and that your experiments support your conclusions.
    • Discuss your results!
      Explain/interpret your results (possibly compare your results to related work). Do not just present data and leave it up to the reader to infer what the data show and why they are interesting.

  6. Conclusions & Future Directions for your work Conclude with the main ideas and results of your work. Discuss ways in which your project could be extended...what's next? what are the interesting problems and questions that resulted from your work?

  7. A brief meta-discussion of your project Include two paragraphs in this section:
    1. Discussion of what you found to be the most difficult and least difficult parts of your project.
    2. In what ways did your implementation vary from your proposal and why?

  8. References
    At the end of your paper is a Reference section. You must cite each paper that you have referenced...your work is related to some prior work.

Writing Style Guidelines

  1. Write in a top-down style
    First present the the high-level issues, then expand them. This applies to the overall organization of your paper as well as the organization of sub-sections and individual paragraphs.

  2. Conclude each paragraph, section and entire paper
    Each chunk of your paper whether it be a paragraph, a sub-section, a section, or the entire paper should have a conclusion. For example, each paragraph should be written as follow:
    • 1st sentence(s): main idea of paragraph
    • middle sentences: expansion of the idea (further explanation or elaboration of the topic)
    • concluding sentence(s)

    Each section of your paper should be organized as: high-level important points first, details second, summarize high-level points last.

  3. Use active 3rd person
    We present, we show, we demonstrate...

  4. Define terms, and always define them before using them

  5. Use figures
    Use diagrams to help explain system design, and graphs or tables for presenting results. If your project has a GUI component, then your paper should have some screen dumps of your interface (look at the man page for xwd).
    You should have a figure showing the high-level design of your implementation.

More detailed writing advice and guidelines can be found here: CS Research and Writing Guide

You may use any software you would like for your final report. However, use a reasonable format, font size. If you want to use latex, I have a latex paper example that you can use as a starting point for your final report (it also shows example of using bibtex, and shows how to add figures and tables, and how to make figures span two-columns). You can copy it over from here:

What to hand in
Before noon on May 12, you will hand in a printout of your project report to me in person. If I'm not in my office, you can slide it under my office door and email me that you did so. You must submit a printout of your report (do not just email me a .pdf).

In addition, by the end of the day on May 12, you should push to your git repo all your project code, Makefile, run scripts, etc. Make sure to include a file named README.final with the information described below.

Your project repo should include:

  1. Everything I need to build and run your project
  2. A README.final file that explains how to build and run your project. Give me example command lines for running. It should take no more than my running make to build, but if that is not true, then also tell me how to build your project. Also, give me any information I need to set up a run environment (again this would be a good thing to include in your Makefile), and any information I need to use any runscripts you have. If your project only runs on XSEDE resources, then give me much more detailed run instructions
  3. a .pdf version of your project report (you can include the .tex and other sources as well if you'd like).