Peter Austin, Information Technology Division, Edith Cowan University, Pearson Street, Churchlands WA 6018. Phone: +61 8 9273 8268, Fax: +61 8 9273 8000, Email: p.austin@cowan.edu.au.
Vaughan Castine, Information Technology Division, Edith Cowan University, Pearson Street, Churchlands WA 6018. Phone: +61 8 9273 8668, Fax: +61 8 9273 8000, Email: v.castine@cowan.edu.au.
World Wide Web, University, Student Administration, Database Access, Internet application.
Large universities face difficulties with managing student enrolment administration due to increasing student numbers, distributed over multiple locations, and reduced staff levels. This paper describes the requirements, development and implementation of a Web-based database application used for student administration. The background to the development of the application is outlined. This is followed by a description of the first two phases of the project. Issues arising from the implementation are discussed and future development plans are outlined.
Edith Cowan University [HREF 1] (ECU) is located on five main campuses in Perth and Bunbury in Western Australia, with further learning centres in regional areas and overseas. With over 18,000 students, ECU is one of the larger universities in Australia.
Such a large number of students, spread over a wide number of locations, creates a need for improved access to, and management of, student information. The development of the World Wide Web and its integration with database technology has enabled the Internet to become the platform for a new generation of application; one that ensures all staff and students have access to information from the same source, regardless of their physical location.
This paper describes the implementation of such an application - ECUWES. The following sections discuss the reasons why ECUWES was needed, how the initial two stages have been implemented, and issues that have arisen from that implementation. Finally, some of the future enhancements planned for the application are outlined.
Historically, re-enrolling students completed their unit enrolment forms, journeyed to the university, stood in line, and waited to be served by Student Administration staff. Faculties which held tutorials, practical classes, laboratories and workshops asked their students to enrol in these either by posting enrolment sheets on bulletin boards, or by directing the student to visit their staff at a specific time before semester began. These processes were time consuming for both staff and students.
Access to information, prior to ECUWES, was a case of feast or famine. Exam results were posted on noticeboards and students were sent their accumulated course results. Students could request (and pay for) transcripts if they required any other check on their academic history. As there are no security roles in the legacy Student Records System (SRS), staff members granted access to it have access to all students' personal information and academic history. Information needed to be provided as required and only to users who had a right to use it.
Changes to the allocation of university funding is forcing many universities to provide (at least) the same service with fewer resources. ECUWES shifts the resource focus for student enrolment from a costly human intensive model, to a model that utilises the IT infrastructure of the University.
Online enrolment has allowed ECU to re-engineer its business processes. Having the students enter their own data has reduced the bottleneck of data processing, and as a result the staff workload peaks have been flattened out. This has allowed other process restructuring to begin, for example ECU can now provide a larger window for the re-enrolment period.
Funding changes have also led University administrators to align their services to their business - ECUWES gives Edith Cowan University a competitive edge. Enrolment is available to our customers where and when it suits them. Potential students without Internet access can utilise the facilities provided on campus, and as the online enrolment can be faster these students will have received better service.
ECUWES has been implemented using Oracle WebServer [HREF 2] integrated with an Oracle database. HTML code is generated by PL/SQL stored procedures which access data within an Oracle database.
Oracle was selected because, as a member of the UniOn Group, ECU has adopted the Oracle database as a standard for storing corporate data and, hence, has a site licence. In addition, the Oracle solution provided a more attractive option than developing the application using CGI for a number of reasons:
Although some early planning had taken place for the ECUWES project since May 1996, the implementation of Phase 1 of the project did not begin until October 14th. The system went into production five weeks later on November 18th. The tight schedule was due to a requirement to allow students to use the system for 1997 re-enrolments and, consequently, only a limited set of facilities were implemented.
The figure below shows the ECUWES login screen [HREF 3] .
The requirements for Phase 1 of the ECUWES project were to:
Access to the Timetable
Access to the semester timetable was provided in order to allow students to plan their enrolments. By entering a unit code, a table of events for that unit was returned. An event is defined as an activity (such as a lecture, tutorial, workshop or laboratory) that occurs at a particular time and location. Each event is allocated a unique identification number and is classed as either primary (lecture, seminar) or secondary (tutorial, laboratory, workshop). Users do not need to login to ECUWES to use this feature.
Access to Academic Record and Re-enrolment
Once a student had logged on to ECUWES, they were presented with a page displaying their contact details plus a list of courses that they were, or had been, enrolled in. Students could then select a course for which to display their academic record or, if the course was current, re-enrol.
Re-enrolment was made available for a specified period (approximately six weeks). During that period, students could enrol in units, changing their enrolment at will. At the end of the enrolment period, students could no longer access the enrolment option.
When the re-enrol option was selected, the user was presented with a page displaying a list of units for which they were already enrolled (if any). They were also provided with the option of withdrawing from a listed unit or enrolling in another unit. Students enrolled in a unit by selecting a primary event belonging to that unit. Note that the system only provided for enrolment in primary events; enrolment in secondary events was to be added in Phase 2 (see below). When an event was selected, ECUWES performed some comprehensive verification to ensure that:
Student Administration staff were also able to enrol students via ECUWES. This facility was provided to cater for students who either elected to continue with the paper-based re-enrolment procedure or who could not access ECUWES. Such enrolments had to be done via ECUWES rather than SRS to ensure that quotas were not exceeded (a consequence of the 24-hour cycle of data exchange described below). Staff were able to change student enrolments at any time.
Security
Security was implemented at three levels. The first level was to deny any access by students to the SRS. This was achieved by physically separating ECUWES from the SRS and transferring data on a daily basis between the two systems. A description of this process is described in more detail below.
The second level of security ensured that the range of functions made available to a logged-in user depended upon their access level, with students accorded the lowest access level, Student Administration staff the next level, and the ECUWES administrator the highest level. Staff logged in using an allocated login name and 4-digit PIN. Students logged in using their student number and a 4-digit PIN.
All students were issued with an initial PIN, which they were required to change the first time they logged in. Of course, there was nothing to prevent a student from providing their student number and PIN to other students, but this would not have been in the student's best interest.
The third level of security, applied once a student had successfully logged in, provided for a certain level of privacy at the workstation. This was particularly important in a computer laboratory situation. Security implemented at this level consisted of:
Performance
Providing a suitable level of performance meant selecting the correct server platform. Unfortunately, determining an appropriate configuration was difficult due to a lack of information concerning the resources required. Neither Oracle nor IBM, who was providing the server on loan, could provide any helpful advice. In addition, because of the short timeframe there was no time for load testing before ECUWES went into production.
The system went into production running on an IBM RISC/6000 model C20 with 128MB of RAM and 4GB of disk storage. The operating system was AIX 4.2. It quickly became apparent that this configuration was inadequate. Response times became very long as students and staff began using the system. The server was quickly replaced by an IBM RISC/6000 model 590 with 256MB of RAM and 11GB of disk storage, spread over a number of physical disks. This change, plus additional tuning of the Oracle database, provided acceptable performance.
It has become apparent, both from our experience and the experiences of others on the Internet [HREF 4], that the major limiting factor in Web server performance is RAM and that 256MB is a minimum workable configuration. This is particularly important considering that the server was running both the Web listener/broker software and the database engine.
In order to prevent any student access to either the SRS or Timetabling System (TTS) servers, ECUWES was installed on a server located on the student network. Consequently, data needed to be exchanged between ECUWES and the other two systems on a regular basis. The process of data exchange is based upon an automated 24-hour cycle and proceeds as follows:
The data exchange process has been structured so that failure at any stage will force ECUWES to remain off-line. Maintaining the correct sequence of exporting and importing is crucial to the integrity of the data. It is worth noting that the data exchange component of the project was one of the more difficult to implement.
The diagram below shows a schematic of the data flow.
Students were very receptive and positive, even enthusiastic, about ECUWES Phase 1. They found the ability to obtain results the most useful aspect, whilst the ability to re-enrol via the Internet was of significant benefit to overseas students. The students were also very positive about recommending improvements and enhancements, and the ECUWES development team made sure that all student enquiries were responded to.
Student Administration staff were less enthusiastic for two main reasons:
The requirements of ECUWES Phase 2 Module 1 are to enhance the system developed during Phase 1 to:
It is interesting to note that whilst Phase 1 required students to cross-reference and utilize a unique id for each event, Phase 2 Module 1 moves away from this format and allows students to deal with events based upon the unit code. Students are no longer shown the event identifiers. Administrative staff still have the opportunity to enrol students by the event id, however this method makes it more difficult for them to perform a complete unit enrolment.
A Javascript demonstration of the Phase 2 Module 1 user interface is available from http://mite.cs.cowan.edu.au/ausweb97/ecuwesdemo/ [HREF 5]
Secondary events include tutorials, laboratories and workshops. Allowing secondary event enrolments via ECUWES provides students with the ability to complete their entire unit enrolment in one step.
After selecting a unit and a campus, the event details for the chosen unit are presented to the student as shown in the figure above. Selecting from the displayed combinations of radio boxes and check boxes, a user is able to choose all events required for a particular unit. Events that are full or cancelled will still be displayed; however these events will be unavailable for selection. When a student tries to enrol in a unit in which they are already enrolled, the display includes their current enrolment information and the student will be provided with the opportunity to modify their enrolment.
Some Faculties structure their timetable to provide groupings of events. From the student perspective this makes enrolment far easier and has locally been termed the 'slick pick' enrolment.
There are 2 levels of system validation; when the student selects events, and when the student confirms the changes to their enrolment. In addition to the checks implemented in Phase 1, ECUWES Phase 2 checks that:
Various reports can be generated by ECUWES. Unlike other parts of ECUWES, client-side caching is enabled to allow the reports to be printed.
Different reports and content levels are available for the various levels of users accessing the system. For example, administrative users may need to notify students of timetabling modifications, so would see more information about students than academic staff. Similarly academic staff would be less likely to be interested in utilization and enrolment statistics than an administrative user.
Student Timetables
In Phase 1 all users were given access to the University semester timetable. As part of Phase 2 we provide the ability for a student (or an administrative staff member) to generate and print the student's timetable. As students are most likely to be printing reports within the University laboratories, the only personal information included on student-generated reports is their student number. However, administrative staff receive more information to assist them with identifying and contacting each student.
Class Lists
Academic and administrative users have been provided with the ability to generate and print both event and full unit class lists. For administrative users these lists are active links back to the enrolment details for each student.
Unit Statistics
To allow better room allocation and examination timetabling, administrative staff need to know how many students are enrolled in a unit and what methods are available for dividing the students. Current methods include statistical breakdown by the student's surname (alphabetically), stream enrolment (groups), campus enrolment and individual event enrolment.
Notification Reports
Sometimes events have to be modified for administrative reasons. As a result of timetabling changes some students may need to modify their enrolment to prevent a clash or to complete their enrolment. Administrative staff need to be able to generate reports to see which students need to be notified.
To prevent excluding some of our customers all development is targeted at the lowest common denominator. This approach means that tools such as Java and Javascript cannot be relied upon for business logic. To increase functionality some non-essential items such as input focus are coded in Javascript. Similarly Javascript is used for some essential validation checks and calculations to remove the load from the web server. In cases where Javascript is used with essential functions, a PL/SQL procedure is available as a backup for browsers that do not support Javascript.
As notification reports are mailed to many students a method to create separate printable pages is required. The inability of HTML to issue page breaks impacted upon the method by which notification reports have been implemented. Options considered to resolve this problem included:
Hidden form fields must be used to maintain connection state information in the stateless environment of the Web. To reduce the risk of this information being misused caching is disabled in most parts of ECUWES. Reports that can be printed are the exception and the challenge faced is how to allow printing whilst maintaining security.
For the ECUWES implementation the limited expiry option was chosen to provide more functionality. Security can only be compromised if a user does not log out correctly. Therefore, the risk is small and the onus is on users to protect their login.
No matter what platform and tools are used for development, the functionality versus usability dilemma is bound to arise. For the Web, issues include:
The statement that Internet years are like dog years is true. Development tools are always struggling to keep up with the evolving Internet standards. This constant evolution of tools threatens to make the current toolset (and possibly even the current implementation) obsolete. An example of this is Oracle WebForms that was in beta during the development of Phase 2 Module 1.
Recently, tools have been released that make the creation and publishing of HTML documents relatively fast and painless for inexperienced users. These tools do not guarantee that the documents created will contain meaningful content, and few allow for the creation of large scale dynamic sites. Whereas application development was once worlds away from the typical end user's experience, today the environments are merging and some users have the idea that web database applications can be brought to production as quickly as smaller static sites.
ECUWES will continue to evolve. Phase 2 Module 2 will allow new students to enrol via the Internet - where possible this will include checking details with the Tertiary Institutions Service Centre (TISC) database of school leavers. We also have plans to investigate:
This paper has described the requirements, development and implementation of the Edith Cowan University Web Enrolment System (ECUWES) - a Web database application. This project began late in 1996 and has already generated great interest from both students and staff. The potential for this application to assist in the administration of the University is immense. The wealth of proposals for enhancing the current system are evidence of this and it is expected that the system will continue to play an important role in the University's future.
Peter Austin, Vaughan Castine, Edith Cowan University ©, 1997. The authors assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grants a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers, and for the document to be published on mirrors on the World Wide Web. Any other usage is prohibited without the express permission of the authors.