COS 333: Project Demo Information

COS 333 Project Demo Information

Wed Apr 11 13:27:17 EDT 2012

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

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

Remaining stages

Leaving aside the prototype stage, which is nominally this week, these are the stages that remain. Notice that there are only 4 weeks to the demos and 5 weeks to Dean's Date.

April 27: 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 4: Beta test. Your code should largely work, all intended features should be installed and working, and drafts of written material should be under way. ("The beta version of a product still awaits full debugging or full implementation of all its functionality, but satisfies a majority of the requirements.")

These descriptions are not formal requirements but are meant to provide guidance about how far along you ought to be.

May 9-11: Demo days

Project demos will happen May 9-11 somewhere (like the small auditorium or maybe Friend 004), between 10am and 5:30pm. 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 group 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. 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.

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

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. You could even make a video of your demo if you were really paranoid.

May 15 (Dean's date): Final submission

Everything must be submitted by 5 PM 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
your timeline, up to date
an implementation overview with enough detail that it would guide someone taking over your code
a report on how things worked out and what you learned

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.

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, IDEs, SVN or Git repositories, etc. We don't want to exceed some CS quota.

Create a gzipped tar file jdoe.tar.gz, where jdoe is the login name of the project manager, and submit it via this Dropbox link. A suitable command sequence is
```
	cd submission_directory
	tar cf ../jdoe.tar .
	cd ..
	gzip jdoe.tar
```

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 and how well it was done, so everything should be there but no extra junk.

Documentation: The documentation must include the following web pages:

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 and that your system really is accessible. Feel free to ask us to check ahead of time.
A page called product.html that includes a 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; maybe it's the home page or screen for your system. The content and format are up to you, but try to make it short and seductive. One possibility might be to organize it around user scenarios like those in your design document.
Your timeline in timeline.html.
A file called internals.html (2-3 pages) that describes the internal structure of the software for the developers who will take over after you sell your company, in enough detail that they could continue to evolve your system once you're gone. State clearly the development environment (operating system, languages, compilers, frameworks, etc.) where the system can be built, and the environment where it will run. If you used major components like Rails or Django, these must be noted, along with your best guess about how to get copies. Do not include them! We won't try to recreate your system, but we want to see how it's put together, spelled out carefully enough that we could imagine taking it over if so motivated. Don't get mired in detail, however; 2-3 pages is likely to be sufficient.
A final report report.html (6-7 pages) 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? What should next year's class learn from your experience? 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.
You can also include links to your demo material, a Powerpoint presentation, etc., if you like. If you did create materials for your presentation, do include them; it will help us to refresh our memories. PDF is much easier for us than Word, Powerpoint, etc.)

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 single 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. (I prefer reports that speak for the whole group with a single voice, not one part written by each team member, but this is not mandatory.) 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 to break things. (We will still worry about security vulnerabilities like SQL injection, of course.)

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.

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.

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:

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
- well organized / rambling, somewhat disorganized / no evidence of organization
- clear overview and motivation / leaps right in to details / no overview or motivation
- good examples to illustrate the system / weak or excessively complicated examples / too much mousing around, lost in details
- apparently works most of the time / occasional glitches / major glitches / broken
- smooth presentation, evidence of rehearsal / scattered, not sure what comes next / lots of interrupting each other
- good graphics, easy to read / too much on slides, too small to read, poor colors, wrong screen size / handwritten on blackboard
- uses allotted time well / runs overtime
- good answers to questions / weak answers
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, crashes
- 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" / repetitive; uncoordinated sections / little evidence of thought or effort
- internals: well described / adequately described / badly described
- writing: very good, clear, interesting, fun to read / acceptable, straightforward / murky, ponderous / excessive grammar errors, spelling mistakes and typos

Important: We will be experimenting with your system starting 5 PM May 15, so it has to stay up through May 21 and someone has to monitor it and respond to mail promptly in case we have trouble. Thanks.