COS 333 Project Demo Information

Sun Apr 14 16:37:45 EDT 2013

This page describes in more detail the requirements for Demo Days on May 8-10, what you have to submit by Dean's Date, May 14, and how grading will be done. There may be changes but nothing that will make a huge differrence, and there will be warning.

Apr	    1  2  3  4  5  6
	 7  8  9 10 11 12 13	project prototype
	14 15 16 17 18 19 20
	21 22 23 24 25 26 27	alpha test
	28 29 30
May	          1  2  3  4	beta test
	 5  6  7  8  9 10 11	demo days
	12 13 14 15 16 17 18	Dean's date: projects due by 5pm
	19 20 21 22 23 24 25	someone must be around in case of trouble


Remaining stages

Leaving aside the prototype stage, which was nominally "due" this week, these are the stages that remain. Notice that there are less than 4 weeks to the demos and only 4-1/2 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.

  • April 26: Alpha test. An "almost working" version of the core functionality of your project, to be demoed for your TA. ("An alpha version or alpha release represents the first version of a computer program or other product, likely to be very unstable but useful for demonstrating internally and to select customers.")

  • May 3: Beta test. Your code should largely work, all intended features should be installed and working, and drafts of written material should be under way. For a web site, that might mean the project is live and working on your web site. ("The beta version of a product still awaits full debugging or full implementation of all its functionality, but satisfies a majority of the requirements.")


    May 8-10: Demo days

    Demos will be held May 8-10 in Friend 008, between roughly 10:30am 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. There is a WASS signup here; grab the good slots early.

    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 potential customers, investors, 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? It's probably easiest to use your own laptop. The room has wireless and the usual computer projector (ONLY 1024 x 768!! Be prepared for the 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.


    May 14 (Dean's date): Final submission

    Everything must be submitted by 5 PM on this date, without exception.

    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.

    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.

    Documentation: The documentation must include the following web pages:

    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 15 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. HTML is best; PDF is ok too.

    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 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.

    I don't yet have a good plan for how to deal with systems that use an iPhone or Android, since we have only limited access to such systems. We can probably use simulators for some of it, but it may be necessary for someone to loan us the equipment for a few hours some day. Suggestions would be appreciated.

    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.


    Grading

    (This part is definitely subject to fiddling.) 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: Important: We will be experimenting with your system starting at 5 PM May 14, so it has to stay up through May 20 and someone has to monitor it and respond to mail promptly in case we have trouble. Thanks.