A major component of the course is a mini-research project. Students will work in a team of two to three members to propose and implement a solution that improves software reliability. The goal of the project is for you to gain hands-on experience as well as to explore something new that might advance the state of the art.
The project can be on any of the topics we covered in the course, i.e., static analysis, symbolic execution, model checking, etc. Topics outside the course syllabus may also work, but you should check with me.
The project should entail a substantial effort to design a solution and implement a concrete prototype. The prototype should be evaluated with real-world software systems and rigorously-designed experiments to demonstrate the solution’s efficacy.
In addition, you will need to write up a formal report like the papers we have read in the class to present the idea, the detailed design, the implementation, and evaluation. Please use the USENIX conference paper template to format your report.
The best outcome for a project that is well done is that it can eventually be suitable for publication at major systems conference. The minimum expectation for the project is that it should at least be interesting. In other words, even if the project may not yield a real publication, it should at least have some intellectual depth and research flavor that readers can learn something.
I will provide some suggested topics. But you are encouraged to come up with your own. You can also propose project that involves your current research with my permission. The course staff will meet with each group several times during the semester to help you refine the project.
In the proposal, briefly describe the following elements:
The proposal should be around 2 pages and include your group member’s name and email. The proposal only needs to be submitted by one of the group members.
In the middle of the semester, submit a checkpoint report (around 3 pages) to describe the status of your project, the solution you have built so far, some initial results, new challenges that you did not anticipate, any adjustments to your approach or plan.
The final report should look like a research paper. It motivates the importance of the problem you are tackling, potentially with some concrete evidence or data points, and why existing solutions do not solve the problem well. Then describes what you proposed idea is, what challenges need to be addressed, how you address the challenges, why your idea is better, what the technical details are. Then shows the experiment results, interpret the results, describe the observations and implications, conclude whether and how the results demonstrate your solutions’ superiority over state-of-the-art solution. Lastly, include a brief related work section to compare and contrast with your solution.
The final report should be around 6 to 10 pages (by the USENIX template format linked at the beginning). I do prefer reading concise and articulated reports, and believe papers do not need to be long to be good. If you can capture the essence of your project in fewer than 6 pages, that would be totally fine. A well-written shorter report will get a much higher grade than a report that is excessively/artificially long but with little substantial content. The key requirement is that the final report must comprehensively cover the points mentioned above.
Each project team will be given a slot to do a presentation in class to show the cool ideas and results to other students. A live demo of the system you developed would be a nice element of the presentation.
You will be required to turn in your source code and any documentation so that we can inspect it.