Project Format


The goal of the project is to encourage students to explore some aspect of the applications of software engineering techniques in building or evaluating distributed systems, middleware or operating systems. You have the freedom to propose any project you wish, but with respect to the following guidelines: 1) the work should be in an area related to the general background of this course( please refer to the topics of each week for a general scope), 2) the work should be completed in less than three months, and 3) you should talk to the instructor and get agreement about a project before committing to it.

Students have three project options: 1) implementation and evaluation of a system, 2) evaluation of an existing system, or 2) writing a position paper. For the first two options, a maximum of 2 students can collaborate on the project and the students should structure the project so that every individual can be evaluated. The third option is for individuals and described in detail later.

Each project has the deliverables described below. These deliverables are per-project (not per-student). Note that each future deliverable contains much of the contents of the previous deliverables. However, the final report should be organized like a research paper.

  1. Project Description: 1 page (Due March 5th, 2009)


  2. Status Report: 3-4 pages (Due April 4th, 2009)


  3. Final Report: 8-10 pages (Due May 16, 2009)

The deliverables must be in a format similar to a research paper. For example, the final deliverable should have an introduction, related work, the main body of the paper, evaluation, conclusions, etc. Please use the following formatting guidelines while preparing your report:

At the end of the term, there will be a presentation for each project or position paper. The date for this presentation will be announced in class.

Position paper

The third option, the position paper option, is for individuals, and it does not require an implementation. Students should pick an area related to the topics discussed each week. First, they should conduct detailed background research and cover as much literature as possible. Then they should compare the approaches and discuss the benefits or drawbacks of each. Finally they should come up with their "position". Your position should be a novel statement based on solid background research and sound judgement that you articulate clearly. Your position should not be obvious from the papers or background research. In other words, the position paper option encourages research (and not just a survey of previous work). With this option, it is not essential that a student implement or evaluate a system. However, the grading will be stricter regarding the quality of the final report and the novelty of the idea.

There are three main differences in the deliverables with this option compared with the previous two options: 1) there may be no implementation and evaluation, 2) the background research should be more thorough, and 3) the focus of the paper should be on the details of your approach which should clearly justify your position, i.e. your novel statement. Think of this option as a proposal for your research. If you are already conducting research in an area that is related to dependability in systems, this option is a great way to force yourself to put your thoughts clearly on paper. If you are not conducting research yet, it will help you get started. This option is not recommended for Non-research-track students.


Project presentation schedule

  1. May 5th: Capturing precise program coupling(Liu Peng)
  2. May 5th: Implementing Design Patterns With Advanced Programming Languages: An Exploratory Study (Wong Kin Man)
  3. May 7th: Replaying concurrency related Java crashes(Huang Shaoming)
  4. May 7th: The evaluation of XML-RPC(Tang Yi Lun)
  5. May 12th: Incremental Execution of MapReduce -- Resuming from Faulty Jobs (Li Yue Qi)
  6. May 12th: Incremental Execution of MapReduce -- Resuming from Faulty Jobs (Zhu Lin)
  7. May 14th: Implementation and Evaluation of Different Concurrency Patterns (Zhang Wei)