COS 333 Project Demo Information

Mon Apr 10 11:37:13 EDT 2017

This page describes in more detail the requirements for Demo Days on May 8-10, what you have to submit by Sunday, May 14, and how grading will be done. There may be changes but nothing that will make a huge difference, and there will be warning.

Demo signup page

	Su Mo Tu We Th Fr Sa
Apr	 9 10 11 12 13 14 15	project prototype
	16 17 18 19 20 21 22
	23 24 25 26 27 28 29	alpha test
May	    1  2  3  4  5  6	last class; beta test
	 7  8  9 10 11 12 13	Demo Days
	14 15 16 17 18 19 20	Project due by midnight Sunday. Someone must be available in case of trouble.
	21 22 23 24 25 26 27

Remaining stages

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

  • April 14: Prototype
    Your team should develop, and demonstrate in your weekly meeting, a bare-bones prototype that shows approximately what you are trying to do, and what your system's core components will be, and how they will be accessed. It need not do much, but it must be demonstrate end-to-end connectivity and do some minimal part of the job. You should not be considering major feature changes after this stage, though you need not have many of the features actually implemented yet.

  • April 28: Alpha test
    Your team should demonstrate in your weekly meeting an "alpha" version -- an almost working version of the core functionality of your project. "Core" means the basic operations that form the essence of your project; if you were doing Amazon 2.0, for instance, this might mean searching for books and accepting orders. "Almost working" means that wizards (you) can help experienced programmers (us) to use the system. Your code may crash and need restarting or suffer other bugs and stability issues. Ancillary features and reach goals may still be stubbed out. Your alpha version must be able to convince us that your project can be completed by the deadline.

    This is the time to start getting real users to test the system.

  • May 5: Beta test
    Your team should demonstrate in your weekly meeting a "beta" version of your system. The beta version should show that all core features work, and all intended features should be installed and implemented, though not necessarily complete or stable. No major component should still be in stub form -- this is the "drop date" for features that have not been implemented. Your system at this stage should survive casual experimentation without guidance or hand-holding. It is very useful if you can get real users before the beta: ask other teams, your friends and roommates, and anyone else to try your system to see how well it works.

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

  • May 8-10: Demo days
    Each group will give a 20 minute public presentation of their work. All team members must attend the presentation, without exception. You must also attend at least three other presentations, for instruction and moral support.

    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 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 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 to keep the streak alive. Plan demos that do not require much typing or mousing or window- or computer-switching. This invites things to go awry, and invites the audience to get restless while you poke around. You just don't have enough time.

    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 three 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.

  • May 14: Documentation
    You must submit two documents: the Product Guide and the Final Report.

    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.

    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".

  • May 14: Submission and Availability
    Your final version is due at midnight on May 14. Note that this is two days before Dean's Date. You must submit the final code, and make available the final version for testing. For web apps, this means that we need the final URL and that the site needs to stay live for approximately a week beyond Dean's Date. For device apps or other stand-alone programs, this means that you will need to meet with some assortment of the course staff to do a demo on your device, where you will know that everything is compatible.

    For the submission, collect all code and code-related files that you created for your project in one place, and compress them into a single file.

    Specifically: Create a directory for named src. Copy all source code to that directory. That includes anything you created, especially source code and similar material. If you have help files, images, data, etc., put them in the src directory 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., and no .git repositories. We don't want to exceed some CS quota.

    Compress the src directory to create a gzipped tar file named with your group leader's netid netid.tar.gz. This is an appropriate command sequence for joestu's group:

     cd directory_above_src
     tar -cf joestu.tar src
     gzip joestu.tar

    Be sure that your code is complete before you copy it to the src directory. We will be looking through your source code to get an idea of what you did and how well you did it, so everything should be there. Once you have created the tarball, submit it via Dropbox at

  • May 16 (Dean's Date): Peer Ratings
    At the end of the project, you will evaluate the effort and contributions of the members of your group. This is your opportunity to provide personal, confidential, reflection on your group members. Note, however, that if there are severe group harmony problems or egregious issues with a group member not pulling his or her own weight during the development of the project, you should approach your TA or instructor to seek resolution rather than waiting until the end of the semester.

    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 The format of the feedback is a list of netids and points allocated, optionally followed by a blank line and free-form text to describe your rankings. Please be concise and attempt to avoid turning the text description into a ranting opportunity.

    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 of all other members will be taken into account when assigning individual credit for the project. Failure to participate in the peer rating process will automatically result in a rating of 0, regardless of the ratings from your teammates.


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

    There will be more information as we go along, to flesh out or clarify some of the sketchy parts here. There will also be class lectures on some of the pieces, like networking basics, user interface programming, web frameworks, and database software. 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...