Rollout

The final delivery of the full project is to be scheduled in the Development Plan, but delivery MUST be between 9:00 AM on Mon Dec 12, and noon on Fri, Dec 16. NOTE: The drop-dead date for this project is noon, Fri, Dec 16. NO Project deliveries will be accepted after this time.

In addition to deliverable content (listed below), rollout will include a final delivery meeting with the CLIENT. At this time, the group must demonstrate the full functionality of its project, provide a walk-through of usage, demonstrate example test code, etc.

Deliverable content for this project includes:

JCiv.jar

A jar archive file containing all class files necessary to run the JCiv program(s) and provide all specified functionality. Optionally, the designers may provide a separate jar archive for the client and for the server.

Java source files

A subdirectory named src/ MUST be provided that includes the entire Java source code tree for all .class files in the JCiv.jar file, as well as any other support code (e.g., programs used in testing the code that are not part of the JCiv program itself). Note: if these programs depend on external library code other than the Java JDK or the gnu.getopt suite, the submission archive MUST either include the library whole or provide easy and explicit instructions on how and where to access such libraries. This documentation MUST be provided in the README.TXT file. The designer is responsible for ensuring that all copyright and distribution conditions are adhered to.

README.TXT

This file MUST describe how to compile, configure, and install the JCiv program suite, including how to construct the .jar file from the raw source code. It MUST also list any dependencies on additional software support libraries. Furthermore, if the software suite provides more than one executable (e.g., a MAP editor or graphical debugger is provided), the README.TXT file should indicate what programs are included in the suite and how to run them. Complete documentation for such auxiliary programs MUST be included in the user documentation.

Internal documentation

The handin MUST also include the full, compiled JavaDoc documentation for all Java source files in the submission archive. This documentation MUST include full descriptions of every public or protected method, field, sub-class, enclosed class, or constructor employed by the code. This documentation hierarchy MUST be included in a sub-directory named documentation/ within the submission archive.

Player/User documentation

The handin submission MUST include complete player (user-level) documentation for the JCiv program suite. This documentation MUST include descriptions of how to use the main game client program as well as any auxiliary programs (e.g., a separate MAP editor). It must describe the User Interface of the program, how to interpret output/buttons/dialogs/screens/etc., and at least one step-by-step example of running the program, playing a game, interpreting the results, etc. In particular, this document MUST explicitly describe both behavior required by this specification and any extensions or modifications provided by designers (e.g., OPTIONAL RULEs).

This document SHOULD describe both client operation and behavior and server operation, configuration, and behavior. The designers MAY, however, choose to offer a separate administrator's guide that describes how to run and configure the server. In either case, there MUST be clear and distinct directions on how to install, run, and configure the server.

This document MUST be named PLAYERGUIDE.extension, but it MAY be a plain text, HTML, PDF, or PostScript document (with the appropriate extension). It MUST NOT be a Microsoft Word or other nonportable format document.

Design documentation

The final submission must also include one or more documents that describe both the initial design of the system (as proposed in Milestone 1), the final design and features of the system (as delivered in the Rollout), and a rationale justifying the modifications (if any). Note: Modifications to the original design are not bad. In fact, they are expected and encouraged. But the design documentation MUST describe why any such changes are made. For example, refined understanding of the specification, design discussions with the CLIENT, improved efficiency or modularity, improved use of Java language features, scaling back design to meet deadlines, untenable original design, improved support for requirements, etc. are typical reasons for modifying the design.

Test cases and documentation

The submission archive MUST include a subdirectory named tests/ that includes all of the data or test cases used in unit, regression, or integration testing of the JCiv system. In addition, the submission MUST include a document named TESTING.extension that describes the testing methodology, result of test cases, etc. This document is responsible for convincing the CLIENT that the JCiv suite performs correctly and meets this specification document. This document MAY be be a plain text, HTML, PDF, or PostScript document (with the appropriate extension). It MUST NOT be a Microsoft Word or other nonportable format document.

CVS log file(s)

For each Java source file, the submission archive MUST include a corresponding .log file including the CVS log for that sourcecode.

Team evaluations

Each team member must independently provide a written assessment of their own performance within the design team as well as the performance of the other team members. This is to be delivered by email directly to the CLIENT and is not to be included in the group submission package. This information will be kept strictly confidential by the CLIENT. See Section  for details on this document.