Toonces Deliverables

Each group is responsible for submitting a final version of their program, including all relevant source files and a Makefile. The Makefile should include comments about what variables are site-specific (e.g., particular to acpub machines) to ease in porting the code to other systems.

Ideally, and certainly in the future, you will submit a tar file containing an archive of all your files and directory structure. This will allow you to submit a directory hierarchy rather than a flat set of files.

You can find out about the tar command by typing man tar. We'll go over this in class and simple use is explained in another document. You should definitely use tar for toonces.

Table of Contents

[ design | user-manual | group write up | software portfolio ]

Design

You must turn in a design document. This can be similar to those you turned in previously, but you may decide that changes should be made.

You must also document what each member function does. Some of this documentation may be accessible in your header files, but there should be programmer documentation so that if someone else takes over your toonces project they can understand what you've done. Ideally much of this documentation will be generated by javadoc. Concentrate on java rather than C++ (and ideally include both).

Be sure to document clearly code that you borrowed from other sources.

Bugs and Features

You should include a list of known bugs. You should also include a list of features you would like to implement if you had time.

User Manual/Documentation

Include documentation, preferably as an HTML document, but be sure to include printed copies of all documentation you wrote.

Group Post Mortem

Each group must submit a document, that each person in the group signs as having read, explaining how many hours were spent on the project. You do not need to allocate hours to individuals, but you should estimate the total number of person-hours spent on the project. You should include, if possible, descriptions of problems you had with coding, design, or other aspects of the problem. You should mention good and bad things encountered by the group as you have worked together.

Each member of the group should also submit an individual assessment of the project. This should include your perspectives on the group project and an assessment of your contributions to the project. No one will read this part of the writeup except for the professor in charge of the course: Owen Astrachan. You are free to comment about contributions from others, but these should be in a positive tone. Remember that each person in a group has different strengths and it is not possible for everyone to be a coding expert (or any other kind of expert). Of course it is possible that someone did not contribute at all. Hopefully all assessments will be be done honestly and with no malice.

The individual assessments can be turned in electronically either by email ola@cs.duke.edu or by using submit108 tooneval README, but it is fine to turn in hardcopy.

Software Portfolio

Although all code is submitted electronically, each group's final deliverable is a copy of everything the group has done that will go into each group member's software portfolio. This includes a copy of all code (hopefully printed 2 up to avoid a mass of paper, you can use enscript -2rG foo.cc to do this.) Do not submit code that was written by outside sources, although you should be sure to document this code.

Each group member should have a copy of what is turned in, a complete copy of exactly what is turned in. If a group has trouble financing the copying of all documents then please ask for help, we can make departmental copying machines available if there is a problem.