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.
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?
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.
Your proposal should be a short document (1-2 pages) with answers
to the following questions:
- Who's in your group?
- What's the goal of the project?
- What techniques will you be using (workload characterization,
measurement, modeling, analysis, simulation, implementation,
verification)?
- What's the minimum/maximum deliverable?
- What's your first step?
- 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.
You can think of the milestones as both status reports and
drafts of the final document.
Here is a process I recommend:
- After you turn in each milestone, I will discuss it with
your group, and you may want to make changes.
- At each milestone, you should be able to add 1-2 sections
to the report, and you might be able to outline the rest.
- 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.
- If there is information from a previous milestone that is
no longer true or no longer relevant, you should edit or remove it.
- At the end of each refinement, please include a section
named `Future Work' that describes what you plan to do next.
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.
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.
|