The course project is an opportunity to apply software security skills to new settings. The purpose of the project is to demonstrate that you can synthesize skills from the class and apply them to a new domain. You will be graded primarily by how well you do thinking about problems, understanding the issues involved, formulating a research plan, and executing on your plan. While many students choose to explore new (i.e., publishable) ideas, you can also do quite well by analyzing, evaluating, and understanding the limits and key concepts of existing research.
The projects can be done in teams of up to 3 students. All students in a team will receive the same grade.
In order to provide feedback throughout the course, as well as make sure everyone is on track, there are 4 phases in the project which serve as graded checkpoints.
In addition to the core research, the projects also give students practice with the mechanics of writing research papers and presenting research results. As such, we have developed a few requirements for writing about and presenting your work.
All written documents must be prepared using LaTeX. LaTeX is the standard way to typeset research in computer science. We provide a template under the resources page you can start with if you wish.
When writing, students should strive for clarity. I have found no better way to write an introduction that to follow the advice offered by Jennifer Widom's Tips for Writing a Technical Paper on the resources page. I stress that the final paper should "look and feel" like the research papers you have read throughout the semester. In particular, proofread. A well-written report will follow the advice from "The Elements of Style" by Strunk and White, e.g., you should use the active voice, make each paragraph a single idea, and so on. Further, you should make sure everything you say is correct. While this might seem like it goes without saying, it is very easy to write something you do not mean to say.
All presentations should again strive for clarity. As a presenter, you should take full advantage of the visual medium to communicate your ideas simply and effectively. As a wise man once said, if you can't state something so that a 6th grader can understand it, you don't really understand it.
There are several iterations to this project. You should address any comments I may have at each successive iteration. Type-o's, stylistic problems, etc. are all easy to solve, and shouldn't appear in successive drafts turned in. If you have questions, you should schedule a time to meet with me. I really do consider at how much effort people put in when deciding a grade.
The first checkpoint for the course project is to think about a project topic, do some background reading on the general field, and propose a general direction. The main direction is for you to commit to a particular problem.
The paper should be organized into the following sections (some may be blank for now):
- Introduction (see resources, especially Tips for Writing a Technical Paper, by Jennifer Widom)
- Related Work
- The main section describing the design/approach/etc. in detail. The actual section title is up to you (and there may be multiple sections if necessary. You should mimic other papers in the area.).
- Implementation. This should look like the implementation section of an academic paper; not a manual for running your tool.
- Discussion and Future Work
- References (I suggest using BibTex to manage this)
Deliverable::The deliverable is the PDF, which should be turned in on blackboard before class, as well as bringing a printed version to class. The writeup must be written in LaTeX. Spelling and grammar errors will count against you.Phase 2
The second checkpoint is a form project proposal. The project proposal should include the following points:
- What is the overall problem setting and specific problem.
- What are the current approaches and major works in the area.
- What is insufficient or could be improved for these works
- What is your projected milestones and timeline for the project
Deliverables: There are two. First, you should prepare a powerpoint presentation that lasts 5 minutes describing the problem and your approach. Do not underestimate the time it takes to make a good report that is short. Some times are on the resources page. Second, you should turn in an updated PDF to Blackboard, as well as give me a printed PDF, all before class.Phase 3
In the phase 3 checkpoint you should extend and resubmit your writeup from phase 1 and 2 with the new work. You should turn in a writeup, similar to Phase 1. You should also address any concerns raised from the phase 2 feedback. At this point I will be looking for some promising signs of real results, e.g., you can answer questions about trivial cases, have figured out basic prototype code if necessary, etc.
Deliverable. Turn in a PDF on blackboard before class, and bring a printed PDF to class.Phase 4
In phase 4, you will extend and resubmit your phase 3 writeup to include your latest results. The main purpose of this checkpoint is to stave off any last-minute problems. I will also try and tell you what grade I would give if your phase 4 writeup was your final submission. For example, a student on track to have an A will have preliminary results, have a full writeup of the introduction, related work, and main techniques, and have preliminary (but not necessarily final) results filled in.
Deliverable. Turn in a PDF on blackboard before class. When I return your phase 4 submission, I will tell you what grade you would get if this was your final submission.
The final report should look like a real research paper.
Deliverable: Please turn in a PDF to blackboard, along with any relevant source code. The final report is due before the time of the CMU scheduled final. There is no need to give me a printed copy.