E6998-2 Final Project
Written Report --- Due 11:59pm, 12/16
Submit a 6-page final report, your source code, and all relevant data.
Your final report should read like a conference paper (we have read many
examples this semester). Send me your final report in PDF format
by email. You will also need to submit your
source code and all relevant data. You do so by setting a webpage with
links to the source code and the data, and email me the URL. Late
submission = 50% penalty.
A good paper will likely have the following components:
One good way to structure a paper is to find a paper you liked in class
and copy its structure (loosely).
If you plan on using Latex, here is an
example Latex template (in tar format).
- Title and Author List: should be self-evident.
- AbstractDescribe in short what you do, how you do it, and the
- Introduction. Motivate the problem you are solving a little
bit. Describe what the problem is, why it is important, and why it is
hard or unsolved. Describe your approach. What is good about it?
Potential weaknesses? Summarize results. Give an outline of the rest
of the paper.
- Description of what you did/built. Use pictures and words to
show what you did. Be detailed. Think about how to organize what you are
- Results. Graphs and tables, all clear and
understandable. Full description of each experiment and the
results. What is the point of each graph? What conclusions can you
draw from it?
- Related work. Write about other similar work. What is
different than what you plan to do? What is similar? Try to draw
general conclusions about what others have missed. Sometimes you can
also place the related work section right after introduction.
- Conclusions.Appropriately drawn from the work described, as
general as possible, with a hint of "lessons learned"; what did you
get out of the study? Summary is what you did; conclusions are what
Here are some advices on how to write.
Presentation and Demo --- 4:10-7:00 pm, 12/17, ENG 253
IMPORTANT: Bring a printout of slides for me.
IMPORTANT: Bring a laptop with your slides.
IMPORTANT: If there are two of you in a team, BOTH of you must talk (split the talk into two components).
You and your partner will give a presentation of your work and demonstrate
how your system works. Keep your talk within 20 minutes (I'll cut
you off after 20) plus 5 minutes for questions. A good talk will include
a clear statement of the problem you are studying, a discussion of how you
went about investigating the problem or solving it or both, results
(graphs), and conclusions.
A sample outline:
Here are some advices on how to give a good talk.
- Introduction and Problem Statement. What problem are you
trying to solve or look into? Why is it an important problem?
- Approach. How do you plan to approach the problem? What is
your methodology? Why is this a good way to approach the problem?
- Results. What have you found out? Present experimental
results here. Make sure to both describe what you are measuring, and
draw appropriate conclusions. ("Here is a table showing the bug-finding
results of our tool on 10 real-world storage systems. The first column
lits the storage systems, and the second column shows the number of bugs
found. ... As you can see from the graph, our fancy tool is pretty darn
effective at finding bugs with no false positives.")
- Conclusions. What did you learn from the process? What should
others take away from what you did? Both specific ("MyCheckingTool found
serious bugs in every system checked, total 10000.") and general ("Model
checking is an effective way to find system errors.") conclusions. Note
that conclusions are different than a summary -- a summary is what you
did, whereas conclusions are what you learned.