Project Artifact

While the code ultimately determines how the program runs, it does not serve well to describe how the program is organized, what decisions were made while the program was constructed, or even the priorities of the project. Nor is code for large projects concise, so it does not allow new developers to quickly get an overview of the entire program. Thus, programs are often supplemented by documentation that serves to explain such fuzzy concepts. Successful programmers must be able to write about code at a variety of levels of detail in order to get their knowledge and ideas across.

A project artifact is a document or website, organized in such way to allow another programmer to understand your program's design and organization so that they might evaluate it, debug it, or extend it. Your artifact should describe how your program is organized and why it was done that way. While you may assume your reader has a technical background, you may not assume that she has experience with this specific project or your design discussions.

It must include the following sections:

• Introduction
  This section should describe the problem the team is trying to solve, the primary architecture of the design, and the primary design goals of the project. It should be no more than two or three paragraphs and discuss the program at a high-level (i.e., without referencing specific classes, data structures, or code).
• Overview
  This section should serve as a map of your design for other programmers, so they will know where to go to fix bugs or make additions. It should describe specific modules in your project and how they are related (a module may represent a single class or a group of classes related in some standard way, such as set of subclasses). It should also include a picture of how the modules are related. This section should be no more than two pages and discuss specific classes, methods, and data structures, but not individual lines of code.
• Technical Details
  This section should describe each module introduced in the overview in detail, especially any design decisions that the group discussed at length (include pros and cons from all sides of the discussion). It should describe how each module handles specific requirements given in the assignment handout and how each could be extended to include additional requirements (from the assignment handout or comtemplated by your team). Finally, it should describe any erroneous situations that are handled by each module (i.e., bad input data, empty data, etc.). This section may be as long as it needs to be and go into as much detail as necessary to cover all your team wants to say.
• Remaining Issues
  This section should cover any known bugs that remain in the project's design or implementation. It is a chance for you to describe how you might fix the problem or refactor the design since you did not have time to actually change the code. This section may be as long as it needs to be and go into as much detail as necessary to cover all your team wants to say.
• Appendices
  This section should include some basic information about your project:
  • a list of all necessary files associated with the program, with a brief comment on the purpose of each
  • the commands needed to run the program, including examples of its various command-line arguments (if appropriate)
  • evidence that you tested your project (i.e., list of the test files: either actual unit test code, program output you saved, or scripts)
  • any other caveats of which the user should be aware (i.e., environment variables, resource files, data files, etc.)

Your artifact must include everybody's name that worked on the project, including outside people with whom you collaborated.