ITEC 325 2019spring ibarland

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

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.

---

Live projects

A “Live” project is one where you are making a website for a real client, which will (presumably) be used in the real world. If you pursue one of these, it is up to your team to contact the listed client, and meet with them every few weeks. At the end of the semester, their feedback will be a component of your grade.

Live projects might not exactly require all the features listed above (that’s fine), but on the other hand they have their own specific requirements and difficulties. Many students find it far more rewarding to work on a live project for an extenral client, than one they make up.

• A page to gather data for a game for measuring user input traits, to see how effective different input-devices can be. idea-input-device-game.txt (Contact: Dr. Chase)
• 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.
  NOTE: you can only do a betting web-site if you follow the above payout protocol.
• An entry for a startup-proposal, via the COBE BB&T Business Innovation Contest. (pdf flyer) (Requires working with a COBE student; cash prizes available; plus, winners may get COBE to help seed their crowdfunding effort.)
• A work-scheduling site that lets managers assign shifts subject to availability/preferences, and lets employees easily request and manage swapping individual shifts with others.
  (This might also be usable by parents who have, say, several dedicated babysitters.)
• A site for one-time “self-destructing” downloads (contact: ibarland).
• If you know of a local organization, charity, or business that would like a web project, and are interested in helping them, see me right away.
• A page for a (campus) club, that you seek out. Perhaps one with events that people can sign up for; or perhaps one with a bio sketch for each member; …

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,…,8}).
  I will likely require access via git as well (presumably bitbucket.org or github.com).
• 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), perhaps 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 Visual Studio or dreamweaver, as well as libraries like Twitter Bootstrap (for CSS), Node.js (server-side javascript), or additional php 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 Jan.31 (Thu) 23:59, one email per team.)
   Choose teams and projects.

   Choose one team member as liaison, who I’ll channel all communication through. The liaison should email me (as plain-text, not attachment):

   • the names of the team-members (w/ one tagged as liaison)
   • a short description of the project: 2-3 sentences
   • the subject line should be “itec325 project team [team-name]”
   • the message must cc all team-members

   disclaimer: The liaison is not responsible for getting teammates to do their work, show up for meetings, etc.. The team lead (who is often also the liaison) should schedule meetings and coordinate with all members to help keep the project on track, but should not do others’ coding. One supporting role that can be useful is that of a sounding board: a team member might sit and code while another member is sitting next to them, and can bounce ideas, design decisions, and questions off of their teammate.

2. (due Feb.1412 in class, hardcopy and D2L-group, one submission per team, .pdf or even .txt)
   Submit a proposal (10%):
   • 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.
     • What successor page(s) each form can lead to (with a ~one-sentence description of the criteria)
   • 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.

3. (due Feb.2720 23:59)
   Have a working git account for your project, with a Readme file, and every team-member having pushed at least one change. Add ibarland@radford.edu as a team-member to the git project.

   The Readme (presumably on bitbucket.org or github.com): Have a README file for the project, which includes the team name and their members (as well as usual README info: a quick overview of the project, what sub-directories include what major components of your project).

   And of course, Everybody should be pushing their changes to this repo regularly. Members who have commited nearly-no code which is included in the final version may be subject to significant loss of points.

4. (due Mar.2614 hardcopy in class, and on D2L (.txt or .pdf). One report per-team (not per individual).)
   Progress report I (2.5%):
   A short-but-specific written summary of progress and problems-encountered (less than one page), including which team-members have been contributing to which component(s).
5. (due Apr.11Apr.02) Prototype (10%), with a class demonstration (10%):
   • A stub for each page, with input fields and links (validation not fully required).
   • An instantiated database, even if just done in Excel tables or written on paper, 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).
   • Your group will present to the other technical-teams at your firm (er, class). You should describe your project briefly, along with what technical problems and (perhaps) solutions you have encountered: database issues you may have had, frameworks you are learning/using (or decided not to), organizational difficulties, etc..
   • Presentations should be 10-15min. I'll have the PC logged in under my account with a browser up, which you are free to use. (And if you don't, you'll want to be quick about connecting/opening anything you need for your presentation.)
   • 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. Certainly, have a plan of what each person will talk about (and presumably rehearse it ~once); the rest of the class doesn't want to stand around and watch you ask each other “who wants to talk next?”.
   • The pages and database design you present are locked in at this point.
6. (due Apr.1625 hardcopy in class, and on D2L (.txt or .pdf). One report per-team (not per individual).)
   Progress report II (2.5%):
   A(nother) short-but-specific written summary of progress and problems-encountered (less than one page), including which team-members have been contributing to which component(s).
7. (due Apr.30 (Tue)May.07 (Tue) 12:30 (our final-exam slot)) Final project (40%), with a class presentation (15%):
   • Demo your project, including full data validation and database connectivity.
   • This presentation should be viewed as demo'ing the project to prospective investors (who have a reasonable technical background).
   • In your demo, include a few moments to talk about technical and managerial difficulties you encountered (expected or not). (“Confessing” any problems won’t hurt your score; indeed it’s often the most learning-useful part of a presentation.)
   • Presentations should be 15-20min. I'll have the PC logged in under my account with a browser up, which you are free to use. (And if you don't, you'll want to be quick about connecting/opening anything you need for your presentation.)
   • Be sure that your projects are accessible for everybody to see/use at the URL: https://php.radford.edu/~projN/.
     • If you’re hosting your project elsewhere, that URL should have a link, or redirect.
     • Be sure others can use public (non-admin) features; if new users can’t create their own account then be sure to write a login&password at the start of your presentation.

       You don’t need to provide us with an admin account&password, but you might if you want to help your “prospective customers” try out the system they’re evaluating. And it goes without saying: if you are using another team’s admin account, don’t do any potentially damaging operations, like delete a database-row you didn’t add yourself, as an issue of the honor policy and basic human decency.

8. (due May.0208 (Wed) 17:00, hardcopy under my door ) Peer evaluation (10%):
   Evaluate both other groups’ presentations, and your teammates. itec325 project feedback

Your grade will be mostly the same for all group members, with some variation based on the team feedback form. However: If the group concensus and/or git logs show that a member contributed very little (including not communicating clearly and professionally), that student’s grade might be given a lower score (even 0), if warranted. The converse is not true: if one student implements far more than their share of the project, they will not necessarily get significantly more points that others. (I do not want students to feel like they must be martyrs, to complete their group’s work.)

Archiving your project

The project-accounts will be cleared, a few weeks into the summer! If you want to keep a copy of your work…

• Grab all the code files. (If you’ve been using github or bitbucket, this is already done!)
• Grab the database! In myphpadmin, there is an “export” button which will create a .sql script which, when run, re-adds all the tables and populates them.
• Make a screencast?
  If you want to link to the project in your resume/portfolio, but don’t want to keep the project hosted and live and updated-security, a screencast isn’t as good as a live site, but is better than nothing.

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

This page licensed CC-BY 4.0 Ian Barland Page last generated

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