Tue Apr 7 13:15:46 EDT 2015
This page describes in more detail the requirements for Demo Days on May 5-8, what you have to submit by Dean's Date, May 12, and how grading will be done. There may be changes but nothing that will make a huge difference, and there will be warning.
Apr 1 2 3 4 5 6 7 8 9 10 11 project prototype 12 13 14 15 16 17 18 19 20 21 22 23 24 25 alpha test 26 27 28 29 30 last class May 1 2 beta test 3 4 5 6 7 8 9 demo days 10 11 12 13 14 15 16 Dean's date: projects due by 5pm 17 18 19 20 21 22 23 someone must be available in case of trouble
Leaving aside the prototype stage, which is "due" this week, these are the stages that remain. Notice that there are 4 weeks to the demos and only 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.
Demos will be held May 5-8 [probably] in CS 105, between 9:00am and 5:00pm. Each team will give a 30 minute public presentation of their work to the TAs and me, and anyone else who cares to attend. Each person is required to attend three other presentations and you are strongly encouraged to attend more, for edification and moral support. Visitors are very welcome, so bring your friends and family; I will invite people as well. A WASS signup sheet will be posted soon.
You can divide the presentation responsibilities any way you like; there is no need for everyone to speak, but all team members must attend and be prepared to answer general questions about the project.
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, though the audience is really just a group of very supportive friends and family, and maybe some potential customers and investors.
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? It's probably easiest to use your own laptop. The room has wireless and the usual computer projector. (Depending on the room, we might be restricted to a 1024 x 768 projector. Be prepared for a smaller screen size!) If you need cellphone coverage, make sure it works. We don't have a way to project from or display cellphone screens.
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: be ready to wing it in an emergency.
Your final submission must include
Here is what you will have to do
(subject to refinements over the next couple of weeks):
Submission:
Collect everything for submission in one place.
Documentation:
The documentation must include the following web pages:
This page should also link to your project's home page, which
presumably includes a product description, screen shots, tutorial
sequences, etc. This is the part that explains to potential customers
or users what's neat about your project. The content and format are up
to you, but try to make it informative and seductive. One possibility
might be to organize it around user scenarios like those in your design
document.
Documentation 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 10-12 printed pages.
The report is the most important piece of documentation. I
am particularly interested in thoughtful and interesting reports, so
don't skimp on this part, though I think an upper limit of 6-7 pages is
about right. Reports that speak for the whole group with a single voice
seem to work out better than those with one part written by each team
member, but it's up to you.
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 break things. (We will still worry about
external security vulnerabilities like SQL injection, of course.)
If your system is meant to run standalone on Windows or Mac OSX or
whatever, you can include a zip file or tarball or a Dropbox link 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.
I don't yet have a good plan for how to deal with
iPhone or Android projects, since we have only some access to such systems.
It may be necessary
for someone to loan us a phone for a short period some day.
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 will be happy; if things go badly, we will get grumpy.
Happy graders tend to give better grades.
May 12 (Dean's date): Final submission
Everything must be submitted by 5 PM, without exception.
Be sure that your code is complete after it is copied to the submission
directory. We will be looking through your source code to get an idea
of what you did, so everything should be there but no extra junk.
cd submission_directory
tar cf ../jdoe.tar .
cd ..
gzip jdoe.tar
Grading
The project is worth about 60-65 percent of the overall course grade.
Every team member gets the same project grade except
for a discretionary component in the unlikely event
of significant dereliction.
The project grade will be derived from considerations like these (percentages
are approximate):
Important:
We will be experimenting with your system starting at 5 PM May 12, so it
has to stay up through May 18 and someone has to monitor it and respond
to mail promptly in case we have trouble. Thanks.