May 3-5: Demo days.

Project demos will happen May 3-5, in the CS building in room 301. Each team will give a brief (30 minutes) quasi-public presentation of their work before a panel of the course instructors; other groups are strongly encouraged to attend, for instruction and moral support.

You can divide up 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 and as such you (and we) want them to go as smoothly as possible. In order to assure this, we'd like you to start thinking about your demos now. Picture your demo as a trade show demonstration that will make or break your "company" -- think of the TA panel as a group of skeptical-but-hopeful potential customers. You'll be on the spot in a foreign place, with an audience.

What kind of hardware will you require? Do you need Internet connectivity? How many connections? What operating systems? Probably the best 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.) We can supply a projector-type display. If you require Internet connectivity, then you need to register with CIT and also CS staff to get mobile IP set up for your laptop. We can hopefully provide some more details on this soon. Room 301 should be available for dry-run testing a few days before the demos.

If using your own laptop is not feasible, please let your TA know as soon as possible what exact hardware you will require. We can probably supply a PC running Windows and/or Linux, with an Internet connection, but we will need lead time to make sure everything works.

Once we have everyone's resource requirements, we'll set up a signup mechanism and slot the groups into a demo schedule. Please have your demo hardware requirements back to the TAs by Friday, April 21.

No matter what 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 some transparencies that you can use in an emergency.

May 9 (Dean's date): Final submission

Your final submission has to include your code, installation procedure, a web page that would induce others to use your system, an internals document describing the implementation, and a report on how things worked out and what you learned.

Here is what you should do (subject to minor refinements over the next couple of weeks):

Submission directory: Make a single directory for submission if you are not already working in a single directory. Be sure that your code is complete and still works when it is copied to the submission directory. We will be assessing your software somewhere else, so be sure to include all necessary files and remove all absolute file names.

• Make a directory for your submission.
• Create 3 sub-directories called doc, src and install.
• Copy all source files to src. This includes C, Java, Perl, makefiles, project files from VB or VC++, help files, icons, logos, and anything else necessary to recreate your work on a development system. Do not include other files that are created by compilation: no object files, executables, class files, etc.
• Copy all the documentation (described below) to doc.
• Copy your installation script, instructions, binaries, etc., to install.
• Create a gzipped tar file xxx.tar.gz, where xxx is the login name of the project manager, and submit it. A suitable command sequence is

  	cd project_directory
  	tar cf ../xxx.tar .
  	cd ..
  	gzip XXX.tar
  	submit 6 xxx.tar.gz
  

Documentation: The documentation must include the following:

• A standard first page index.html that looks exactly like this one. This page must refer to the other components of the documentation as shown. It must include the "elevator" description, a single paragraph that states clearly and succinctly what your system does.
• Your advertising material, starting in a page called product.html: teaser web page, short product description, screen shots, tutorial sequences, etc. This is the part that explains to potential customers or users what's neat about your project. Make it short but seductive.
• Installation instructions, in a file called install.html. This must contain enough detail that a user could install the executables on a suitable system, or a developer could make them, as appropriate. State clearly the development environment (operating system, languages, compilers, etc.) where the system can be built, and the environment where it will run.
• Internals documentation, in a file called internals.html. This should describe the internal structure of the software. Imagine that you are writing this document for your customers, who will need to maintain the code after they buy it from you. Help them understand how it's put together. Don't get mired in detail; a few pages is likely to be sufficient, and in no case should be this more than 8 pages in a normal font.
• A final report, in report.html, that describes how well the team worked in practice. How did your milestones go? What was your experience with design, interfaces, testing, etc.? What surprises, pleasant or otherwise, did you encounter on the way? What choices did you make that worked out well or badly? What would you like to do if there were more time? How would you do things differently next time? Imagine that you are writing this document for your (friendly!) boss or professor and want to explain what you learned that could be applied to the next project.

All documentation must be in simple HTML, GIF and JPEG that works with Netscape 4.5. It should be written in good English prose, free of spelling and grammar errors. It should be thorough but not exhaustive; the total submitted documentation should not exceed 15 printed pages.

Installation: If your code is meant to run on Unix or Linux, it should include a makefile such that the command make will make the system in the current directory. The command make clean should remove all temporary junk, like object files and executables.

If your system is meant to run on Windows, you can include a self-installing executable or a zip file that contains all the necessary files, along with any project files for the compiler you used.

In either case, if your system relies on the existence of major components like a compiler, a debugger, a source-code control system, or the like, these must be noted in the installation instructions, along with your best guess about how to get copies. You do not need to include them!

You should test your installation procedure just as you test your system, and you should inflict it on others if possible.

Grading

The project grade will be derived from considerations like these:

• 10% for detailed plan, first prototype, second prototype, and beta
  • submitted on time? thoughtfully detailed? plausible assessments of time? reasonable division of code and labor? adequate functionality?
• 20% demo
  • good organization of material
  • clear overview, motivation
  • good examples
  • system apparently works most of the time
  • smooth presentation, with evidence of rehearsal
  • stays within allotted time
• 40% functionality
  • a suitable amount of work, reasonable stages
  • flair: innovative, exciting, intriguing, neat ideas / solid, workmanlike / mundane, pedestrian / klunky, apparent lack of thought or imagination or effort
  • works almost flawlessly / mostly works, occasional glitches / sort of works, awkward / easily broken
  • consistent, attractive, intuitive user interface
  • sensible code structure, code is clean, clear, well structured
  • submission complete and correct
• 20% documentation, code, etc.
  • internals well described / adequately / badly
  • report provides real insight / straightforward "this is what we did" / little evidence of thought or effort
  • writing quality: very good / acceptable / poor, bad grammar, spelling mistakes
  • advertising: appealing, seductive / straightforward / sloppy, careless
  • links all work
• 10% teamwork