This course is closed. The accuracy of this page's content is not guaranteed. [Return to college.yukondude.com]

You really should consider upgrading your browser to a more recent version. You'll still be able to view everything on this site, but it'll be an ugly experience.

COMP220: Database Design II (W'05)
Term Project

You will plan, design, and construct a database-driven web application ("weblication") as your individual term project. You will proceed through all of the stages typical of the development of such projects in the real world: from the requirements-gathering stage, right through to the perilous demonstration of the completed application to the client. You are free to choose any theme you wish for your application: perhaps something work- or hobby-related. You may re-use your project database from COMP210, but you may wish to simplify it a little as this term's focus is on the interaction between application and database, rather than just database design.

Regardless of your choice, it is more than likely that the scope of your project will grow. This will especially be the case if you choose a work-related topic for your project--precisely because you will be aware of the complexities of the problem domain, and will want to model them faithfully. As the term progresses, you may be asked to reduce or enlarge the scope of your project so that the amount of effort you need to expend is reasonable. You will track these changes throughout the life of the project.

Although you are expected to work on your project by yourself, class members are encouraged to share their ideas and code. Students that incorporate pieces of other projects into their own are required to first solicit permission to borrow the code, and then must also acknowledge the original author of the code in both internal (comments) and external documentation. You may also use pieces of code from external sources (e.g. the web) but only under the owner's licensing provisions, and you must always indicate the source of any such code.

The instructor will also build a parallel sample project, intended both as a reference for marking purposes and as a method to ensure that the individual student projects remain somewhat synchronized. The deliverables from the instructor's project will be posted to this page.

Project Webserver

All of the student project websites can be found by visiting the project server's home page. If you are connecting from within the T1030 electronics lab follow this link instead.

Requirements

Each deliverable assignment will list the requirements for that stage of the project, but at all times your web application's HTML pages (static or dynamic) must conform to either the HTML 4.01 Specification or the XHTML 1.0 Specification. In either case your pages may conform to the Strict (very difficult) or Transitional (much easier) versions of the specification.

Deliverables

The project will be graded as a series of deliverables to be submitted on specified dates. Please remember that all deliverables must be submitted at the beginning of class (6:00 pm) on the date they are due. Late deliverables will be penalized 20% per working day, unless prior arrangements have been made with the instructor.

Deliverable Format

Each deliverable will be submitted in two parts: a design document and development log, and an online website (the first two deliverables do not require the website portion). The design document and development log will be resubmitted with every subsequent deliverable, updated and appended as needed.

The design document will eventually consist of the proposal, database conceptual model (E-R diagram and dictionary), database schema diagram, DDL schema scripts, and DML population scripts. The design document is always submitted to reflect the current state of the project. Changes to the design document are recorded in the development log.

The development log is used to record all activities pertaining to the completion of the project: additions or changes to the design document; pages or code added, modified, or removed from the application; pieces of code borrowed from elsewhere; and any other significant work performed. At a minimum, each entry in the log should consist of the date of the activity together with a description of that activity. Optionally, you may also want to keep track of how many hours are spent on each activity--useful for estimating the next project.

The online website portion of the deliverable will be located under your account's URL on the project webserver. If you do not wish a page of the website to be considered for marking, it should not be present and no links should lead to it. During the period that the website portion is marked, your account on the server will be disabled.

Deliverable Schedule

To view the detailed description of each deliverable, click the links in the Deliverable column below. These descriptions will be posted to the site over the course of the term, and will also be handed out in class.

Deliverable Weight Due Date Description
Proposal
2005 Sample
2004 Sample
2003 Sample
2% Feb 1 The proposal outlines the business problem to be solved and the business rules that must be followed by the application.
Application Flowchart
2005 Sample
2004 Sample
2003 Sample
6% Feb 10 This deliverable consists of the application's screen flowcharts as well as the database conceptual model.
Prototype
2005 Sample
2004 Sample
2003 Sample
(only the relational schemas for previous years' projects are accessible)
6% Feb 17 The prototype consists of an online mock-up of the application of sufficient detail to account for the business rules defined in the proposal. The database schema diagram and DDL schema script are also included in this deliverable.
Static Query
2005 Sample
2004 Sample
(only the population script for the previous year's project is accessible)
8% Feb 24 The static query deliverable adds two business-related reports to the application that pull their contents from the database. A database population script is also part of this deliverable.
Dynamic Query 10% Mar 3 The dynamic query deliverable adds methods for the application user to browse and search through the records in the database.
Three-Tier Integration 6% Mar 17 The goal of this stage is to rewrite the pages of your application so that they are physically organized following the guidelines of three-tier design.
CRUD Functionality 16% Mar 31 This deliverable adds CRUD (Create, Read, Update, Delete) functionality to the central entity of your database design.
MVC Integration 6% Apr 14 The goal of this last stage is to rewrite the application so that it uses the Model-View-Controller design pattern, while preserving the same features and three-tier organization as before.
Total Weight: 60%

Evaluation

Each deliverable is evaluated differently due to the nature of the tasks involved. With the exception of the Proposal, the mark for each deliverable is made up of two components: correctness, and effort. The proposal's mark has only an effort component.

Correctness is based on whether the PHP and SQL code produce the correct result. Defects (bugs), unused code, and code that fails "silently" all count against the correctness component.

Effort is admittedly more subjective and so is the smaller of the two components. The effort mark is based upon: the obvious effort expended, attention to detail, clarity of the solution and supporting documentation, code quality, conformance with notational and coding conventions, and neatness. I'm a bit of a stickler when it comes to neatness, so be warned.

Finally, since the scope of your project will likely change as the term progresses, you will be able to make changes to your project, but all such changes must be fully documented and the changes shown in updates to each affected deliverable. In other words, your project's documentation package must be completely up-to-date every time you submit it. You may wish to add a section in the latest deliverable that describes the changes, or resubmit the previous deliverables with the changes highlighted in some way. It's assumed that you will make these documentation changes; if any are missing, marks will be deducted from the total up to at most one-quarter of the deliverable's total mark. Regardless of how you choose to document changes, you must resubmit all previous copies of a deliverable that were marked by the instructor in your documentation package.

Resubmitting Corrected Deliverables

If you made mistakes or omitted necessary information for a particular deliverable, you may make the corrections and resubmit your changes together with the subsequent deliverable. If your changes are correct, you may earn back up to one-half of the marks deducted from that deliverable (rounded down to the nearest half-mark). To qualify for these marks, you must document each correction that you have made.

Sample Project

The sample project will consist of a web application that supports the Famous Drummer Tanning Emporium's (FDTE) business: providing tanning bed facilities for its stable of high-profile celebrity percussionist customers.

The sample project's design document and development log are posted below. You can visit the evolving web application at 199.247.245.45/~drogers/project.

Design Document

The design document always reflects the current state of the application's design. Changes to the design will be documented in the Development Log.

Development Log

The Development Log records all activities pertaining to the completion of the project, including changes to the Design Document.

↑Top