Course Project

Collectively, the project accounts for almost half of the course grade. That would suggest to me that one should read this page closely.

Overview

The intent of the course project is to provide deep, hands-on experience with a storage topic interesting to each student. The class will separate into groups of two or three. The timing and grading weights for the different parts of the projects are given on the course page.

In general, groups will base their project on the two "Program" assignments that take place in the first half of the course. However, where you go from this base is up to you. Your project must take the basic concept of a filesystem or block device driver and add functionality that addresses one (or more) of the following questions:

• How can I improve the availability and/or recoverability of this storage?
• How can I make this storage network-accessible effiently?
• How can I improve storage efficiency?
• How can I improve performance?
• How can I improve security?

To get ideas for projects, some lecture time will be devoted to an "overture" summary of topics that will be covered later in the course.

Groups will submit an proposal draft that describes their project and how it will be achieved, including detailed plans for two milestone deliverables. Groups will also, at this time, schedule time with the instructor to discuss the proposals.

Groups may need to alter their project plan (or even abandon it for something else) based on feedback at this stage. A finalized proposal will be submitted after this revision process.

Work will then proceed in depth on the project. Students must aim to have two measurable, demonstrable units of work—milestones—as evidence of consistent effort over time (the key to success). Unlike most artifacts in the course, milestones will be due at 8am (though can of course be submitted sooner). That day, the usual lecture will be replaced by a project work day, in which the instructor will meet with groups individually (1) receive an informal demo of the milestone and (2) to offer feedback and advice. Attending work days is mandatory — this is how I grade milestones and track individual student contribution and project health!

Finally, when the project is complete, there will be three forms of deliverable:

• First, all project materials as well as a written report will be turned in.
• Second, groups will present a final presentation to the rest of the class on their project.
• Third, groups will schedule an out-of-class final demo to the instructor, which will allow greater depth of discussion.

Each stage of the project will be motivated by a "business scenario" -- a situation in a corporate environment that would lead to the deliverable being asked for.

Note: At any stage, the instructor may opt to require resubmission or a change of plan. This is independent of the grade for that stage, as the cause could be quality (submission was incoherent) or content (submission was coherent but the design expressed was infeasible).

The precise requirements for each of the deliverables are described below.

Proposal draft

Business scenario: You're an individual contributor on a technical team at a storage company. You have an idea you'd like to pursue outside your normal job responsibilities, and are pitching to your manager for approval and perhaps even budget.

The proposal consists of:

1. A brief write-up (3-4 pages) that describes the project.
2. A 60-minute meeting with the instructor to present and discuss the proposal. In the meeting, a 5-10 minute presentation is expected, followed by discussion. NOTE: See "How to schedule meetings" below.

The proposal should answer the following questions:

• What will be built? What is the high-level architecture? The most basic design questions should have been answered by this point (e.g. language, platform, algorithm, etc.).
• What will be the criteria for success? Be specific. Include a high-level description of your test plan, including what kinds of testing is needed (unit, integration, performance, etc.)
• What are the major risks and unknowns involved?
• Do you need extra hardware resources? (Reasonable hardware requests can be granted for projects)
• What is the exact timeline for the project?
  • The schedule must include, in detail, two milestones you plan to demonstrate during project workdays later in the semester (see course calendar for dates).
  • Be sure to identify the new skills will need to be developed to complete the project, and include the time to learn these skills in the timeline.
  • If your team server is being used, consider how its use may conflict with course lab assignments -- note this in your timeline.

Grading for this deliverable will be based on:

• Completeness of proposal versus the questions above.
• Clarity of write-up.
• Professionalism of presentation.

Independent of the above, receiving feedback that alters the project will not bear a grade penalty. It is expected for students to be new to the subject matter, and to potentially need significant guidance in honing their projects at this stage.

Tip: Structure your written proposal for rapid readability: brevity, diagrams, bullets, and tables are preferred over long paragraphs!

Proposal, finalized

Based on feedback received, you will update your proposal. The structure is the same, but the bar for quality and completeness is raised. Grading for this deliverable will be based on the attributes from the initial proposal as well as:

• Successful incorporation of initial proposal feedback.
• Feasibility of the presented plan.
• Correct use of the concepts covered thus far in lecture.

It is possible that you may receive further feedback at this stage.

Milestones and workdays

Business scenario: What once was a small organic project within your team has gained major visibility in the company. Marketing is advertising it on customer-facing roadmaps and sales is talking it up to customers. You'll need to show your progress to your manager and interested stakeholders periodically to assure them that you're on schedule and will produce a high quality product, as well as to accept feedback from technical mentors to help ensure success.

As described above, you'll need to show off two milestones of measurable progress at certain points in the semester. The exact technical content of these will depend on what was agreed to in the proposal stage.

