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 at most 8 pages that describes your project. It should be similar in style and organization to the research papers that we read this semester. 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.

The major components of your project grade are:

• Paper (50%)
• Presentation (30%)
• Other documentation (proposals, checkpoints) (5%)
• Code Review/Demonstration (15%)

You will give a 15 minute presentation of your work including questions. You should prepare for about 12 minutes of content. See Prof. Newhall's Oral Presentation Guide for more information on how to structure your talk.

A few general comments:

• Your presentation should use figures and diagrams wherever possible. In particular, you will probably have to make new figures in addition to what you plan on putting in your paper. A visual aid is always better than words on a slide.
• Slides should not be cluttered; provide concise outline of main points, not a transcript of what you are going to say. You don't want the audience reading your slide, you want them paying attention to you. When in doubt, use figures and illustrations.
• Practice. Practice. Practice. The easiest way to handle nerves is to be comfortable with what you plan to say, and to have given a talk to an audience beforehand.
• The presentation will be in Science Center 183. Please let me know how you plan to present - using the room Mac or your own laptop. Either way, do a dry run in that room or similar room with your preferred device.

Here are the rubrics for evaluating presentation:

• Student Evaluation Form - each individual will fill out an evaluation of their classmates. This form is very simple - you must provide strengths and weaknesses on three criteria - content, organization, and communication. You must provide quality feedback - both positive and critical. Your feedback will not determine the presenter's grade. But it will effect your own (there is a 10% participation component) and it will help me be more accurate in my evaluation.
• Presentation Rubric - this is the complete list of attributes I will be looking for in a good presentation and how much weight I give to each category. Note that 10% of your presentation grade comes from the quality of your evaluations to other students.

During The week of December 15th, you and your partner will give me a 15-30 minute demo of your project. I will have a sign-up sheet and will provide flexible times.

It is up to you to decide what you are going to demo. Before we meet, decide what you are going to show me. 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.

I will use your demonstration as a starting point for my review of your final code submission.

You have been provided a sample report document in your lab directories. You must utilize the provided LaTeX style files to produce your report. I am more than happy to answer questions, but will almost always just "google" the question for you. Use Piazza and Stack Overflow for best results. 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; think of it as your "elevator speech". 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 contributions of your work. Limit your abstract to just a couple of paragraphs - 200 words at most.

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.

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. If it makes sense to do so, you can incorporate related work into your Introduction. For example, if you are building on previous work. You can review a recent paper by my group as an example.

4. One or more sections describing your Solution This is some times referred to as Methods, Algorithm, Methodology, or Approach. Your section headings could even be specific to the algorithm, such as k-Nearest Neighbors. As a whole, these sections should tell the reader what you did, and how they could replicate it. Be sure to address these issues:
   • Details of the problem you are solving
   • Details of your solution and the project's implementation
     Even though you may have spent a considerable amount of time writing code, this should not include a listing of any code you wrote. You can use high-level pseudocode to describe an algorithm if you implemented it.
   • Discussion of how your solution solves the problem.

5. Experimental Results demonstrating/proving your solution
   • Experimental Methodology: Explain how you gathered the data and details of how your experiments were run. Did you use any external software? Did you pre-process the data in any way? How did you generate features from the data? Did you use cross-validation? Do you need to define any questions you use for evaluation (e.g., Silhouette Index).
   • Explain the tests you performed (and why)
   • 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. Your results should be rich in meaning and concise.
   • Discussion of 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. You must cite all referenced papers within the text of your paper.

Writing Style Guidelines

1. Write in a top-down style
   First present 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. Don't shy away from math - use equations and variables instead of overly verbose descriptions.

6. 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.

Your complete final project is due by noon on Friday, December 19. Subdirectories below are in your ~/cs68/labs/project directory. The first three items bellow will be submitted by using handin68. Data is submitted using submit68 instead. You should hand in:

• In the paper subdirectory, submit your paper and all accompanying files necessary to compile your paper. Your main source file, bib file, and pdf should all have the user IDs of all project partners. For example, eoh1_wngo1.tex. Be sure to include all necessary figures in your submission.
• In the presentation directory, all files from your presentation. I prefer your slides in PDF format to keep things compact. If you have any external demos or animations, include a README file describing how to view them.
• In the code directory, all of scripts and main programs you developed for the project. Include a README describing the purpose of each file and how to use them to produce the results. Your code should be well designed and commented.
• You will submit your data used for evaluation. To do so, create a directory containing all of your data, e.g., projectData. Then, run submit68 from the command line. The script will prompt you for the directory location, and then package the file and move it to a central repository. You may re-run this command, which will overwrite the previous submission. If you have multiple data sources, place each in a subdirectory within your main folder, e.g., projectData/yeastExpression. Place a README file as well, describing the source of the data (paper, website) and any pre-processing steps you utilized (e.g., throwing out incomplete data). The idea is to make it easy for me or someone else to re-use your data.