CSCI 240 - Final Report

Due Fri Dec 10 at Midnight

The Assignment

Each development team will compile one last set of documentation about their product's design and implementation. This report should basically be a compilation and revision (with some small extensions) of your previous reports--except that this report will describe the finished version of the product. You will describe the requirements of your system, your design that fulfills the requirements (described in present tense), your implementation of that design, and the results of any testing used to verify your implementation.

Your report should have the following sections:

Cover Page:
Include a cover page with the name of the project, your division, and the names of all your team members.
Abstract:
A one-page summary of your system and the contents of the report. This should act as an executive summary--that is, I should be able to read this and understand the basic gist of what you did and why you did it. Thus can be adapted from previous reports, but be sure to include the summary of this report.
Functional Requirements:
Include the use cases of each functional requirement you had planned for your system. Each use case should have a Name, Actors, Scenarios, Preconditions, Postconditions, and Alternatives.

Include any use diagrams (such as a System Sequence Diagram) to help describe your use cases. The goal is to be as clear as possible about the system requirements.

This content can and should be adapted from your Requirements Document.
Non-Functional Requirements:
Detail all nonfunctional requirements that you addressed in your final product. (e.g. "Easy Visibility: All text in our product is 16pt font."). These requirements can be borrowed from your Requirements Doucment, though be sure to explain the manner in which you addressed them!
Architecture Design:
Briefly (in around 1 page) describe the high-level architecture of your final product implementation. Be sure to include a design diagram of your product so that the functions of different modules are clear. This description can be adapted from your Intermediate Report, informed by your Design Document.
Module Design:
A detailed description of each module in your final implementation. Each module should have a Name, a Description, and a set of Provided and Required interfaces.

Note that these can be adapted directly from your Design Document.
Implementation Description:
A detailed description of the implementation of your final product. This can be adapted from your Intermediate Report, but must be updated to reflect the final product. Include the following components:
1. Source Code Location: Include a clear link to a repository where someone can download your source code. Remember that your source code should be carefully documented (with details about who worked on what, if possible).
2. Installation Instructions: A description of all the necessary procedures a developer (or the professor) would have to complete to install and run your product. Remember to address any problems the testing team may have had in installing your system!
3. Detailed Code Style Guide: This should be fairly detailed including naming, coding conventions, and comment conventions.
4. Class Diagram: Include a detailed class diagram; note that this should be distinct from your Design Diagram (in that it has more details about data and methods). Basically it should be a map of your code. Note that if you are using a third-party library, this diagram should detail the important classes and methods so that I can follow what you did.
5. Code Walkthrough: Include a text description of how your system works, and how the various components interact with one another. This could be understood as a textual version of the class diagram. Basically, walk me through understanding what you did to make things work, and why you did them that way!
Testing Details:
A description of how your system was tested (both internally and externally). This section should explain in detail the testing procedures followed. Be explicit about any changes made in response to external testing.

HINT: You may want to ask the group that tested your system for a copy of their documentation, if you haven't already!
Development Procedures:
A short description of the breakdown of development responsibility (e.g., who was reponsible for what components). This should be much more than "everyone worked on everything".
Reflections:
Include member reflections on the following topics:
1. Describe technical challenges you encountered in the development of your product, and how you overcame them.
2. Describe how you did or did not apply software engineering techniques to help you in your development. What helped, and what didn't? Why or why not?
3. Describe what you would have done differently if you were to start this project over again.
4. If you were to continue working on this project, how would you continue developing it?
Each of these reflections should be detailed (at least a full paragraph, likely two or three). Also make sure that everyone in your group contributes input to these reflections--do not just assign a single person to write this section. In fact, having a copy of the reflections from each group member would be highly appropriate (though they can be integrated if desired).
Glossary and References:
As always, be sure to define any technical terms you use, and to include links and pointers to any tools, packages, or systems that you mention in your document. Always cite others' work!

Submitting

Upload a pdf copy of your document through Moodle. Note that your reports may be shared with future classes. BE SURE TO PROOFREAD YOUR PAPER. These should be professional looking documents describing what you did all semester--the kind of thing you might give to future employers or graduate schools as a sample of your work!

(This document is due at midnight in case you need to clean it up after the demo; however, you should aim to have it completed before that!)