Reference and Instruction Automated Statistics Gathering and Reporting System Members: Patrick Chen (pyc7) Soo-Yung Cho (sc444) Gregg Herlacher (gah24) Wilson Muyenzi (wm59) Colin Reuter (chr8) Nurwati Widodo (ncw4) March 10 th, 2005

Project Overview Client: Cornell University Library System Objective: Build a system for the Cornell library staff to input their instructional and consultation sessions data to a centrally managed system database. Goal: The system will help the library staff to produce reports, edit information and view statistics of the session from the web.

Overall System Diagram LoginLogin Instructional Form Consultation Form Query Form Database Submit Edit Submit

System Design Flowchart Home Page User Admin Query Instructional FormConsultation Form Submission Summary Page Edit Submit Login Search Page Query Result Page Individual Result Page Add/Delete/Edit Users Confirmation Page Edit DB Fields

Use Case – Standard User Individual: Philip Glass, a Cornell University library instructor at Olin Library. Philip Glass has a Cornell- issued NetID and password. He has been authorized to access the system by an admin user. Equipment: Dell computer, a typical Cornell University library computer. Computer has Internet Explorer installed.

Use Case – Standard User Scenario: 1.Philip Glass powers up computer 2.Philip starts up browser and types in URL to access system 3.The system displays CUWebLogin 4.Philip types in NetID and password 5.System displays list of options: Consultation form, Instructional form, Query

Use Case – Standard User (cont.) 6.Philip wants to input new consultation session He clicks on Consultation form input button 7.Philip fills in all required entries, additional optional entries 8.Philip clicks submit button System shows individual result page with options to edit or complete submission

Use Case – Standard User (cont.) 9.Philip confirms he has input data correctly System redirects to system home page 10.Philip clicks log out link System logs user out 11.Philip logs out of browser

Use Case - Administrator Individual: Dave Roberts, a Cornell University library instructor at Olin Library. Dave Roberts has a Cornell- issued NetID and password. He has been authorized to be an administrative user for the Reference and Instruction Automated Statistics Gathering and Reporting System. Equipment: Dell computer, a typical Cornell University library computer. Computer has Internet Explorer installed.

Use Case - Administrator Scenario: 1.Dave Roberts turns on computer 2.Dave Roberts starts up browser, types in URL for system 3.System displays CUWebLogin 4.Dave enters NetID and password 5.System displays list of options Dave chooses Administrative Tasks link

Use Case – Administrator (cont.) 6.System displays Administrative Tasks page 7.Dave selects new user option System displays page with user information fields 8.Dave fills in all required fields, any additional fields 9.Dave clicks submit button System displays information Dave just entered, with options to edit or complete submission

Use Case – Administrator (cont.) 10.Dave confirms he has input data correctly System redirects to Administrative Tasks page 11.Dave clicks on log out link System logs user out 12.Dave closes browser

Functional Requirements The set of tasks each class of user will perform Two classes of user: –Administrative –Standard

Standard User Tasks Insert new records –Data about instructional or consultation sessions Edit records –Edit records the user has input previously View records –View all records in database

Administrative User Tasks Add/Edit/Remove Users –Administrators can add, remove, or change status of users Edit Form Data Choices –Ability to edit fields on the instructional or consultation forms Edit All Records –Ability to edit any record in the database

Standard User Tasks: Insert New Records User chooses “Instructional” or “Consultation” User enters data for all required fields, can choose to enter data for optional fields User submits form after entering data

Standard User Tasks: Editing Records User edits records using form similar to insert new record form –Form already filled in with data User may edit any data he wants User can choose to accept or reject all changes

Standard User Tasks: Viewing Records Users view records by selecting “Query” link from home page Users can choose to search all records or to search their own sessions Users can choose from set of criteria to search from Users can edit their own records only

Administrator Task: Users Users identified by NetIDs Administrators can modify user status (Standard, Administrator) Administrators can delete users Administrators can add user, user type

Administrator Task: Forms Administrators can choose to add or delete fields in the instructional or consultation form –Edit: all records will refer to new data choice –Delete: Old records will retain deleted data choice New records will be unable to access deleted data choice

Usability Interface –Language: English –Simple, Clear and Intuitive –HTML –Color Coded Pages –Readable: acceptable font size –Scalable

Usability (cont.)

Help System –Link to simple online help guide –Contact of administrator or library staff for help Error Free –Perform as outlined –Errors as minimal as possible

Performance / Hardware Server –MySQL and PHP –Server provided and maintained by client –Reliability administered by library staff Availability –Require Cornell NetID and password –Accessible by anyone pre-decided by library staff –Denied access  Contact / Explanation Page

Performance / Hardware (cont.) Load and Process Time –HTML pages load under 10 seconds –Input process less than 1 minute –Query response less than 1 minute

Interoperability HTML –Common language, preferred by library staff –Readable by any device with a web browser PHP –Preferred language of library staff HTTP –Most common form of communication among HTML pages –Allow users on any platform access with an active internet connection to our system

Interoperability (cont.) MySQL –Common type of database most familiar by library staff

Training / Documentation Training –Intuitive –Understand short documentation in under an hour –Help page –Tool tips

Training / Documentation (cont.) Documentation –Explanation of ambiguous concepts and forms –Clear and short, readable in under one hour –Each individual page explained

Legacy Method of Storage –Database and its protocol will last long enough such that the data is not lost (MySQL) –Deprecated input form data stored such that queries on old properties can resolve –Deleted entries will be lost permanently Method of Communication –HTML will last for 1+ years

Quality Assurance Testing –Thoroughly tested by creators –2+ hours of final testing Approval –Final product approved by clients –Weekly discussion with clients on issues of implementation

Legality and Business Rights –Full copyrights transferred to client upon completion –Client able to use, modify and distribute freely

Security and Authorization Security –Users unable to edit data of other users –Users must be authorized by Cornell University –Users must be authorized by administrator of the system to view data

Security and Authorization (cont.) Authorization –Users authorize themselves via Kerberos and CUWebLogin as is the norm at Cornell University –Unauthorized users not given access –Directed to either system home page or notification page that user is not a member of the system

Status Update Milestone #1 –Database Design & Web Server Configuration –User Input Interface (HTML & CSS) Design for Instruction and Consultation Form –Database interface code (PHP) –Meetings with Client –Comprehensive list of client requirements produced

Demos

Gantt Chart Current Status

Future Works Milestone #2 –User Authentication System (Kerberos) –User Interface (HTML & CSS) for Administrative System –User Interface (HTML & CSS) for administrative tasks of library staff –User Interface (HTML & CSS) for Data Retrieval/Reports System

Future Works (cont.) Database interface code (PHP) Refinement of deliverables from milestone #1 Meetings with Client

Questions?