Your project document
=====================
Due Thursday November 29, 2007.

On the same date, turn in your team/self evaluation.
See file hitchhikers-couch-potatoes (same directory).

It is important that your code itself is appropriately documented.
In the project document you reflect on your project experience
and tell the story behind your project. There are two parts.

Part 1. 
=======
highlights the difficulties you had and motivates
your important design decisions. It also compares your original 
road map with the actual road taken by your project.

Suggested outline:

Your general impression of the project: How did you experience it?

Difficulties you encountered. 
  How did you solve them. 
  Which approaches worked best for solving difficulties?

Important design decisions and their motivation.

Include an XML schema covering our exchange languages and
an optional UML class diagram and an optional collaboration diagram.

The XML schema is important. It defines the languages that
we specified using a class dictionary using a standard technology.
There are tools available that generate an XML schema from
XML documents.

Your initial roadmap and the actual road taken.

Part 2.
=======
analyzes the quality of the system that you developed.

Answer the question: How well does your product implement the requirements?

In part 2.  of your document, I want you to focus on testing. Turn in
your test inputs and report the ones
that did not work properly and identify where the problem is:

There are at least four possible sources:

1. Your code
2. outsourced code
3. Java library code (unlikely)

Describe how and why you assigned the error to a particular source.
If it is your code, describe in English how to repair your code.

The entire document should not be longer than 5 pages, excluding the test 
cases (inputs, expected outputs).

Testing and repairing a piece of software is a valuable skill.