May 9: Demo day

Project demos will happen May 9, in (probably) Room 103 between 10am and 5pm. Each team will give a 30 minute public presentation of their work to Christine and me; other groups are strongly encouraged to attend, for edification and moral support, and visitors are welcome. I'll post a signup sheet for demo slots closer to May 9.

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, start thinking about your demo now. 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. Think of the audience as a group of skeptical but hopeful and very supportive potential customers or investors.

What should you cover in your presentation? That's entirely up to you, but it will likely include an overview of what your system does and why it's 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 5 minutes for questions at the end.

For the demo, what kind of hardware and software and network access will you require? 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 will supply a computer projector (1024x768 resolution) and an overhead projector. If you require Internet connectivity, you need to register with CIT and also CS staff to get mobile IP set up for your laptop. The room will be available for dry-run testing on Wednesday, May 8, the day before the demos.

If using your own laptop is not feasible, please let Christine know as soon as possible what exact hardware and software you will require. We can probably supply a PC running Windows 2000, with an Internet connection and an X Windows emulator, but anything beyond that is likely to be infeasible. No matter what, you need lead time to make sure everything works. Please give your demo requirements to Christine by Friday, April 26.

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 14 (Dean's date): Final submission

Your final submission will have to include

• access to a working version of your system so we can test it
• a web page that would induce others to use your system
• your code and an installation procedure so we can see what you actually did
• an installation procedure sufficient for a user or developer to move your system elsewhere
• an internals document describing the implementation
• 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: Collect everything for submission in one place.

• Make a directory for your submission.
• Create 2 sub-directories called src and doc.
• Copy all source files to src. This includes C, C++, VB, 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.
• Create a gzipped tar file jdoe.tar.gz, where jdoe is the login name of the project manager, and submit it. A suitable command sequence is

  	cd submission_directory
  	tar cf ../jdoe.tar .
  	cd ..
  	gzip jdoe.tar
  	submit 6 jdoe.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 speech" description, a single paragraph that states clearly and succinctly what your system does. And it must tell us how to access a working version of your project so we can experiment. This is very important, so make sure that what you tell us here is right!
• 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. The content and format are up to you, but try to make it short and 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 create them, or both, 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 developers who will be maintaining the code after you hand it over. Help them understand how it's put together. Don't get mired in detail; half a dozen pages are likely to be sufficient.
• 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 other than your seduction web pages must be in simple HTML, GIF and JPEG that works with Netscape and Internet Explorer. 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 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, Perl modules, XML tools, and the like, these must be noted in the installation instructions, along with your best guess about how to get copies. Do not include them!

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

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

The project grade will be derived from considerations like these:

• 10% for planning, prototype, alpha, and beta
  • schedules met? evidence of thinking and planning? plausible assessments of time and effort? reasonable division of code and labor? teamwork and cooperation? adequate functionality?
• 20% demo
  • good organization of material
  • clear overview, motivation
  • good examples to illustrate the system
  • system apparently works most of the time
  • smooth presentation, with evidence of rehearsal
  • stays within allotted time
• 50% functionality
  • effort: clearly the result of sustained hard work / a suitable amount of work / little evidence of effort or care
  • flair: innovative, exciting, intriguing, neat ideas / solid, workmanlike / mundane, pedestrian / klunky, apparent lack of thought or imagination or interest
  • operation: works almost flawlessly / mostly works, occasional glitches / sort of works, awkward / easily broken; can't tell if it works; doesn't respond
  • user interface: consistent, intuitive, attractive; good online help / mundane, pedestrian / awkward, unintuitive, confusing, no help
  • code: sensible structure, clean, clear, well structured, readable / messy, disorganized / significant examples of bad code, poor style
  • submission: complete and correct / wrong file names or directories, broken links / major installation or access problems / major missing pieces
• 20% documentation
  • internals: well described / adequately / badly
  • report: real insight, thoughtful, informative / straightforward "this is what we did" / little evidence of thought or effort
  • writing: very good, interesting, fun to read / acceptable, straightforward / poor, bad grammar, spelling mistakes
  • advertising: appealing, seductive / straightforward / sloppy, careless