1 / 50

Washington and Lee University

Waiting for WebRegistration: One Small College's Solution Scott Dittman, University Registrar Washington and Lee University sdittman@wlu.edu Jeff Knudson and John Hellmuth, University Computing at Washington and Lee MOSIS 2000 Springdale, Arkansas Session T.3.2, Tuesday, July 18, 2000.

darrin
Download Presentation

Washington and Lee University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Waiting for WebRegistration: One Small College's SolutionScott Dittman, University RegistrarWashington and Lee Universitysdittman@wlu.eduJeff Knudson and John Hellmuth,University Computing at Washington and LeeMOSIS 2000 Springdale, Arkansas Session T.3.2, Tuesday, July 18, 2000

  2. Washington and Lee University • Founded in 1749 • saved by a financial gift from George Washington • Robert E. Lee's only job after the "unpleasantness" • Lexington VA (pop. 7,000 including students) • 1,740 undergraduates, 360 law students • 4-4-2 (12-12-6) calendar initiated in 1969 • 190 undergraduate faculty, 3-3-1 normal teaching load • University Registrar's staff: • 2 exempt, 2 support, 2 PT students MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  3. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  4. W&LUniversity Computing today • Hardware • 1,300 university owned PCs; 90% of students own • personal Ethernet connections for campus residents, Novell NetWare • free dial-up PPP access for non-residents, faculty, staff • T3 Internet access, T1 for Lexis/Nexis, backup T1 • Staffing • 25, several of whom are permanently assigned to support specific schools or departments - only 1 administrative programmer/analyst • Budget • $500,000 non-salary annual operating • $1.5-2.0 million annual capital including replacement MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  5. The problem • Manual system: paper forms, headcounts,wait lists • Long lines outside of department offices and the registrar's office - students cutting class, esp. early • Outdated information, poor communication • Poor enforcement of registration priorities • W&L idiosyncrasies (calendar, balance, no section registration, 75% of all courses required a signature) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  6. The charge In 1995, as part of developing a University-wide, 5-year strategic plan, the president charged a group of faculty, staff, and students to "determine the means and timetable for a flexible and widely accessible on-line registration process, estimating the feasibility and benefits, as well as the costs and liabilities. Consider compatibility with the degree audit program and other student records, and also the relation of registration to matriculation." MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  7. The first committee • Comprised of the following: • 6 faculty, two of whom are alumni: • disciplines: mathematics, journalism, French, religion, physical education, management • 2 students, a sophomore and a senior • 4 administrators: • university registrar, associate academic dean, controller, director of administrative computing • Met for 5 months: Oct.1995 through Feb.1996 MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  8. The priorities • NOT paper-based • Faculty control of enrollments and advising • Minimize signatures; let the system count noses • Easily updated with added or deleted courses • Interactive so students know what's open (course availability) • End with balanced enrollments within a course • Cost-effective • Secure, confidential, and fair • Appropriate staffing support MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  9. The options • Online with hard wiring directly to mainframe • problems: security and user training, no interface, firewall, cost of dedicated terminals/PCs • had been tried in 1987 with only mixed success & acceptance • looked at Oberlin's system which allowed for off-campus access • Telephone registration (voice response) • problems: perceptions of less personal contact, "high" initial financial and labor cost ($35,000-80,000), high continuing maintenance costs (primarily labor) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  10. The options (cont.) • Customize existing software • Datatel customer since 1982, live since 1983 • Software at that time did not have an "easy" interface • Costs for out-sourced programmer estimated at $150(!) an hour (now much higher) with no internal commitment to staffing for long-term maintenance MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  11. The options (cont.) • Delivery via intranet/Internet as web page • problems: • still relatively new (remember, this is 1995-96) • costs unknown • access by faculty and students not ubiquitous • advantages: • "it's coming fast,” promise of long-term stability & ease of maintenance - commitment for the University in place, including campus-wide network and widespread e-mail use (97% of students, 98% of faculty) • had staff expertise on both sides of the data manipulation stream (Datatel data exporting, web/Perl programming) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  12. The initial recommendations(March 1996) • -move advising to the week before the registration process rather than during registration week • -develop a one-year calendar for planning, programming and testing, and involve all segments of the university (offices, department heads and faculty, students) in the development • -install secure web software on the campus network • -arrange for custom programming • -confirm the technical requirements for hardware availability and capacity • -develop faculty and staff training information and student documentation and instructions MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  13. In the meantime … • All computing issues were removed from the Five-Year Plan recommendations • Met individually with department heads to find one system to which all departments would subscribe • Continued with manual registration (paper forms, lines, signatures) • Recommendations were implemented piecemeal • Fall of 1997, two events moved us forward ... MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  14. Kick start • University Computing offered to help me develop a web interface for registration (October) • Upperclass students panicked the freshmen with rumors of getting no courses if they didn't spend the night waiting for registration signatures. Approximately 80% camped out (November) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  15. Committee #2 is formed • In January 1998, the urgent charge was to develop a WebRegistration system which would • approximate the priorities of the redesigned manual registration process • eliminate lines • operate interactively • enforce the system fairly regardless of department MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  16. Committee #2 • Comprised of the following: • 4 faculty: • disciplines: chemistry, journalism, physical education, politics • 2 students, the freshman class president and a sophomore • 6 administrators: • university registrar and assistant registrar, associate academic dean, controller, director of administrative computing, systems analyst, webmaster/systems specialist • Met for 4 months: January through April 1998 MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  17. Priorities • Eliminate paper • Increase quality advising time • Changes in offering and availability immediately accessible • Transfer mechanics to students • Allow for “standing” in multiple lines • Don’t cut class to do registration • Improve communications between faculty, students, and University Registrar MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  18. Process • Consensus, rather than majority votes • Individual and group creativity • Formatting proposal from University Computing • Reactions to formatting proposals • Constant “tweaking” of appearance and mechanics • Introduce one piece at a time • Frequent public comment, including web forum MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  19. Schedule • -PreRegistration (added late from student suggestions and faculty interest) - May 1998 for Fall 1998 - followed with final paper registration • -Freshman PreRegistration - Summer 1998 - results given to advisers as conversation starter(overhead) • -Late summer classes for advisers - mechanics and strategy • -Upperclass students change paper results - September 1998 (total of 200 made changes on the web without instruction but with nearly 100% positive feedback MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  20. … continued ... • Fall 1998 freshmen registration completely web-based, without training (“how self-evident” test). • Hotline/HelpDesk staffed by University Registrar and volunteer deans and faculty for those students whose advisers had problems or preferred not to do computer work • System ground to a halt because, unbeknownst to the planners or computing staff, a parameter limiting the number of simultaneous web transactions was in place. As soon as the parameter was increased, the process resumed without incident. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  21. … continued ... • Manual drop/add process has continued (one week, simple form, avoids need for additional advising password) • October 1998 - first all-campus PreRegistration (98%) • extensive documentation on the web, getting hundreds of hits • numerous offerings of training/feedback classes, few attendees • November 1998 - first all-campus WebRegistration • late registrants dropped from 65 to 4 MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  22. W&L WebReg system: Hardware • Today • T3 to internet with T1 backup through alternate provider • 1 Gb campus backbone • "Liberty" web server: HP 9000 D250, running dual 100 MHz processors, 10 Mbs connection to backbone • "Augusta" database: HP 9000 K200, running quad 100 MHz processors, 10 Mbs connection to backbone MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  23. WebReg: Software • Administrative database software is Datatel’s Colleague, release 13.13 on Augusta • Composed of five sets of software on Liberty: • Central Systems Interface • Student Access • Faculty Access • Administrative Control • Archiving and Health Checks MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  24. WebReg: Central Systems Interface • The Central Systems Interface is composed of a Perl client program on Augusta, which passes commands to a Perl server process on Liberty, which in turn executes the appropriate WebReg database functions. These commands include the creation/modification/deletion of courses, the creation/modification/deletion of student accounts and updates to the Hold table. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  25. WebReg: Student Access • The Student Access software provides an interface between the web server on Liberty and the student WebReg databases. Through these Perl scripts, students may view, add and drop courses from their registration schedule. They may also view listings of available courses and view the current enrollment numbers and limits for each course. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  26. WebReg: Student Access • Two passwords (random 4-digit) • PreRegistration: course interest, provided by e-mail • Web Registration: sent to advisers for release after advising • Assigned access window (36-60 hours) - starts every 30 minutes from 10 am to 3 pm • Class • PreRegistration participation required • History of start times - average at 12:30 pm over 4 terms • Current class schedule • Random within class (overhead) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  27. WebReg: Student Access • The chart below shows freshman WebReg traffic; red = the number of simultaneous Web connections, blue = the total load on Liberty(overheads) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  28. WebReg: Student Access • http://www.wlu.edu/registrar/newreg.htm MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  29. WebReg: Faculty Access • The Faculty Access software provides an interface between the web server on Liberty and the course functions of the WebReg databases. Through this Perl script, faculty may accept students into a course from a wait or permission list and send group emails to registered or wait‑listed students. Department heads may set course enrollment limits, modify the class distribution of the limits and set a message to be displayed to registering students. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  30. WebReg: Faculty Access • Two levels of passwords sent to department head only • Department head: allows determination of course limit mode and numbers, special message, and faculty privileges • Faculty member: allows manipulation of wait lists and use of e-mail features • Limit modes • Single limit - first come, first served • Class limits • Major/non-major limits • Permission required - also single limit plus faculty action MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  31. WebReg: Faculty Access • http://olr.wlu.edu/cgi-bin/apps/registrar/reg/list.pl • http://olr.wlu.edu/cgi-bin/apps/registrar/reg/fac.pl MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  32. WebReg: Administrative Control • The Administrative Control software provides an interface between the web server on Liberty and the administrative functions of the WebReg databases. Through this Perl script, the University Registrar may control access to the WebReg screens and toggle the ability of faculty and students to modify the WebReg data. Event logs are available by day or by student. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  33. WebReg: Administrative Control • Super user • Maintenance and override access for all functions, including passwords, holds, and times • Access to logs (current term) and archives (previous terms) • Access to history of communications: conflict messages, prerequisite checking, wait list permission, course cancellation e-mails MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  34. WebReg: Administrative Control • http://olr.wlu.edu/cgi-bin/apps/registrar/reg/admin/index.pl MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  35. WebReg: Archives • Every half hour, during registration, checkpoint files are created (cron processes) which archive the state of the course and student databases and updates the Datatel database. • The entire WebReg database structure may be recreated from any set of these archive files. An audit program compares versions, verifies the integrity of the WebReg databases, and debugs any discrepancies. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  36. WebReg: Archives • Archive Files: a plain text snapshot of the WebReg databases. They are composed of three files, Courses, Enrollment, and Student. • Courses: department, course, title, credit(s), general education flag, limit mode, limits, equivalent (cross-listed) course, permission required flag, associated majors, faculty password, department head password, associated message • Enrollment: student user name, selected courses, first choice wait-listed courses, second choice wait-listed courses, PE courses • Students: user name, password, full name, year, major, maximum allowed credits, holds, start time, end time, adviser MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  37. WebReg: Data • Composed of the following data stores: • Course Databases • Enrollment Databases • Student Databases • Hold Table • Event Logs • Archive Files MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  38. WebReg: Course Data • Course Databases: Perl DBM containing the descriptive elements for each course. • department, course, title, credit(s), corequisite(s), prerequisite(s) • general education area notation • limit mode and limits and permission required flag • equivalent (cross-listed) course • associated majors • faculty username and password, department head user name and password • associated message MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  39. WebReg: Enrollment Data • Enrollment Databases: Perl DBM containing the students registered for or waiting for admission into a course. • counter • data for each student - student user name and ID, class year, major(s), credits accumulated MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  40. WebReg: Students Data • Student Databases: Perl DBM containing the descriptive elements for each student as well as the list of courses that the student has selected. • user name, password • full name, class year, major(s) • hold flags, start time, end time, adviser, • maximum allowed credits (14 in long terms), current credits accumulated, number of wait lists, number of permission lists, pending notice to student, courses selected, courses waiting, PE courses selected MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  41. WebReg: Holds • Hold Table: a text file containing the hold flags codes, descriptions, and associated phone numbers, for example, • RG*REGISTRAR’S OFFICE*463‑8451 • BO*BUSINESS OFFICE*463-8730 • LR*LIBRARY-REG ALLOWED*463-8643 • IR*HEALTH CTR-REG ALLOWED*463-8401 • Hold flags update cron is run every 5 minutes MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  42. WebReg: Logs • Event Logs: text files containing detailed logs of each event that occurs in any of the WebReg subsystems. • time stamp • user name • event and description (drop from schedule, drop from roster, admit to course, warnings, etc.) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  43. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  44. WebReg: Results • WebReg results are run through batch process to assign times and balance schedules • Schedule available via the web to students • Advisers receive an e-mail schedule for each advisee before and after drop/add MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  45. WebReg: • Demo time! MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  46. WebReg: Bug List • Under very heavy load, a race condition may occur if a student adds a course then immediately resubmits the same request. No data corruption occurs, but the second process hangs and must be terminated by a watchdog program (also a Perl script). This will be resolved when the SQL database is implemented. • If a user uses the Back button to overwrite PE courses, he may cause an entry to be dropped from the course database that still exists in the student database. This will be resolved when the SQL database is implemented. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  47. WebReg: Enhancements • Replace the many Perl DBM databases with a SQL database. • Rewrite the databases access modules to take advantage of Apache Fast‑CGI, which will greatly improve performance by eliminating the need to spawn a new process whenever a database event occurs. • Rewrite the authentication code to integrate the Novell NetWare user accounts for students and faculty. • Migrate the entire package to a compiled language such as C++ to increase performance. • Develop faculty post-WebReg advising & course management • Others??? (e.g. move to secure server) MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  48. Information Links • Technical assistance and contacts: • John Hellmuth, jhellmuth@wlu.edu, Systems Analyst: Datatel database, Unix, cron, Uniquery reports • Jeff Knudson, jknudson@wlu.edu, Network & Systems Specialist: webmaster, Perl, Unix • University Registrar's page: • www.wlu.edu/registrar • WebRegistration instructions and strategies page: • www.wlu.edu/registrar/newreg.htm • WebRegistration starting page (no password required ‑ feel free to play): • olr.wlu.edu/cgi-bin/apps/registrar/dev/admin/index.pl MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  49. … links continued ... • Planning group: • www.wlu.edu/registrar/webreggrp.htm • WebRegistration development feedback forum: • www.wlu.edu/cgi-bin/apps/forum/aforum.pl?forum=online_reg • WebRegistration process articles: • advice to students (April 1998): www.wlu.edu/computing/news/access/97-98/march/webreg.html • first feedback report (June 1998): www.wlu.edu/computing/news/access/97-98/June/webreg.html • follow-up report (January 1999): www.wlu.edu/computing/news/access/98-99/jan/05register.html MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

  50. Questions or Comments??? • Thanks for coming. MOSIS 2000 T.3.2, Waiting for WebRegistration: One Small College's Solution

More Related