COS 333: Project Demo Information

COS 333 Project: Demo Information

Fri Apr 22 15:35:43 EDT 2005

Demos will be on Thursday, May 5, to avoid conflicts with the CS department's affiliates visit on May 4.

This page describes in more detail the requirements for Demo Day on May 5, what you have to submit by Dean's Date, May 10, and how grading will be done.

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

Remaining stages

April 22: 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.")

April 29: Beta test. Your code should largely work, all intended features should be installed and working, drafts of written material and web page should be pretty much done. ("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 5: Demo day

Project demos will happen May 5, probably in Friend 004 and probably 1:00 to 5:30. Each team will give a 30 minute public presentation of their work to Chris, Aquinas 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 during the last week of classes.

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, 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 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? 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.) We will supply a computer projector and an overhead projector. If you need Internet access, you may have to register with CIT and also CS staff to get mobile IP set up for your laptop; don't count on wireless access just in case I can't get a proper room. I will try to have the room available for dry-run testing the day before.

If using your own laptop is not feasible, I will bring my laptop running Windows XP SP2, with an Internet connection (behind the CS department firewall), an X Windows emulator, and Powerpoint. That provides access but you won't be able to install much of anything. Any requirements beyond these are likely to be a problem. No matter what, allow some lead time to make sure everything works.

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.

May 10 (Dean's date): Final submission

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

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
the code you wrote so we can see what you actually did
an installation procedure spelled out in sufficient detail that a dedicated user or developer could move your system elsewhere
an internals document giving an overview of the implementation in enough detail that it would guide someone taking over your code
a report on how things worked out and what you learned
your timeline, up to date

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.

Make a directory for your submission.
Copy all the documentation (described below) to this directory.
Create a sub-directory called src.
Copy all source files to src. This includes anything you created, especially source code and similar material. If you have help files, images, data, etc., put that here too (sub-directories are fine). Do not include other files that are created by compilation or downloaded from somewhere else: no object files, executables, class files, etc.
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
```

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.

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. (It's better if it works with all browsers and does not require plug-ins.)
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. 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! We will not try to recreate your system, but we want to see the process spelled out carefully enough that we could imagine doing it if so motivated.
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 project worked out. 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.
Your timeline, in timeline.html.
You can include your demo material, e.g., a Powerpoint presentation, here if you like.

All documentation other than your seduction web pages must be in straightforward HTML, GIF and JPEG that works with Firefox 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. I am particularly interested in thoughtful and interesting reports, so don't skimp on this part.

A working system: We will be experimenting with your system starting on Dean's Date, so you must provide us with some kind of access to a running version. If the system is web-based, make sure it's up and running and we have access to 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, 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.

You should test carefully to ensure that someone not in your group can exercise all aspects of the system.

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 65 percent of the overall 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:

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
- operation: works almost flawlessly / mostly works, occasional glitches / sort of works, awkward / easily broken, can't tell if it works, hangs
- user interface: consistent; intuitive, natural and easy to use / occasional pitfalls and unobvious uses / awkward, unintuitive, often confusing to use
- appearance: polished and professional / mundane and pedestrian / little attention to appearance
- 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
- advertising: appealing, attractive / straightforward listing of features / sloppy, careless
- report: real insight, thoughtful, informative / straightforward "this is what we did" / little evidence of thought or effort
- internals: well described / adequately described / badly described
- writing: very good, interesting, fun to read / acceptable, straightforward / poor, bad grammar, excessive spelling mistakes and typos

Important: We will be experimenting with your system starting May 11, so it has to stay up until May 17 and someone has to monitor its behavior, and also respond to mail in case we have trouble. Thanks.