Tue Apr 22 10:54:48 EDT 2008
This page describes in more detail the requirements for Demo Days on May 8-9, what you have to submit by Dean's Date, May 13, and how grading will be done. There may be minor changes but nothing of substance.
Demo schedule updated: May 8-9.
Apr 1 2 3 4 5 6 7 8 9 10 11 12 project prototype 13 14 15 16 17 18 19 20 21 22 23 24 25 26 alpha test 27 28 29 30 May 1 2 3 last class; beta test 4 5 6 7 8 9 10 project presentations 11 12 13 14 15 16 17 5/13: Dean's date; projects due 5pm 18 19 20 21 22 23 24 someone must be around in case of trouble
Leaving aside the prototype stage, which is nominally this week, these are the stages that remain. Notice that there are only 4 weeks to the demos and 5 weeks to Dean's Date.
These descriptions are not formal requirements but are meant to provide guidance about how far along you ought to be.
Project demos will happen May 8-9, some in CS 105 and some somewhere else, and probably mostly in the afternoon. Each team will give a 30 minute public presentation of their work to Bill, Anirudh, Jia, me, and anyone else who cares to attend. Each group is required to attend one other presentation and you are strongly encouraged to attend more, for edification and moral support. Visitors are welcome, so bring your friends and family. I'll post a signup sheet for demo slots during the last week of classes.
You can divide the presentation responsibilities any way you like; there is no need for everyone to speak, but all team members must attend.
These demos will determine a significant portion of your grade, so you (and we) want them to go as smoothly as possible. In order to assure this, start thinking about your demo now. You could picture your demo as a presentation that will make or break your "company" -- you'll be on the spot in a foreign place, with an audience. You might think of the audience as a group of very supportive potential customers or investors, or as friends and family.
What should you cover in your presentation? That's entirely up to you, but it might include an overview of what your system does and why it was worth doing; what's in it, how it was constructed and how it works; a demo of its most basic or interesting features; and maybe a bit about what you learned and what you might do next. Leave 4 or 5 minutes for questions at the end.
For the demo, what kind of hardware and software and network access will you require? One solution is to install your project on a laptop that one of your group members owns. (This is a good chance to check out your installation procedure.) The room will have a computer projector, an overhead projector, and wireless access.
Whatever you plan to use for your demo, you should still be able to present if something breaks. Murphy's Law applies to all of us: bring along something that you can use in an emergency.
Your final submission will have to include
Here is what you will have to do
(subject to minor refinements over the next couple of weeks):
Submission:
Collect everything for submission in one place.
Documentation:
The documentation must include the following:
All documentation other than your seduction web pages must be in
straightforward HTML that works with Firefox. It should
be written in good English, free of spelling and grammar errors. It
should be thorough but not exhaustive; the total submitted documentation
should not exceed about 15 printed pages. The report is the most important
single piece of documentation. I am particularly interested in
thoughtful and interesting reports, so don't skimp on this part. (I
prefer reports that speak for the whole group with a single voice, not one part
written by each team member, but this is not mandatory.)
A working system: We will be experimenting with your system
starting on Dean's Date, so you must provide access
to a running version. If the system is web-based, make sure it's up
and running and we have whatever passwords and other controls
are necessary to play with the system; that includes administrative
rights if part of the functionality involves administration, though we
will try to be very careful not to intrude or to break things.
If your system is meant to run standalone on Windows or Unix or
whatever, you can include a zip file or tarball that contains all the
necessary files, along with any project files for the compiler you
used. In this case, be sure to include installation instructions.
You should test carefully to ensure that someone not in your group
can exercise all aspects of the system, working only from the
information in your submission.
It will be a great help if you follow these directions and try to
make it easy for us to look at and play with your project. If things
go well, we tend to be happy; if things go badly, we get grumpy.
Happy graders tend to give better grades.
May 13 (Dean's date): Final submission
Everything must be submitted by 5 PM on this date, without exception.
Be sure that your code is complete after it is copied to the
submission directory. We will be reading through your source code
to get an idea of what you did and how well it was done, so everything should
be there.
cd submission_directory
tar cf ../jdoe.tar .
cd ..
gzip jdoe.tar
submit 6 jdoe.tar.gz
Grading
(This part is definitely subject to fiddling.)
The project is worth about 65 percent of the overall course grade.
Every team member gets the same project grade except
for a small discretionary component in the unlikely event
of significant dereliction.
The project grade will be derived from considerations like these:
Important:
We will be experimenting with your system starting early May 14, so it has to
stay up through May 19 and someone has to monitor it and
respond to mail promptly in case we have trouble. Thanks.