ITEC 325 2014fall ibarland

home—lects—hws
D2L—breeze (snow day)

project
Project
requirements

For this course, teams of four students will design a web application. Some examples of the sorts of things that can be done are:

• A reservation system: Enter room-requests, have them approved, show all reservations for a given room, show all reservations for a given client, udpate a room's details. Include a calendar view.
• A specific variant of the above:
  A scheduling tool for RU students to make (advising) appointments w/ a faculty member. For example, spend an hour trying out a site like checkappointments.com and doodle.com (setting up your schedule and having a friend arrange an “appointment” with you), and see if you can make a site which is better for the specific task of RU student advising.
• mp3 shop: Browse inventory, search for albums/artists/songs, release files upon payment, update inventory.
• sports-team database: Look up information about players and about teams; administrators can to update such info; users can have a list of favorites teams or players and log in to see summaries. Allow users to either make changes to data, or suggest changes to be reviewed by an administrator.
• External client: a local Church

  See the newsgroup post (in a moment) for details.

• A web-site to maintain a friendly betting pool: On superbowl sunday, friends come over and watch the game together, and might have a small betting pool based on an elegant parimutuel system. A web-site would track the tickets issued, and when the game finishes it would show how to distribute the pot. See ibarland@ for details.
• A page for a (campus) club. Perhaps one with events that people can sign up for; or perhaps one with a bio sketch for each member; …
• If you know of a local organization or charity that would like a web project, and are interested in helping them, see me right away.

You encouraged to suggest your own projects, perhaps inspired by the suggestions above. However, your project must include the following features¹:

• Your pages are reachable via https://php.radford.edu/projn, where n is your team-number (in {1,…,5}).
  I will likely require access via git as well (presumably bitbucket.org).
• User authentification, either as a client or a manager/administrator.
• A back-end database to store information.
• Pages for clients to enter new records, and view all their own records (possibly modifying/updating parts of them);
• Pages for administrators to modify any records (with safeguards), view appropriate groups of records (e.g. all reservations for next week), with a page for administrators to enter/modify any record, a way for a client to enter/modify parts of their own record, and ways for administrators to view summary of many records.
• Data validation performed (as appropriate) on the client-side, server-side, and database back-end.
• As appropriate, a unified appearance for all the pages.

• You may use tools like dreamweaver, as well as libraries like Node.js or PEAR packages you install. Be sure to cite code you get from elsewhere (e.g. a bunch of php/javascript for showing a clock/calendar), and during your presentations be up-front about what libraries and code you made use of. (Discussing the difficulties of integrating others' code certainly can be a worthy topic, as well.)
  If you feel unsure whether you're borrowing too much, just talk with me.

  Note that the individual homeworks are where the course ensures you know various specifics of coding; the project is intentionally there to help you expand your vision of what your sites can (or, should) do.

Checkpoints include:

1. (due Oct.13, Mon., 09:00: in class, hardcopy only) Choose teams and projects.

   Choose one team member as liaison, that I'll channel all communication through. The liaison should send me the names of the team-members, and a 3-sentence description of their project.

2. (due Oct.22) Submit a proposal (10%):
   • Team name,
   • members (with the liaison )
   • a list of pages that site will contain, along with:
     • A crude, hand-drawn mock-up of each page (each page has a short name; each links/forms to other pages are that target name, circled). You do not have to use crayons.
     • A crude, hand-drawn mockup of any standard header/footer/sidebar that will be on all other pages.
     • What input fields each page has (if any), annotated with what data/validation will allow a successful submit; (perhaps even the exact id/name attributes for each input field).
     • Example sentences of the page-specific content.
   • A database schema/ERD: what tables, what columns they have, and one-to-two sample rows for each table. Show primary and foreign keys.
     (This can be hand-drawn, but neatly (using ruler etc). Or you can use a tool such as Visio, which might save time during updates and presenting later.)
   You aren't locked in by this proposal; it is intended to make sure you have thought through what you need to do, and that the entire group understands exactly what functions will be implemented.

   (Details to follow:) You will also have to have a git account working (presumably on bitbucket.com), where each team member has added their name to a file README and pushed their changes back to the repo. I will verify this by examining the commit-comments for that file.

3. (due Nov.03) Prototype (10%), with a class demonstration (10%):
   • A stub for each page, with input fields and links (validation not fully required).
   • An instantiated database with the indicated tables, and at least four rows of sample (concocted) data in each (exercising the range of cardinalities in the ERD), and at least two sample SQL queries that might be eventually generated by the web form (but not necessarily connected to the web forms).
   • For the presentation: this is fairly informal — you don't need to dress up, nor have powerpoint slides (though you certainly may, if you like). But you do need each person to partake in the presentation, make eye contact with everybody in the room (not just the professor), and not have any misspellings on your web page or database samples.
   • The pages and database design you present are locked in at this point.
4. (due Nov.21) Progress report (5%):
   A short written summary of progress and problems-encountered (less than one page), including which team-members have been contributing to which component(s).
5. (due Dec.05 (Fri.)) Final project (40%), with a class demonstration (15%):
   Full data validation and database connectivity.
   In your demo, include a few moments to talk about technical and managerial difficulties you encountered (expected or not).
6. (due Dec.11 (Thu) 23:59) Peer evaluation (10%):
   Evaluate both other groups' presentations, and your teammates. project-team-feedback—itec325 project feedback

home—lects—hws
D2L—breeze (snow day)

©2014, Ian Barland, Radford University Last modified 2014.Oct.12 (Sun)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu