CPSC 343 Database Theory and Practice Fall 2017

Project

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.


Teams and Topics

Teams

Projects are to be completed in teams of two. Teams will be assigned based on student preferences and skills.

Teams:

Topic

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.

Ideas

Note that these ideas are given as a starting point - you still need to make sure your topic satisfies the criteria given above.


Due Dates and Grading

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.

datedue
Fri Sep 8 team survey (available on Canvas under Quizzes)
Mon Sep 18
(recommended)
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:

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.


Project Components

Topic Approval

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

Specifications

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:

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:

Conceptual Data Model

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:

Database Design

Application

Milestones

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.

Peer Review

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.

Specifications

Consider the following points:


Valid HTML 4.01!