Iteration 3

Devise acceptance tests for the functionality that had been agreed upon between you and your client. In so far as is practical, the client should agree before the demonstration that these tests suffice to demonstrate the agreed upon functionality.

Deliverables

Mail the instructor a jar file, named <teamname>.jar before the demonstration. It should include the following directories and files (the names do not have to match exactly):

Files

• build.xml - has the targets needed to build, test, and run your system. - Do the targets work?

Directories

• documents -  has an index.html file that contains [links to] the following:
• Vision statement - Is it clearly written? Is the extant work researched?
• Project development principles - Is English crisp? Are principles traceable to practices?
• Project development practices - Is English crisp? Are practices traceable to principles?
• Javadoc - all public classes and public methods within those classes should have Javadoc. For guidance on this topic, please see Sun's page on how to write javadoc comments. -  Complete? Useful?
• UML Class diagram of key classes. Represent: generalization, realization, aggregation, and composition. Do not represent methods or data members.
• Readme - complete, detailed instructions on how to: - Do instructions work as stated?
• build your system
• test your system
• run your system.
• Postmortem - Does it provide answers?
• What went right?
• What went wrong?
• Specify any changes to your principles and practices for the next iteration.
• Peer reviews - each team member reviews every other team member. Provide comments as needed.  Do they exist?
1. Researched and gathered information
1. Unsatisfactory: Does not collect any information that relates to the topic.
2. Developing: Collects  little information. Some relates to the topic.
3. Satisfactory: Collects basic information. Most relates to the topic.
4. Exemplary: Collects all relevant information.
2. Fulfilled team role's duties as assigned
1. Unsatisfactory: Does not perform any duties of assigned team role.
2. Developing: Performs few duties.
3. Satisfactory: Performs nearly all duties.
4. Exemplary: Performs all duties well.
3. Shared the work equally
1. Unsatisfactory: Always relies on others to do the work.
2. Developing: Rarely volunteers to do the work.
3. Satisfactory: Volunteers to do nearly an equal share of the work.
4. Exemplary: Always willing to do at least an equal share of the work.
4. Listened to other teammates' points of view
1. Unsatisfactory: Never allows others to speak.
2. Developing: Usually talking, interrupts others a lot.
3. Satisfactory: Makes an effort to listen. Rarely interrupts.
4. Exemplary: Listens carefully. Never interrupts. Restates what was said to confirm to the speaker that the message was correctly understood, whenever the message appears ambiguous.
5. Other (specify)
• library -  has executables, typically jar files, that are not written by your team, but are needed to run your project.
• source -  your top-level package structure must be teamname.projectname. - Good OOD? Compatible with Practices (e.g., coding conventions)?
• test -  include your unit test source files. Each test class is in the same package as the class it tests. You also may include these files in the source directory. Are they reasonably thorough?
• testlibrary - has executables, typically jar files, that are not written by your team, but are needed to test your project.

Overall

• Requirements Does the system function as previously agreed?
• Substance       How substantial is the system?

Demonstration

• Build your system using Ant
• Run your unit tests using Ant
• Show us your Javadoc & class diagram
• Demonstrate that your system has all the functionality that you agreed upon with your client.