Introduction

At the end of the course you will be 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 more formal writing.

Your final report should be written in LaTeΧ, and conform to the ACM SIG format. Your LaTeΧ code should have the following line, for its document class:

\documentclass[sigconf,nonacm]{acmart}

You are responsible for finding the proper LaTeΧ files to make this work (though they should be available by default on Overleaf). For a full team of 4, the document should be between 8 and 10 pages, including all figures and references. You may make the document 1 page shorter, for every “missing” team member you have below 4. (For example, a team of 2 may make their document as few as 6 pages long, if they desire.)

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 discovered and the significance of that discovery. 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 as much as 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.

• 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 / Methods: 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 & 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. This will be substantial in a research report, but less so for an implementation project. The references 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.
• Appendices: 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:

• quality of the underlying project
• paper content
• presentation

Please take all of these seriously.

Useful Links

Here are some links that might help, when preparing your paper.

• “How to Write a Paper in Scientific Journal Style and Format”
• “Writing Research Papers”
• “Writing Technical Articles”
• “A Guide to Writing a Successful Paper”
• “Fourteen Steps to Writing an Effective Discussion Section”

Presentation

You will have 20 minutes on Saturday, April 29th in order to present your project to a wider audience. The presentations are open to the wider math and computer science community.

Your presentation should be a preview of what is contained in the paper. It is assumed that you will use slides or some other method of electronic presentation. It should address the following points:

• Be sure to set up your problem; why is it interesting in the first place? Is it filling a particular need? Are you answering a question in which you have personal interest? Has anyone else done work in this area in the past? Try to make the audience care about your project.
• What approach did you take to solve your problem? Trace through your thought process when you went about executing your project. Explain the methods and tools that you used, and your rationale for using them.
• Did it succeed? Almost no project is going to be 100% successful. Try to explain both the areas where you succeeded, and where you did not. Also explain the standards that you used to judge your project, and why you think they are worthwhile. Finally, you might explain where you would go from here if you had more time to work on it.

When designing your presentation, try to avoid any slide that is entirely text or entirely image(s)—use the two to complement each other. Finally, if you are able to do so, a working demonstration can help sell your product far more than static slides can.

Team Reports

Finally, it would be a huge help if you write me a personal e-mail indicating how working with your team went. Indicate if you feel that you or one of your teammates did more than their share of the work, or if you believe that one of your teammates was slacking off. (Of course you do not need to do this if you were on a “team” of one.)