You should be ready for real users to test the system; earlier is better.

Drafts of written material (as described in other deliverables) should be underway.

The demo will determine a significant portion of your grade, so you (and the course staff) want them to go as smoothly as possible. In order to assure this, start thinking about your presentation now. You could picture your presentation/demonstration as an event 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. As to content, the "trade show" metaphor is useful, but you should aim for more than just a glitzy demonstration -- you should also spend at least some time discussing the architecture, the trajectory of the project, and providing evidence that you learned something.

One possible outline of your presentation would be: a short introduction of what your system is supposed to do; a demo of a small number of stable important features; a summary of other important features; a brief overview of architecture and implementation; an anecdote of something that worked well or failed disastrously such that you were able to take something away from the experience; and something that you might explore further or do differently if you were to start all over again or had more time. (You do not have to follow this outline; it's just one set of possibilities.)

You have 20 minutes, which is not a lot of time. Plan on using about 15 minutes, to leave time for questions, setup and teardown, and other delays. In previous years groups have done well on timing; rehearse so we can keep the streak alive. Plan demos that do not require much typing or mousing or window-switching. These invite things to go awry, and invite the audience to get restless while you poke around. You just don't have enough time. Never plan to switch computers or write on the board.

Have fun. These projects are really interesting, and the enthusiasm of their presenters helps make that evident to all in attendance. Because a healthy audience amplifies that enthusiasm, each student is required to attend four other presentations and you are strongly encouraged to attend more, for edification and moral support. Visitors are welcome, so bring your friends and family. Typical projects are great; come and hear about them. We will advertise the schedule of demos in advance.

We also want to take a look at your Github repository to get a sense of size and scale. We will explicitly not be counting commits by individual team members. More details on this later, when we figure out the least invasive and low overhead mechanism that we can. (Suggestions are welcome.)

The Final Report should describe how the project worked out. How good was your original planning? How did your milestones go? What was your experience with design, interfaces, languages, systems, 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. Some groups present a single unified report, synthesized from the thoughts of all group members. Other groups prefer to write separate pieces of the report, since they focused on different project components and learned different things. Either is fine, but in both cases aim for true introspection; try to avoid repetition or banal generalities like "This was really interesting. We learned a lot."

The Product Guide should provide 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 that you used but did not create.

More details will follow soon on project submission and documentation.

You will have 3 points per person in the group, excluding yourself, to distribute across the other members of the group. (That is, for a group of 5, you will have 12 points to split among 4 people; for a group of 3 you will have 6 points to split among 2 people.) The minimum score for any person is 0.

You must submit the feedback on Dropbox in a text file named peer.txt using the link https://tigerfile.cs.princeton.edu/COS333_S2019/peer. The format of the feedback is a list of netids and points allocated, optionally followed by a blank line and free-form text to elaborate on your ratings. Please be concise and attempt to avoid turning the text description into a ranting opportunity. Follow this format exactly.

Here is an example of the list and text feedback for teammates Joe Student and Josephine Élève in a group of three:

jeleve 4
joestu 2

Joe contributed to the initial design of the project, but dropped off
the face of the earth in April.  He did get back with the program for
the documentation, which I think is good, but I feel like Josephine and
I really carried the project through to the demo.  Josephine was a dream
to work with because she was a good leader and always got her code done
on time and in working order, but once Joe showed back up, she did sort
of dump us with the documentation at the end.

The ratings from all other members will be taken into account when assigning individual credit for the project.

Note: You will get a rating of zero for failing to provide ratings, or for failing to use the correct format as specified above, regardless of the ratings from your teammates.

Grading

Grading for the project will be based on a number of criteria, including

• planning: how careful, realistic and thoughtful your plan is.
• development process: how well you carried out stages of design and early implementation, including preparation and participation in TA meetings, reviews, etc.
• functionality: successful design and implementation of the basic task you set out to do. Working code is critically important -- if your system is easy to break, your grade will truly suffer.
• user interface: visual appearance and polish, suitability for its intended purpose, consistency and uniformity, naturalness, freedom from surprises.
• implementation: clean, well organized, modular code is good.
• engineering: how well your project adheres to the important ideas of the course, like sound tradeoffs, testing, appropriate efficiency, etc.
• documentation: marketing blurb, web pages; a working description of the project and its implementation (but not a line-by-line walkthrough of the code); a careful and thoughtful report that looks back on what you did and what you learned from it. The report is the most important part of the documentation.
• demo: organization, preparation, polish, interest.

There will be more information as we go along, to flesh out or clarify some of the sketchy parts here. You are encouraged to ask questions that will help clarify things for everyone. Murphy's Law applies to projects and their administration, so there will undoubtedly be screwups. We apologize for those in advance, but of course they too will be a simulation of reality...