Project Report

Your final project report will be in the form of a workshop paper submission using the template provided here.

The paper should be 10-12 pages in length when completed (that isn’t as long as it sounds when you consider figures, charts, and tables take up space as well). You will more than likely end up generating a lot more than this if you do a good job on documenting all aspects of your project.

Your target audience is other researchers who want to build on your idea, either by continuing your work or doing a similar deployment or domain-based project. They would need to understand why it is interesting, why your work will save them a lot of time, and how to reconstruct your project. Documenting the design decisions you have made along the way – both why you picked one particular alternative AND why you rejected others, is an important part of this. It would be especially nice if tutorial information about specific devices, software, and/or interfaces and how to deal with them is placed in a separate appendix so it can serve as a handy reference. You will definitely receive extra credit for a great job on this.

Below is a basic outline of the report that you should use as a guideline. Please do your best to cover all the points listed.

Abstract. Short description of your project, what you accomplished, and what conclusions you were able to draw. This should be in the range of 250-300 words.
Introduction. Problem description including a typical scenario of use. What problem does your project try to solve? What is interesting or hard about this problem? What do people do now? What is your basic idea and how will it make things better? This section should include a figure or two and be approximately 2 pages.
Related Work. What have others done - both closely and loosely related? It is important to make sure you do a good job of this and draw upon a wide range of information sources including conferences and journals in the area, magazines and popular press, newsletters, and, of course, web searches. Feel free to build on what was done in Winter quarter but go further. In particular make sure you do a survey of related technologies, not just research projects. This is where the bulk of the citations will be and should be about 1 page clearly explaining why these other works were not enough to solve the problem.
Approach. How are you going about realizing your idea? What are the main pieces? Why did you choose these pieces? How do they interact? How generally reusable will these pieces be? This should be a fairly large section with several figures and should probably run about 1.5 to 2 pages.
Implementation. Describe the choices you had to make that were not obvious. What was hard about getting things to work? What tradeoffs did you have to consider? You also want to talk about how things could have been implemented better if you had more resources or more time. This section will also be about 1.5 to 2 pages and should include figures about the data flow and final design.
Evaluation. How are you evaluating your solution? Evaluation has both technical aspects as well as usability aspects. Who are your target users and who did you use as surrogates? How well does it work? Use both qualitative and quantitative approaches and relate the evaluation back to the scenario. Another 1.5 to 2 page section.
Conclusion and Future Work. What are the next steps to take and why? What lessons did you learn? What would you differently next time? How could the solution be improved upon further? This section can be short and should recap the paper and back up the claims made in the abstract. It is only about a page in length.
Acknowledgements. Who helped you along the way this quarter and how?
References. Everything that helped you understand the issues including: papers, magazine articles, data sheets, web resources, interviews, surveys, etc. Make sure they are all cited in the body of the paper. These could easily run up to a page.
Appendices. All the material you might need to reconstruct your project: source code, schematics, installation and configuration instructions, etc. (NOTE: this does not have to conform to the template provided and can be in the most appropriate format to make it easiest to use).

The paper’s .doc file and files for the appendices should all be packaged into a .zip file with a README file included to explain the purpose of each file included.