Final Project Guidelines
Final Database report is due Tuesday Dec. 8, 2009
There are two deliverables for your final project: a written report and a final presentation. They will be graded the following way:
We will use your class presentation and the written report jointly to evaluate the quality of your final project, looking to the report to answer questions that would not fit into the presentation.
The quality of the presentation itself will be factored into your "class participation" grade. Preparing an engaging presentation is part of your contribution towards making this class interesting and fun for others.
In other words, if you don't show up for a presentation but your report convinces us that the project was of high quality, you may still get full credit for the final project but lose points for participation. However, the presentation is really your best chance to show your project interactively, so make good use of it.
Normally the presentation should include a description of the project including intended uses and/or use cases, the database design, specific issues or challenges in development (these are usually presented using Powerpoint for illustration) and a demonstration of your user interface for the database.
We intend to grade final project in a similar way that Assignment 4 was graded, looking at how well it fares on four dimensions listed below. You can think of Assignment 4 as the draft of your final report, so the latter should be a refined version of A4, correcting previously identified problems. (Keep in mind, however, that we expect your user interface to be working at this point.)
We won't grade your report per se, but will rather use it as
evidence of your work on the project. The report does not have to
answer a pre-determined set of questions (as was suggested with A4),
but you should probably similarly use screenshots of your forms,
queries and reports. Please keep in mind that you would want to
demonstrate separately the design of your database, and the user
interaction with it. You should also show how they fit together. For
instance, you can show for each of your scenarios, you could show us
the form the user sees, the SQL query that gets generated, then the
results the user gets, etc.
Please do not include unnecessary information in the report. In particular, some of the printouts of Access queries provide way too much irrelevant information. Your assignment is not graded by weight. You should show details, but focus on meaningful details that would help evaluate your work.
The dimensions (each is worth 1/4 of the grade):
Problem statement and use cases. Does you have a clear problem in mind and have thought through specific ways the database will be used?
- What is the problem that exists now that will be solved by this database?
- Who specifically will be using the database? How exactly will help them?
- It is easiest to demonsrate this by including detailed use cases.
Database Design. Does the database design make sense given the problem?
- You would at least have to include an ER diagram, but you would also want to explain what your entities represent and why they are linked this way or another. Note that ER diagrams generated by Access mis-represent the cardinality of relations. You should either use a different tool or use a pen to correct the diagrams generated by Access.
- Normally, we would expect the database to be fully normalized. If your database is not, make sure to explain why.
- Check that your database design can indeed support all the things that it is supposed to do. If your database cannot achieve some of the objectives, explain this (and explain why).
Database Implementation. Has the database been successfully implemented (as designed)?
- A good starting point is to include table descriptions, SQL queries that match your use cases and their results. A successful demo during your presentation would also help.
- Your implementation must match your design.
User Interaction. Does your database have a usable user interface?
Please include some screenshots and explain any non-obvious design decisions. Again, the demo should help convince us of this.
As a general rule, asking users to enter IDs of entities does not make for a usable interface. If your interface requires them to enter IDs, make sure to explain why.
If you encountered problems implementing your interface as you conceived it, please make sure to document any discrepancies. I.e., tell us both what you really wanted to make and what you've got, why you couldn't get it to work as it wanted and what you would do it you had more time. You'll get partial credit for well-thought out interface that you couldn't implement.