Capstone Project Final Report

Due Friday, May 13th (by 11:59pm)
Not accepted late!

Introduction

At the end of the course you are required to submit a written report describing your project or research, using a format typical for publications in computer science. This report will detail your accomplishments this semester, but will also be an opportunity to reflect on your experience and to get some practice with technical writing. Your final report should conform to the ACM SIG format and be 8-10 pages, including all figures and references. (There are templates for both Word and LaTeX on that site.) If you completed an implementation project, your writeup should include a detailed description of your implemented system, including what it does, how it works, and how it is used. You might also include details about false starts or discoveries you made of what didn't work, or how your project integrates with a larger system. If you completed a research project, this document should include the details of that research, including what you accomplished and the significance of your contributions. Be sure to detail the background for your research, the method of your research, the results of your research, the analysis of your results, and the implications of that analysis. In either case, you will want to include the background and motivation of your project (which you can borrow from your proposal), as well as a brief overview of related and similar work. Implementation projects should have at least 5 references, while research projects might have 10 or 20 or more.

Format

Below is a general template for structuring academic papers. Some of these sections might not be applicable, depending on the specifics of your project, but it should serve as a good starting point for the organization of your writeup. You can find some of the final project writeups from the last time I ran capstone in this folder for reference. There's a wealth of information online about structuring academic papers as well. (Here's one from Columbia, for example, that might be helpful.)

Abstract A short (max 150 words) summary of the paper. It's usually easier to write this last, once the structure of the paper has taken shape.

Introduction: Explain the context and motivation for your project. What domain are you working in? What is the subject of your project? Why is this a problem worth solving? Include a very brief description of your approach. With some luck, you can probably steal most of this from your project proposal.

Background and Related Work: What other work has been done before? Do similar systems or research exist? How does your project fit into a greater context, perhaps building on what has come before? Be sure to reference other work properly, and include those references at the end of the paper.

Implementation / Method: If you did an implementation project, describe its architecture and how it works. For a research project, explain your research method. Feel free to document failed attempts as well as the final path taken. This is likely to be the largest section in the writeup of an implementation project. Just the facts please: this section should not make claims about how well your system works or how it compares to other efforts. That material goes in the next two sections.

Evaluation / Results and Analysis: How well does your system work, or what did you figure out? In an implementation project, you might report on either a short user study explaining the system in use, or give the results of tests demonstrating the effectiveness of your implementation. For research projects, present and analyze data that supports your arguments. It wouldn't be surprising for this to be the largest section in a research project writeup.

Discussion: The previous two sections described your work in detail, and the related work section talked about what others have done. This section should put your results in context — how does your contribution support, refute, or extend previous work? What is the significance of your project? Opinions are fine here, as long as you make a coherent argument to back them up. (E.g. "We feel that this system offers a superior experience for the user since it crashes less often than Microsoft Blurb.") Your discussion will be stronger if you give an honest comparison of your project to existing work. (E.g. "It is true that Microsoft Blurb offers better security than our system, but security was not our primary emphasis for this proof-of-concept implementation, and could be added at later date.")

Future Work: What are the next steps, either for you or for people who might build on your work?

Conclusion: Include some concluding remarks. Summarize and reiterate what you see as the key points from your writeup. Basically you're using the old "tell them what you're going to tell them, tell them, and then tell them what you told them" structure in the hopes that your point really got through.

Acknowledgments: This section is used to acknowledge the people or organizations that provided significant help or inspiration. It might not be relevant to your writeup. In the real world you'd thank the funding agencies that supported your work, the reviewers who gave feedback on drafts of the paper, and any other contributors. If you did an implementation project, you might consider acknowledging the authors of any packages or libraries you used, etc.

References: A properly formatted list of references. These can be construed fairly broadly in computer science — in addition to journal articles, books, and conference proceedings, papers often reference web pages, tutorials, etc. Note that this is different from a Bibliography, which lists things that you've read but that are not necessarily referenced in your paper. All of the entries in this section should be referenced at least once in the body of your paper.

Appendicies You might consider adding an appendix (or several) if you have tables of data, long listings of source code, or other supporting information that's too long to insert into the body of the paper, but that's relevant to your project. These will not be counted against the 8-10 page limit.

Your document should be proofread and highly polished when you turn it in. It should be something that you would consider submitting for publication without embarrassment. It's likely that these project writeups will find their way into the library's collection and appear online, so do a good job! You might consider getting students outside of your group (perhaps outside of CS) to read through drafts of your paper and give you feedback. Your submissions will be graded on both content and presentation so take both seriously. Your written document is due at the end of finals week on Friday, May 13th. If you are completing an implementation project, your code/system should accompany the paper so I can see all of the gory details. (Zip it up, or send me a link to GitHub, or whatever works.)