Research Project

The main component of this course will be an original research project.

Students will organize into groups and choose to implement a project that is:

  • Relevant to the topics discussed in class,
  • Requires a significant programming effort from all team members, and
  • Unique (i.e., two groups may not choose the same project topic).

The projects will vary in both scope and topic, but they must satisfy these criteria. Students are expected to address a novel problem or address an existing problem in a novel way. Students should actively consider submitting a paper at the end of the course to a top-tier conference in data management (SIGMOD, VLDB, etc.).

Each project group will present their project proposals to the class to get feedback from their peers. They will then meet individually with the instructor afterwards for additional discussion and clarification of the project idea. Late submissions will not be accepted.

Project Ideas

Projects typically fall under one of these categories:

  • Novel problem / task/ application.
  • Formulation: formulate a new model or algorithm for a new/old problem.
  • Application/survey: compare a bunch of algorithms on an application domain of interest. These make most sense if you are expecting some interesting trend or finding in the analysis.
  • Analysis: analyze an existing algorithm.

Collaboration

Everyone has to work in a team of two people (depending on enrollment). Groups are allowed to discuss high-level details about the project with others.

No more than 15 teams in the class total. You may combine this with another course project but must delineate the different parts.

Project Milestones

Each project is comprised of several tasks that are due at different times during the semester:

  • Proposal Meetings: (Week 3) Each group will meet with the instructor to discuss their plans for the project.
  • Proposal Presentation + Report: (Week 4) Each group will present their project topic to the class.
  • Project Status Meetings: (Week 7) Each group will meet with the instructor to discuss their plans for the project status update presentation.
  • Project Status Update Presentation + Report:(Week 8) Each group will provide a brief update to the class about the current status of their project.
  • Code Reviews: (Weeks 6, 10) Each group is required to review the code of another group and provide feedback on system architecture, correctness, coding style, and assumptions.
  • Final Presentation + Report:(Week 12) Each group will present the final status of their project and submit a technical report along with the relevant source code and documentation.

Each group must use a single Github repository for all development.

Proposal Meetings

Each group will meet with the instructor in private to discuss about project ideas. This will be a preview of the group's project proposal presentation in the subsequent class.

Proposal Presentation + Report

Each group will need to turn in a three page project proposal. This proposal should contain the following information:

  • What is the problem being addressed by the project?
  • Why is this problem important?
  • How will the team solve this problem?
  • How will you validate your implementation?
  • How will you evaluate its performance?
  • What resources will you need? (e.g., software, hardware, data sets, or workloads)

Your proposal should also provide three types of goals: 75% goals, 100% goals, and 125% goals. Think of these as the equivalent of a B grade, an A grade, and a "wow!" grade. The goals can be dependent or independent of the prior goals. Each group can meet individually with the instructor afterwards for additional discussion and clarification of the project idea. Each group should submit their proposal report to the course email address.

In addition to the written proposal, you will also present your project idea to the class in order to receive feedback from your peers. This proposal should be to convince the class that your idea will pertain to the course, that you will be able to complete it, and that we will be able to evaluate it. Each group should send their slides to the course email address.

Project Status Meetings

Each group will meet with the instructor in private and discuss the current status of the project. This will be a preview of the group's status update presentation in the subsequent class. Students should bring up any unexpected challenges or issues with their project implementation.

Project Status Update Presentation + Report

Each group will need to turn in a six page interim report and provide a brief update to the class half way through the project on the the current status of their implementation. You should update the introduction and motivation based upon feedback from your proposal and any changes you've made as a result of your research so far. A re-iteration of your proposed goals, with explicit discussion about what progress you have made to date on those goals and what your time-line is for accomplishing the rest of them by the end of the semester. A well-filled-out background and related work section citing the appropriate work from the literature. A sketch of your evaluation section outlining your evaluation plan and listing (as simple as an itemized list if you wish) the major components you plan for your evaluation. Feel free to include additional material in your interim report: If you wish to include, e.g., your design section or preliminary results, we will give you feedback to help ensure that your final report is great.

The project status update presentation should contain the following information:

  • An overview of the development status of their project as related to the goals discussed in the initial proposal.
  • Any information about whether the groups' original plans have changed and an explanation as to why.
  • Commentary about any surprises or unexpected issues that the group encountered during coding.

The goal of this exercise is to make sure that everyone in the class is aware of what the other groups are working on and how far along they are in the process.

Code Reviews

Each group will be paired with two other groups and provide feedback on their code. The development group (i.e., the group that implemented the project) will provide the reviewing group with a brief summary of the files they want the reviewing group to examine. The reviewing group will later post their pull request URL on the course spreadsheet.

Review #1:

Pull Request Date: Oct 8 @ 11:59pm
Review Date: Oct 15 @ 11:59pm
Code Review Due Date: Oct 24 @ 11:59pm

Review #2:

Pull Request Date: Nov 14 @ 11:59pm
Review Date: Nov 21 @ 11:59pm
Final Code Drop Due Data: Dec 5 @ 11:59pm

The Pull Request Date due date is when the development group should provide the reviewing group their pull request. The Review Date is when the reviewing group must complete their review and provide feedback. The development group will then have until either the next Code Review due date or the Final Code Drop due date to update their project in response to the last code review.

The code reviews do not need to be all done exactly on the due date but they must be done by the due date. The groups are free to schedule with each other when they are ready for the review. The grading for this will be based on participation in terms of both providing a useful review to other students as well as incorporating the feedback into their implementation. The review will be completed on Github.

Each group should consider the following questions when examining the code:

General Questions:

  • Does the code work?
  • Is the code as modular as possible?
  • Is there any redundant or duplicate code?
  • Is all the code easily understood?

Documentation Questions:

  • Do comments describe the intent of the code?
  • Are all functions commented?
  • Is any unusual behavior described?
  • Is the use of 3rd-party libraries documented?

Testing Questions:

  • Do tests exist and are they comprehensive?
  • Are the tests actually testing the feature?

Final Presentation + Report

Each group will need to turn in a ten page final report. During the scheduled final exam period for the course, each group will do 10 minute presentation on the final status of their project. This presentation should contain the following information:

  • A re-iteration of your proposed goals, with explicit discussion about what progress you have made to date on those goals.
  • A discussion of how you tested the correctness of your implementation.
  • A discussion of the experimental results that the group collected to evaluate their implementation.
  • An outline of concrete tasks for future work to expand or improve your implementation.

Formatting Guidelines

All reports should be written using the following format guidelines:

  • Double-column
  • Single-spaced
  • 11pt font
  • Reasonable margins

I suggest that you write all of your documents using LaTeX. It is the de-facto tool in which most CS research papers are written. Although it has a bit of start up cost, it is much easier to collaboratively write complex research papers using LaTeX than with Microsoft Word. You can use the ACM SIG Proceedings Templates alternate Latex style for your reports.

Credits

The above ideas are graciously borrowed from the database systems course developed by Andy Pavlo.