|CPSC 343||Database Theory and Practice||Fall 2017|
A significant component of this course is a project in which you will design and implement a database-driven application, bringing together concepts and material from many parts of the course. You will be responsible for designing and implementing both the database and the application.
Projects are to be completed in teams of two. Teams will be assigned based on student preferences and skills.
The topic is up to you; some ideas are given below but you are welcome to come up with your own. The criteria for an appropriate topic:
About the last point: The emphasis in this course is on the "database" part of "database-driven application", covering everything associated with the database itself (modeling, design, implementation) and up to and including the interaction of the front end application with the database - not a fancy user interface, tons of functionality, or extensive handling of data that has been retrieved from the database. In other words, plan big enough to achieve sufficient complexity in the data requirements; it's OK if you only implement some of the functionality.
You are encouraged to discuss your ideas with me prior to fully developing your specifications in order to determine if they would be suitable.
Note that these ideas are given as a starting point - you still need to make sure your topic satisfies the criteria given above.
All deadlines are in class unless otherwise noted. More details on what the different components entail and what to hand in are given in the "Project Components" section below.
|Fri Sep 8||team survey (available on Canvas under Quizzes)|
|Mon Sep 18
|topic approval (encouraged but not required)|
|Mon Sep 25||project specifications (milestone)|
|Fri Sep 29||peer review of project specifications|
|Wed Oct 18||conceptual model (milestone)|
|Mon Oct 23||peer review of conceptual model|
|Fri Nov 3||database design (milestone)|
|Mon Nov 13||peer review of database design|
|Fri Dec 8||application / final handin|
Grading will be based primarily on the final handin - specifications, conceptual model, database design, and the functionality of the application itself will all be assessed at this point. Peer reviews provide an opportunity for feedback earlier in the process, and you are always welcome to discuss your work at office hours.
What each component is graded on is outlined below in the "Project Components" section.
It is expected that all members of a group will contribute substantially. All members of a group will normally receive the same grade.
You are encouraged to discuss project topics with me to make sure they are appropriate (criteria given above) and of an appropriate scale. Something written (such as a draft of your specifications) is helpful; this can be followed up with a meeting during office hours or just email communication.
What to hand in: draft of specifications or other description of the topic
Graded on: not graded
The first step in developing a software system is to figure out what it needs to do. For a database application, this means determining the functional requirements (what the users need to be able to do) and as well as the data requirements (what needs to be stored and its constraints) for your project.
Begin by identifying your target audience (the stakeholders). Who will be using your system? Are there different groups of people with different needs?
As much as possible, interview members of each group of stakeholders. (If that is not possible, try to put yourself in their shoes and imagine how they would use the system.) What kinds of things does each group want to use the system for? What data is necessary for those tasks? What's the structure of that data?
Also consider any relevant existing systems. Use them to shed light on what your system will need to do - how do they work? What features do they have? What are they lacking?
This data-gathering should result in a requirements document with the following sections:
An introduction and overview which informally introduces what the system is for, who will use it, and what things they'll do with it. Compare/contrast your system with any relevant existing systems as a means of description ("it's like such-and-such, except with ...").
A description of the functional requirements for your system. Here's where you say (in more detail than the introduction) what the system will be used for. Identify the different groups of stakeholders and describe each type of thing a user might do, including which users are allowed to perform this task. For example, in a course registration database, tasks might include listing all of the courses with available seats (available to everyone) and registering for a particular course (available to students at certain times and the registrar all of the time).
A description of the data requirements for your system. Identify what information needs to be stored, what its interconnections are, and what the domain is for each value. (This can be in prose; you aren't creating a formal ER model yet, though you know you will be so you can think of that in terms of the kind of information you'll want to include.) Also include any constraints that may apply e.g. a student may not be allowed to register for more than 5 courses in one semester or student ID numbers must be unique. These constraints need not be something that you know how to represent - the goal is simply to identify properties of the data.
A prioritization of the application's functionality. Use at least the following categories for your ranking, though you can further order requirements within a given category if you wish.
Think carefully about the "essential" and "important" features - you will generally be expected to implement all of the essential features for a passing grade and most or all of the important features for a good grade, though this depends on the scale of the project. (If the full system is quite large, implementing the database to support the full system but only the essential/important features for one component of it can be acceptable.) Be creative with the "nice" and especially the "extras" features - you are not committing yourself to implementing them, but it is a good idea to think about extensions/enhancements from the beginning so you don't find yourself having made design decisions that then prevent a feature from being added.
Note that your focus in all of this is only what the system will do, not how. The how will come later!
What to hand in: Your requirements document with the elements described above.
Milestone graded on:
Final handin graded on:
In this phase, you should produce an ER model for the data involved in your project. This should be based fairly directly on your requirements analysis, though you may wish to first revise your requirements list based on feedback from the peer review. (You may also need to revise your requirements if you discover things that weren't sufficiently nailed down as you work on modeling.) Your focus should be modeling the data in a conceptually accurate way, and then expressing as many of the constraints on the data as possible within the ER framework.
You should also write up a discussion of your design - when there were alternatives about how to model something, why did you make the choice you did? Did you run into any difficulties trying to express things within the ER model? (Were there things you couldn't express or couldn't express elegantly?) Explain.
What to hand in: (a) The requirements list (data and functional) from your requirements document, updated to include any revisions made. (b) The ER diagram. (c) A list of any specifications or constraints that are not represented in the ER diagram. (d) Your writeup.
Milestone graded on:
Final handin graded on:
In order to encourage appropriate progress and to provide an opportunity for peer review and feedback, components of the project are due at various points during the semester.
What to hand in: As identified for specific components above.
Graded on: Satisfactory progress, as identified for specific components above. Late handins are not accepted, so you will also miss out on the benefits of peer review if you miss these deadlines.
For each of the three specifications and design phases, your team will review the work of several other groups and provide feedback to them. This is an opportunity to gain additional experience with the different elements of the project as you will get to see how others have done things as well as having to think critically about how to handle different situations.
What to hand in: For each assigned document to review, a writeup addressing the points outlined below. Identify which document each review is for.
Graded on: Thoroughness, accuracy of critique.
Consider the following points:
Are all the parts present? (introduction/overview, identification of stakeholders, functional requirements, data requirements, prioritization of functionality, credits and resources)
Is the functionality designated as "essential" or "important" sufficient for a useful application? (Minimally useful is OK.)
Are the data requirements complete? Is all of the relevant data identified, and is the structure of that data covered? Is there enough that you could produce an ER diagram modeling the data requirements?