Deliverables: On the morning of the milestone deadline, you'll submit your technical artifacts (code, documentation, performance data, etc.) and a milestone writeup that captures:

• Progress to date
• Changes to the schedule established in the proposal, with discussions of any shortfalls or changed designs
• A brief summary of each team member's specific contributions

Workdays: I want you to be successful in this project, on the due date of each of the two milestones, we'll suspend lecture and use the time as a work day, during which you should be prepared to demonstrate your milestone progress. This will ideally involve a software demo, review of performance data, or other hands-on evidence of progress. Also come prepared with questions and concerns to discuss -- this time is provided help you! Because the instructor will be meeting with each group separately, you'll be on your own during much of the class session, so use this as guaranteed group meeting time to get stuff done. You can also use this time to collaborate with other groups if you wish.

NOTE: Workdays are not optional!

Be honest, please! If things are progressing differently than you expected, don't hide that! Just report honestly what's going on. If things are looking bad, contact the instructor proactively to propose a revised timeline. Having honest difficulty with new subject matter is not grounds for a bad grade. However, misrepresenting progress will be penalized, as will failing to take proactive steps to correct or revise a schedule that is slipping constantly.

Tip: These milestones and workdays are for your benefit -- past students asked for more structure to avoid a big rush at the end. Don't fight the structure, use it to remove risk and stress from the project.

Final report

Business scenario: A project isn't complete until it's documented. Explain your work in detail for future colleagues to build upon.

This report will, in a maximum of 8 pages, describe the results of your efforts. Below is a reasonable outline for this document.

• Introduction: What is the problem or market you're addressing?
• Design: What is your approach to the problem? Discuss your design in depth. Diagrams are likely useful here.
• Implementation: Describe your implementation fully, making sure to start at the beginning (language, platform, etc.).
• Evaluation: Conduct a study to evaluate how well your system fulfills its goals. Also include a performance study featuring appropriate benchmarks. Be sure to discuss WHY the numbers are the way they are. If you get disappointing results, discuss those too (don't hide them!).
• Conclusion: Summarize the key benefits and tradeoffs of your system. Describe potential avenues for further improvement if you were to continue on the project.

Grading for this deliverable will be based on:

• Completeness versus the above.
• Clarity.
• Correctness.

Note: actual health and quality of the project will be assessed in the demo to the instructor (see below).

Tip: Less is more -- look for ways to shorten this document while still covering everything you need to.

Final presentation

Business scenario: You've completed your project, and in the time you've been working, visibility of your once-small project has ballooned into a departmental priority. Product managers and executives are suddenly claiming indirect credit for the work, and you've been asked by the senior director from earlier to present your work to the departmental senior staff meeting chaired by the executive vice president of engineering. Don't screw up.

The final presentation consists of a 15-minute presentation to the rest of the class (plus time for Q&A). The presentation should answer the following questions:

• What is the problem or market you're addressing? (in the scenario, you're presenting to a broader audience, so start at the beginning).
• What is your approach to the problem? What is you design?
• Describe the implementation process. Have any major changes been incorporated since the proposal was finalized? How did the project proceed compared to the timeline presented in the proposal? Explain any differences.
• What were the most challenging problems encountered? How were they solved? What limitations still exist in the project?
• Evalute your project in terms of its core goals as well as its IO performance.
• DEMO: SHOW US WHAT YOU GOT.

This overlaps the report described above somewhat, but whereas the report discusses the final product, this presentation is focused more on the implementation process.

As before, you likely want to cover the first bullets quickly so as to maximize time for the good stuff, your demo.

Grading for this deliverable will be based on:

• Completeness of the presentation versus the questions above.
• Professionalism of presentation.
• Smoothly staying within the time limit.
• Correct use of the concepts covered in lecture.
• Successful incorporation of feedback throughout the project.

Note: actual health and quality of the project will be assessed in the demo to the instructor (see below).

Tip: We're looking for a high degree of polish on this talk. Use this chance to impress!

Final demo

Business scenario: With your project complete, the technical director of your group has asked you for a technical deep dive. Unlike the presentations thus far, the technical director is concerned with a getting deep understanding of your work in order to assess its merit as the basis for a major product or initiative at the company. Expect detailed discussion and difficult questions.

The final demo consists of a 60-minute meeting with the instructor (15 minutes for talk+demo, then interactive Q&A). The instructor will send directions on how to sign up; if he has not yet done so, ask. In this meeting, your project will be put through its paces, code will be inspected, trade-offs will be debated, etc. It can basically be thought of as a defense of your work against scrutiny.

Grading for this deliverable will be based on:

• Completion of objectives laid out in proposal and outline.
• Technical merit.

Tip: Do a really good project.