Software Systems
Fall 2006

Project Plan

This document describes the schedule for the class project. The primary deliverable for this project is the final report, which is due on the last day of instruction, December 12. Along the way, there are a series of milestones at which you will turn in drafts of the final report.

The most important thing to understand about this process is that the document you turn in at each stage of this process is a draft of the final report. At each stage, you will add new material and revise the existing material, possibly removing material that is no longer needed.

The target audience of the report should be someone who is familiar with the material of the class, but who may not be familiar with the specific organization and vocabulary of this class. For example, you could pretend that Andy Tanenbaum will read your report.

You can use any document-preparation software you like, but you will need to generate a final report in a format appropriate for archiving, preferably Postscript or PDF. Naturally, I recommend LATEX.

Schedule

Here is the schedule of deadlines:

  • October 12: Project proposal.

  • October 26: First progress report.

  • November 9: Second progress report.

  • November 16: Exam 2.

  • November 30: Draft of final report.

  • December 12: Final report due.

  • December 19-20: Expo?

Project shopping

We will have some time in class for people to present project ideas, with the goal of getting suggestions from the class and possibly finding people with similar interests to work with. You can also post messages on the class mailing list, software_systems@lists.olin.edu, either looking for people or ideas.

Project proposal

Your proposal should be a short document (1-2 pages) with answers to the following questions:

  1. Who's in your group?

  2. What's the goal of the project?

  3. What techniques will you be using (workload characterization, measurement, modeling, analysis, simulation, implementation, verification)?

  4. What's the minimum/maximum deliverable?

  5. What's your first step?

  6. What's the biggest problem you foresee or question you need to answer to get started?

You should turn in one copy of your proposal for each project group.

A note on style: The documents you turn in at various stages do not have to be complete, or polished, or formatted beautifully. But please don't take that as a license to make them incoherent, or verbose, or silly. You should try to present your ideas clearly and concisely, with the goal of producing a final report that you would be proud to show to the outside world.

Progress reports

You can think of the milestones as both status reports and drafts of the final document. Here is a process I recommend:

  1. After you turn in each milestone, I will discuss it with your group, and you may want to make changes.

  2. At each milestone, you should be able to add 1-2 sections to the report, and you might be able to outline the rest.

  3. As you obtain results, I recommend incorporating them into the report fairly early. You might find that when you explain your results in writing, you notice errors or see additional opportunities.

  4. If there is information from a previous milestone that is no longer true or no longer relevant, you should edit or remove it.

  5. At the end of each refinement, please include a section named `Future Work' that describes what you plan to do next.

Final report

Your final report should include the following elements:

  • An abstract that explains what you did. The abstract doesn't have to include much background material, but it should be comprehensible to someone who has not read your paper.

  • An introduction that presents background information necessary to understand your paper (with references) and explains again what you did, but with more emphasis on why you did what you did.

  • Presentation of your work. In many cases, there will be one section for each kind of work you did; for example, if your project involves a trace-driven simulation, you might have sections named Measurement, Workload Model, and Simulation.

  • Results. If you do more than one experiment, your results might be scattered around the paper, or you can pull them together in one section.

  • Conclusions. It is common to end a paper with a summary of the major conclusions of the paper. It should not be a summary of the paper, and it should not repeat material from the introduction.

  • Related Work. If there is prior work that is relevant to your project, you can cite it throughout the paper or you can discuss it all in one section.

  • Future Work. It is traditional to talk about additional work that could be done on your project, even if you have no intention of doing it.

  • Acknowledgements. Be sure to thank people who helped you.

Your report does not have to have all of these elements, and they don't have to be in exactly this order. You have some flexibility to adapt this structure to suit your project.

Expo

Depending on what else you are doing this semester, you might choose to present this project at Expo. If so, then each member of the team will make an individual presentation. You will have the option to present a poster or a short talk. In either case, you might want to start writing your poster/slides at the same time you are working on your final report.