COS 333 Project: Final Submission Information
Fri May 9 18:12:25 EDT 2014
May 13 (Dean's Date): Final submission
Everything must be submitted by 5 PM on Dean's Date, without exception.
Your final submission must include
- most important:
access to a working version of your system so we can test it.
If your system involves a special device like a smartphone, you will
have to schedule times when TAs and instructor can play with your
system. We will try to arrange blocks of times when the
TAs will be in the tea room to experiment with your systems.
- 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 (you have been maintaining it, yes?)
- 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's what you will have to do:
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.
- 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
Do not include other files that are created by compilation or downloaded
from somewhere else: no object files, executables, class files,
emacs backups, IDEs, Git repositories, etc. We don't want
to exceed some CS quota.
If you used a public repository like GitHub, you can definitely
include that link; that will help us see where things are.
- Create a gzipped tar file jdoe.tar.gz, where jdoe is the
login name of the project manager, and submit it via Dropbox
A suitable command sequence is
tar cf ../jdoe.tar .
The check script expects that this will be done by jdoe.
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.
This page should also link to your project's home page, which
presumably includes a 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 informative and seductive. One possibility
might be to organize it around user scenarios like those in your design
- Your timeline in timeline.pdf.
- A file called internals.pdf (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
- A final report report.pdf (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
- You can also include links to your demo material, a Powerpoint
presentation, etc., if you like. If you did create materials for your
presentation, you can certainly 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 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.
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.
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.
(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:
We will be experimenting with your system starting at 5 PM May 13, so it
has to stay up through May 19 and someone has to monitor it and respond
to mail promptly in case we have trouble. Thanks.
- 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?
good teamwork and cooperation?
adequate functionality along the way?
- 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
/ clearly 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
- submission: complete and correct
/ wrong file names or directories, broken links
/ major installation or access problems
/ major missing pieces
- 20% documentation
- product page: appealing, attractive
/ straightforward listing of features
/ sloppy, careless
- timeline: detailed, informative
/ straightforward listing of events
/ sketchy, sparse, minimal
/ clearly written after the fact
- internals: well described / adequately described / badly described
- report: real insight, thoughtful, informative
/ straightforward "this is what we did"
/ repetitive; uncoordinated sections
/ little evidence of thought or effort
- writing: very good, clear, interesting, fun to read
/ acceptable, straightforward
/ murky, ponderous
/ excessive grammar errors, spelling mistakes and typos