There are two final documents: a substantial paper, written by the team as a whole, and an individual who did what description.

Final Paper¶

The final paper in this course should describe your project from beginning to end, in a way that shows your accomplishments. Your aim is to have something that you might give to an employer to show your skills in databases with web interfaces. This is a team-authored document. One of you may be the lead editor, but each team member should contribute to the writing, probably writing about their own work.

Content¶

Your paper should have an introduction giving any necessary background, so that I or your potential employer understands what the paper is about and what the context of your project is. It should describe and motivate the features you are implementing at a high level, omitting technical details. It should explain, again in a non-technical way, how someone uses your web site--a kind of user guide. This might be integrated into other sections or described in a separate section. Finally, your paper should describe the technical aspect, talking about the different facets of the work and how they all fit together. The technical part should talk a little about the data you've collected. Not all the details of the DDL, but high level descriptions of things. Describe files that users can upload and where they are stored. Anything particularly interesting in the implementation. Not code documentation. Imagine you're giving this document to an interviewer for a job at Facebook or Google.

Your paper should have a nice conclusion that summarizes this as a piece of technology, possibly with a bit of marketing (blowing your own horn about how good it is). You can imagine that you're trying to get someone to buy your software or hire you as a consultant: how do you conclude the paper in that situation?

Technical writing is hard and is worth learning how to do. It's hard to figure out where to start, especially with a multi-faceted project. Do you start with the web pages and forms, since that's what the user sees, or do you begin with the tables, since that's what holds the information? Do you start with the middleware (urls that are supported and such), since they pull everything together, or does that make the description too complicated, as too many things are introduced at once? You'll have to figure out how to do this for your project. Assume a technically knowledgeable audience (so you don't have to define what SQL is or what a table is), but one that knows nothing about your project other than what you've described. Again, consider your audience to be a technically knowledgeable manager at a tech company, who wants to know roughly what you did, but is not interested in 30 pages of Python code.

Format¶

This should be a nicely formatted paper with reasonable font and margins. A Google Doc would be great, but I know some people would prefer to do it in MS Word or something else, and that's okay, too, but if so, send me a PDF. Pictures and diagrams to supplement the writing are a fine idea, but they cannot replace the writing. I am not stipulating a minimum length, but I would be surprised if you could do it in fewer than 8-10 pages (including pictures/screenshots). However, brevity is always appreciated, and if you can do an excellent description of your project in 6 pages, you'll get an excellent grade. If it takes you 12 or 15, that's also fine.

How to Submit¶

Google Docs is easiest. That allows me to comment (if necessary) and allows co-authoring. It's also okay to copy text from prior documents, such as your design-and-plan or your draft, etc.

The title of the document is very important, otherwise I will mis-place it and lose time finding it. The title of the document will be CS304-SEM-YYYY-paper-TEAM where the SEM is the semester (Fall/Spring), the the YYYY is year, and the TEAM is name of your project or team account or your names.

Who Did What¶

As a separate Google document, each team member must write a brief explanation of who did what on the project. This is an individual assessment, not group work. It need not be long; it could just be a paragraph or two and maybe a bullet list. Turn it in as a Google Doc as well, named **CS304-SEM-YYYY-P6-YOURNAME`.

With the "who did what" documents, I'm mostly looking for a consistent story from each person and a reasonably equitable division of labor. For example, if Hermione did the "like" button and Harry did the "photo upoad" feature and Ron did the "login" procedure, it would be nice if all the documents said so. If Hermione and Harry didn't feel that Ron pulled his weight, they could say so in their documents.

I trust you all to work well and effectively together, and by and large, I've found that to be so. But every now and then, something happens, and I need to know about it.

Time and Work

The following link has been updated for Spring 2022

Finally, when you have completed the assignment, make sure you fill out the Time and Work Spring 2022 That report is required.