Project

You will design and carry out a quarter-long research project (done in teams). I hope that these projects will Give you some first-hand experience with security, but in a topic of your choosing. Our timeline is:

  • 5/1: inform me of your group's membership. Groups should generally consist of 3 or 4 people. Your project partner will have a substantial effect on your experience in this course, so choose carefully.
  • 5/8: inform me of your project choice. This will be a brief description of what you plan on doing for the quarter.
  • 5/12: Milestone 1
  • 5/19: Milestone 2
  • 5/26: Milestone 3
  • 5/29 - 6/3: Project presentations. You can find more information about presentations in class.
  • 6/9 @ 12:30pm: Final project due.

Project groups should be 3-4 members. Any other group size needs explicit approval by the professor.

This quarter I am not going to give out project ideas. You are responsible for coming up with a project idea by yourself, but I encourage you to start this process early and to solicit feedback from me.

Github organization and content

The center of the project is your github repo this quarter. We are using github classroom to create repositories, and when you submit your project groups we’ll create a github classroom repo for your project. Each time you turn in something, you’ll turn in a link to a doc in your github repo.

  • proposal.md A markdown file that includes your proposal
  • milestones.md For everyone in the group include one sentence on each of these (1) what you did last week (2) what you plan to do this week (3) anything that you’re stuck on. Also include links to any PRs you committed or design docs you wrote.
  • design_docs.md A markdown file that includes a one sentence description of a design doc and a link to your Google doc. Please make sure that the staff can access your Google docs or else you will not get credit for it.

Proposal

Send us a paragraph about (1) what problem are you solving, (2) why is it important, (3) what do you plan to build, and (4) what are your expected results. Your proposal should be around 300 words (please don't go over) and your prose should be polished (make sure that it flows well and is free of spelling and grammar mistakes).

Meetings and milestones

We want you to meet each week as a group to coordinate with your group members. In this meeting for each member of the group you should discuss (1) what you did last week, (2) what you plan to do this week, and (3) anything you’re stuck on. These status updates should only take about 10 minutes total for the group and you should spend the remaining 20 minutes talking about some aspect of the project that needs further discussion.

One important aspect of your meeting notes is keeping track of action items and revisiting action items from previous weeks. As you meet, you’ll figure out what needs to be done, make sure that it’s clearly documented who’s doing what and make sure that you follow up about the previous week’s action items to make sure that things are getting done.

For your milestone, you will submit a link to your "milestones.md" doc in Github that contains your meeting notes that includes one sentence for each person and for each of the updates (last week, this week, blocked), plus links to pull requests committed for each person and any design docs you wrote.

In your "milestones.md" doc, please also include link to a three minute video that you created to go over your update. For the first video you'll do a summary of your project proposal, and for subsequent videos you'll discuss whatever we asked you to discuss during the previous meeting.

Design docs are an important aspect of your milestones and each group member needs to author at least one design doc and submit it to one of the three milestones.

Design docs

Design docs are a critical way to communicate technical information, especially as we are all remote this quarter. Your goal with a design doc is to introduce a problem and explain, from a high level, how you plan to solve it. Here is an example of a real design doc that I wrote personally. After reading a design doc, people should understand what you’re doing and why, and enough of the details of how that they would come up with a reasonably similar implementation. Note: if you find yourself including code snippets in your design doc, then you are going into too much detail. Keep the discussion at a conceptual level and leave code for your pull requests.

Your design docs should be 1-2 pages long, written in Google docs, have comments from your teammates about any clarifications / suggestions / discussions, and contain the following:

  • An introduction section, which is 2-3 paragraphs explaining the problem, from a high level, why it’s important and a sketch of the solution.
  • An overview section for your solution. Go into some technical details here, but keep things at a conceptual level.
  • A figure within your overview section to explain the main components of your system, the flow of information, or something else visually. Having a figure is absolutely critical and probably where you’ll spend most of your time (coming up with good figures is hard).
  • A public interfaces section. If you’re working on a server component this includes APIs that you’re going to expose, or if you’re working on a module this includes any methods that other components will invoke, or if it’s a stand alone tool then the inputs and outputs for this tool. The most important part here is that you’re going to be working with other people so then need to know how to interact with what you write, but they don’t need to know how you implement these interfaces.

Final presentation grading

For your final presentation, you will record a video describing your final project for the class. We'll provide details about what we expect in the second half of the quarter. We will dedicate some time in class for us to all view the videos together and then allow the authors to answer questions from the class live.
  • Clarity and quality of presentation
  • Ability to explain the problem and set the appropriate context
  • Ability to explain the system you built
  • Quality of the live demo

Final project grading

See slides from lecture for more details on what we're expecting. This quarter we're going to use slides and source code as the artifacts that you're going to turn in for your grade. We will grade you on:
  • Code quality. To get points you must include a README file in your repo that outlines the basic structure of your code and how the concepts from your project map to actual code. Also, we're expecting significant contributions in real source code from all group members.
  • Clarity and quality of explanation
  • How significant was the system you built. We've been giving all groups feedback on this during our weekly meetings, so I'm not expecting any surprises here.
  • Result. Basic results will get you most of the points, but we're reserving a few points in this category for exceptional results.

Project meetings

We will have 2-3 project meetings this quarter. The purpose of these meetings is to get feedback from the staff on your project. Meetings are 10 minutes long and at least one group member needs to be present for question and answer. The general flow of the meeting will be:

  • Watch the 3 minute video that you submitted in your milestone doc.
  • 3 minutes of Q and A with Sam -- he'll ask questions about your project
  • 2 minutes of Q and A with the TAs -- they'll ask questions about your code.
  • 2 minutes for the staff to take notes before the next meeting.