COS 333 Project: Final Submission Information
Sat May 11 08:19:50 EDT 2019
Here are the remaining things you have to do. Hang in -- the end
is very near!
May 12 (Sunday): Final submission
Everything must be submitted by midnight on Sunday May 12, 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 instructors can play with your
system. We will arrange blocks of times when the
TAs will be available to experiment with your systems.
- a link to your ongoing web site
- access to your Github repository so we can see what you actually did
- a report on how things worked out and what you learned
- a product guide for users and potential future developers
Here's what you will have to do:
Submit your project on Tigerfile at
The submission must include the following files with
EXACTLY these names, all lower case:
- A standard first page called index.html that looks exactly like this template. 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. 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 correct 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. This is
probably either the landing page for your system or the page that
you have been keeping up to date so far.
- A productguide.pdf (5-6 pages)
that provides an overview of the
system aimed at two targets: its typical end users, and its hypothetical
continued developers and maintainers. The "user guide" portion should
describe what the system does and how to get it to do what
it does -- relatively simple installation instructions, and the
features content typical of a non-technical user's manual. The
"developer guide" portion should describe the internal structure of your
system in intermediate depth, as though for a professional engineer
taking over your project. Help them to understand how the system is put
together, in an orderly and compact description, without getting mired
in lowest-level details. The document should provide a good working
description of the system and its implementation, but not a line-by-line
walkthrough of the code. This also is the place where you
acknowledge the software systems and other resources that you used but
did not create.
- A final report report.pdf (5-6 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 like a Powerpoint
presentation, etc., or you can upload them; it will help us to refresh
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. We are
particularly interested in thoughtful and interesting reports, so don't
skimp on this part, though I think an upper limit of 5-6 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 not a big deal and it's entirely up to you.
A working system: We will be experimenting with your system
starting on May 13, 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.)
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.
May 15 (Tuesday, Dean's Date): Peer ratings
Don't forget to submit your peer evaluations, as described on
(This part is subject to minor 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 small component from the peer review and 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 midnight May 12.
It has to stay up through the end of May 21 and someone has to monitor
it and respond to mail promptly in case we run into 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, or major missing pieces
- 20% documentation
- product guide: 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
- writing: very good, clear, interesting, fun to read
/ acceptable, straightforward
/ murky, ponderous
/ excessive grammar errors, spelling mistakes and typos