Project Reports

The requirements for both intermediate and final group-project reports are described below. The intermediate reports do not affect your grade directly (they have 0 weight) and are thus optional. However, their submission is strongly encouraged to enable early feedback on projects.

Instructions for all reports: The quality of your report is an important component of your final grade (roughly a third of your project score, or 10% overall), so please make sure you pay attention to organization, grammar, punctuation, typography, layout, and overall clarity. Word and page limits are strict. Figures contribute to the word-count an amount equal to the number of words in the figure. The first page of each report should include appropriate title and identifying information (group name and group members). Do not use a separate title page or cover page. Do not include sensitive information (SSNs, passwords, etc.) anywhere in your report. In each report submission, include all previous report submissions in an appendix. You should also include a section in each report detailing how you have addressed (or plan to address) any comments I may have made on your earlier reports. You are also free to include additional appendices containing information you believe to be useful to the reader. However, like all appendices, the material in such appendices should not be required to understand the report. That is, you should not assume that the appendices will be read. The appendices do not contribute to the page or word limit.

Submission: You should submit your project reports electronically in PDF format. Your file should be named using the scheme gname-X-N.pdf where gname is the name of your project group (e.g., widgetmasters), X is one of pr1, pr2, and pr3 for the first, second, and third project reports, respectively, and N is an arbitrary 4-digit number. For example, the widgetmasters group may submit a file widgetmasters-PR2-4242.pdf. Please use only lowercase letters in gname and use gname consistently for all submissions. For the source-code submission, use the file-naming scheme gname-src.tgz for the tarred, gzipped package containing your source code. You should upload this file by anonymous FTP (anonymous as the user name and your email address as the password) to the FTP server cs.umaine.edu in directory the /incoming/cs/cos480/. If you need to upload an updated version of your submission for any reason, you can follow this procedure again using a different four-digit integer in the file name. If you try using the same file name as your earlier submission, the upload will likely fail. I will grade the most recent submission before each deadline. You will not be able to list the FTP upload directory (standard security setup), so pay attention to the diagnostic messages from your FTP program.

Project Report 1: The most important parts of this report are the choice of group members and the choice of a suitable application. The maximum length is two pages. This report is optional. Points to cover:

Group name: short and sweet.
Group members: For each member, include full name (as registered), preferred name, major, and year.
A brief description of your proposed application from the end-user point-of-view. (How would you describe your proposed work to a potential customer who is not familiar with databases and programming?)
A brief description of your implementation plans. You may wish to include a rough system architecture. Mention the programming languages, database systems (e.g., Oracle, PostgreSQL), and major libraries or components (e.g., Apache, PHP, Jserv) that you plan to use. (How would you describe your work to a classmate or other database-savvy person?)
Progress report: Outline what you have done so far and what you plan to do next. Try to set up some milestones for yourself.

Project Report 2: The maximum length is 10 pages. This report is optional. Points to cover:

Any revisions to your project description or implementation plans.
Conceptual (ER) model for your database application. Please make sure that you follow the standard conventions as described in the textbook and in class. Any additional features that you need should be included as annotations. Try to include as many constraints as you can (as annotations). Include explanations for any constraints that are not obvious. (For example, if some constraint is the result of your design decision to allow at most one shopping cart per registered user at any time, make sure you explain this reason.) Remember that the ER diagram is a design tool and your work will be evaluated for good design. Simply submitting a syntactically correct diagram will not get you very far if the design is poor (or poorly explained). Feel free to include English explanations as needed in the main body of your report.
The translation of your conceptual model to a logical (relational) model. You must include details of all steps of this process, including the mapping of ER concepts to relation, the enumeration of functional dependencies, normalization, and any additional transformations.
A summary of the final logical model derived above.
Partial physical model: Include create table statements that illustrate the attribute types. Explain non-obvious design choices (e.g., if you use an integer type instead of a date type for date-of-sale).
Progress report, as in the earlier report.
Appendix with earlier reports, if any.

Project Report 3: The final report consists of the following parts. Please note that, except for the first twoparts, there is no limit (neither lower nor upper) on length. You should not feel the pressure to write a certain number of pages. For example, you don’t need to write 10 pages of user documentation to get a good score. If you can say all that needs to be said in five pages, it’s fine.

Summary of work: This part should be no longer than 10 pages. It should include a clear description of your application and a high-level description of the functionality you implement. This part is your chance to make sure you get credit for the parts of your project work that may not be obvious. Be sure to highlight the novel, interesting, difficult, or otherwise noteworthy parts of your project.
All the material required for the earlier project reports, subject to the corresponding length restrictions. This part is in addition to the verbatim inclusion of earlier reports in the appendix, as noted below. The description here may differ (and typically will differ) from what you submitted in earlier reports. For example, if there were problems with your ER diagram and normalization, you should include the fixed versions here.
User documentation: This part is what you would include with your application if you were shipping it as a product. Note that by user, we mean the person setting up your application, not the end user. (For example, if you built an online bookstore application, the user here denotes the person working for the bookstore, charged with setting up the Web site, not the person buying books.) It should include a description of how your application works (major modules, processes, flow of control and data, etc.). There is no fixed page limit for this part; 10 pages is typical.
Developer documentation: This part should contain a detailed description of your implementation that would be useful to someone interested in extending or modifying it (but that is not needed by someone interested in only using it as-is). For example, you should mention here how additional functionality could be added, or how something could be implemented in a more efficient or easier manner. Do not shy away from pointing out problems in the current implementation. You will not lose points for it. In fact, if you clearly describe why something you implemented is not great, and how it can be improved, you’ll get more credit. There is no fixed page limit for this part; 10 pages is typical.
Appendix with earlier reports, if any.

Source Code: As part of your final submission, you should upload all source code packaged as a tarred, gzipped file. (See submission instructions above.) This package should include a README file that describes the files in your submission and indicates how to compile them and set up your application. (As a simple test, a classmate who reads your project report and the README file should be able to set up your application.) You should include all code (and HTML pages and scripts) written by your group. Do not include compiled code and libraries. Instead, indicate how to obtain and set up the libraries. (For example, you can say ”We use the Apache server version x.y.z, which is available at http://www.apache.org/”; do not include the Apache distribution!) You should include a small sample dataset (no larger than 10 MB) so that someone setting up your application can test it easily. You should also include any icons needed to get your application running (e.g., logo for a online store, image of a ”for sale” button). Although, unlike the programming homeworks, we do not require that your submission compile with a single make command, you are required to provide enough detail to enable someone else to set up your application, so please check to make sure you’ve included all the necessary files and instructions.

[next] [prev] [prev-tail] [front] [up]