This paper was presented at CUMREC '99, The College and University Information Services Conference. It is the intellectual property of the author(s). Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and that the title and authors of the paper appear on the copies. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the authors.


Cooperative Education and the Web:
Linking Students, The Educational Institution and the Work Place

University of Waterloo, Waterloo, Ontario

David Thomas, Associate Director, Co-operative Education & Career Services

Rick Roach, Program Coordinator, Co-operative Education & Career Services

David Kibble, Strategic Consultant, Information Systems and Technology.

Philip Engle, Vice-President

Academic Software Inc., Austin, Texas

Institutional Overviews

University of Waterloo commenced in July 1957, with the introduction of the Co-operative Engineering Program. Co-op programs are now offered in Applied Health Sciences, Arts, Engineering, Environmental Studies, Independent Studies, Mathematics, and Science. Co-operative education is based on the principle that during the undergraduate years an academic program combined with integrated work experience in alternating terms, is relevant to, and desirable for, effective professional preparation. The work terms allow students to acquire experience in their areas of career interest, while the academic terms are devoted to fundamental and theoretical studies. Necessary arrangements for integrating work terms, securing potential employers, arranging interviews, and generally managing the employment process are the responsibilities of the Co-operative Education unit. Field co-ordinators advise students, visit them on the job, assist them to adjust to work situations, and encourage their professional development. Academic Software Inc. is the industry leader in providing creative solutions to Career Services Professionals. With clients in United States, Australia, Guam, Canada, Siam, and South Africa, Academic Software has truly become a company with an international perspective. Academic Software has experienced incredible growth over the past several years. With a reputation for innovative products, quality technical support and a great deal of word-of mouth advertising they have grown to over 600 clients worldwide. These clients include large universities, small community colleges, corporate human resource offices, government agencies, and even high schools. In the past year they have brought their clients into the 21st Century with cutting edge Internet applications.

Abstract

The University of Waterloo and Academic Software Inc. are working together to develop a totally integrated Web based system, used by employers, students and the university for the student recruiting process, known at UW as the ‘CECS.online Project’. Employers can use the Internet to make all their recruiting arrangements. Employers can submit jobs, book interview rooms, view resumes packages of students that have applied to their jobs and select students for interviews. After the interviews are completed the employers are able to rank the students for job matching and then to view the students that have accepted their positions. Students are set up in the system based on information downloaded from the main UW student information system. This gives students access to the CECS.online system where they can update their personal information and to develop up to 3 electronic resumes. Once this information is complete students are able to view jobs, apply to jobs and monitor interviews on the Web site. After interviews the students are able to rank their positions for job matching. Most UW administration activities can be carried via the Web site. Some of the more complicated functions such as manipulating interview schedules are done through a W95 module. The database is Oracle based running on a UNIX server. The ASI application itself is NT based. Reporting is done utilizing COGNOS reporting tools. At the time this paper was written the system is still being developed and was in testing mode. It is anticipated that the pilot stage will be completed in the summer of 1999and that full implementation will take place in the fall of 1999. The presenters intend to review the features of the system and discuss the issues that have complicated the implementation of such a system. Short comings and future developments will also be discussed.

Cooperative Education and the Web:
Linking Students, Educational Institutions and the Work Place

Overview of Current Systems

The last major systems review for CECS began in 1988. This led to the UW in-house development of the current computer system, ‘CERVIS’. This application handles:

Two other related systems were developed:

Plans for the CERVIS system originally included an enhanced adhoc query or reporting tool and the automation of the resume and prescreen package distribution process. However, in 1993, significant changes were required to accommodate the ‘continuous placement’ or ‘offers’ process. This and changing institutional priorities and technological directions have prevented further development of those applications.

Why a New System?

The existing CERVIS system has been operational for approximately 10 years. There has been considerable pressure in the last few years for UW to enhance the services to students and employers in the recruiting process. The new CECS.online system addresses a number of concerns with the existing system including:

1. Reduce costs

2. Streamline the process and improve efficiency

3. Expand participation in program by allowing:

4. Improve CECS image

Product & Vendor Summary

A number of options for the acquisition and development of a new system were considered, including:

A survey of a number of institutions using ASI products was undertaken. All of the ASI customers interviewed were satisfied with the products and service and none of the universities had any concerns with the vendor’s ability to develop a new web-based product.

Academic Software Inc. is based in Austin, Texas. ASI specializes and is the industry leader in co-op and graduate recruitment software. ASI has:

The Development Exercise

Following a vendor (ASI) visit in September 1997, the following steps were agreed to:

  1. Completion of an Assessment and Deliverables
  2. Functional and Technical Agreement
  3. Resources and Business Case Discussion
  4. Contract Negotiation
  5. Project Initiation

Minimum Functional Requirements

The functional items to be included in the development of the CECS.online system proposed included the following:

  1. Allow employers and UW staff to enter job listing and interview schedule information via the World Wide Web (WWW) for student viewing.
  2. Provide a WWW vehicle to collect student registration information, including the development of a resume, the collection of skills and interests as pre-defined lists, and the possible importation of marks information.
  3. Provide the ability for administrators (UW staff) to search, view and manipulate all student data.
  4. Allow students to submit "applications" on-line, expressing their interest in an employer’s position or interview.
  5. Allow employers to view via the WWW, any student information submitted to them with regard to a schedule or job listing. The employers will also have the ability to select students they wish to interview and will have the ability to view student information grouped by search criteria they define.
  6. Allow Administrators to produce for employers a packet of resumes resulting from a search, or associated with a specific job or interview schedule. These packets may be produced either in hard copy or via fax.
  7. Provide a feature as described in this document that will automatically arrange students on schedules.
  8. As an alternative to #5 above, allow students to select via the WWW, a time to interview of their choosing, once their request is accepted by the employer.
  9. Allow students to view all interviewing activity for themselves during the current academic year via the WWW.
  10. Allow employers to view all interviewing activity for themselves during the current academic year via the WWW.
  11. Allow administrators to view, alter and manipulate all schedule and related information.
  12. Following an interview, allow students to "rank" employers given the method described in this document.
  13. Following an interview, allow employers to "rank" students given the method described in this document. Following the collection of the rankings, students and jobs will be matched, also as described further in this document.
  14. Allow students to view and print a copy of their Co-op Student Record as described in this document.
  15. Allow employers to view and print a copy of their Hiring History as described in this document.
  16. Provide for importation of specified data in this document.
  17. Provide a reporting tool that will allow for UW staff to develop reports, or coordinate efforts with UW staff in using existing reporting tools.
  18. Information will be stored with each placement record allowing students and employers to enter evaluations of the work term.
  19. Year 2000 compliance.

Project activities included the completion of the detail system design, testing (module and system), workflow and training processes, conversion, reporting and other related implementation tasks. The proposed timeline would involve an initial implementation in spring 1999 of a relatively isolated group of students and employers in a pilot mode. The targets for complete implementation would be fall 1999.

Technical Issues

A number of potential technical issues were identified but none were viewed as "show-stoppers".

Some additional technical specifications must yet be negotiated with the vendor. These include such items as the ability for the product to use an external identification & authentication mechanism and to use the campus Legato backup infrastructure.

General Overview of Operations

The proposed system consists of three logical components:

Each of these components is described in greater detail below.

A common process invoked by a user would follow this procedure. Note that these processes can be run in tandem:

  1. The user invokes an action by selecting a process available to them in the HTML document that is their interface to the system.
  2. A connection is opened between the browser and the HTTP server, encryption keys are established and verified.
  3. A call to a specific function within a dynamic linked library (DLL) is passed from the browser to the HTTP server. The HTTP server executes the requested function.
  4. The DLL collects the parameters passed to the HTTP Server by the browser and calls a function within the Application using the Windows NT "pipe" convention.
  5. The Application Server pre-processes the parameters and data passed from the browser and DLL.
  6. The Application Server connects as the sole client to the SQL Server (if not already connected).
  7. The Application Server opens a thread and submits a series of SQL statements to the SQL Server to be executed.
  8. The SQL Server executes the statements and returns a result table to the Application Server.
  9. The Application Server processes the data in the result table, building a new HTML document.
  10. The Application Server closes the thread to the SQL Server.
  11. The Application Server passes the HTML document to the DLL via the still open pipe.
  12. The DLL passes the HTML document to the HTTP server and closes the pipe.
  13. The HTTP server passes the HTML document to the client browser and closes the connection to the browser.

HTTP (Web) Server

The primary interface for this system is a series of Hypertext Markup Language (HTML) documents generated dynamically at runtime. Each of these HTML documents has at least one embedded call to a dynamic linked library (DLL) which resides on the Web Server. Each call includes at least one parameter identifying the function within the Application that is to be executed next.

This DLL resides in memory on the server at all times. Its primary function is to receive parameters from the Web Server and pass them on to the Application Server. In the event that the application server is unavailable, the DLL will queue the requests for a pre-defined number of seconds before a time-out or error message is returned to the client browser which submitted the request.

Academic Software, Inc develops the DLL. The HTTP Server is any commercially available server that supports ISAPI protocols (i.e., MS Internet Information Service, O’Reilly’s WebSite).

Application Server

The Application receives a specific function call from the DLL as well as any parameters or data collected via forms. Each function call invokes one or more of the following possible actions:

  1. A SQL query is performed of a table containing HTML "chunks" to assemble the next HTML document to be returned to the client browser.
  2. A SQL query is performed of a table containing data and is combined with 1. above to form an HTML document.
  3. A SQL statement or statements is executed to append or alter data in an existing data table.
  4. The parameters sent by the DLL are pre-processed (as in field validation, etc.)

All SQL statements executed by the Application are 100% ANSI/ISO SQL 92 compliant. The intent is to develop an application that maintains portability across a number of SQL database platforms.

Database (SQL) Server

The SQL Server will receive SQL statements from the Application server, execute them, and return the result tables. The SQL Server is any commercially available database server that can interpret and execute ANSI/ISO SQL 92 compliant statements.

Hardware and Software

Web/Application Server

The HTTP and Application Server will be housed on Pentium based machines. The processing role of the HTTP Server is negligible, eliminating the need to have it serve on a separate machine. Further communication between the DLL run by the HTTP Server and the Application Server are most efficient using the Windows NT pipe convention.

SQL Server

The SQL Server will be housed on a UNIX based machine. The processing role of the Oracle SQL Server is less than that of an Oracle application server. This server will only be used to process SQL 92 compliant statements and return the result table to the Application Server for processing.

Clients

All clients will require a World Wide Web browser that supports HTML 2.0 and cookies. The project will support Internet Explorer 2.0 and Netscape Communicator 4.0 or greater versions. The administration staff will be using a Windows application, named WinMill.

Additional Items

Support

All hardware, network and operating systems are the responsibility of the Client. Support for the HTTP Server, DLL, Application Server, and all other components developed by ASI are the responsibility of ASI. ASI provides support via the following vehicles:

ASI's approach to the support of its clients is very "hands-on". To insure the highest level of support possible, ASI prefers to be notified first in the event of a problem concerning the system. ASI’s support staff maintains a degree of training on the operating systems, network and hardware platforms supported by its products. This assists the client’s on-campus personnel in diagnosing any problems with the system. Further, notification of any modifications made to network, hardware, operating system, or any other components of the system is requested prior to the change.

Interfaces to Other Systems

Utilities will be developed to import information from other on-campus systems from an agreed upon format. As an alternative, table structures and other necessary information will be made available to on-campus personnel to facilitate the development of applications to add or append data directly to the system tables.

Some of the data under consideration for importation include marks, personal contact information, major, classification and other academic information, and citizenship. Since this information remains relatively static during the course of a term, there is no need to consider real-time interfaces to other systems, merely batch processes as described above.

Reporting

Reporting (as opposed to the interactive reporting available via the HTML interface, described elsewhere in this document) is to be handled by utilizing COGNOS products that are the standard UW reporting tool.

Oracle

As Oracle is the database standard at UW, the application will be developed against an Oracle database on a UNIX platform to insure compatibility. When deployed, the systems applications will be installed on a Pentium based Windows NT platform which will serve as the HTTP Server and Application Server.

 

Security

A Certificate will be provided to enable SSL and SHTTP encryption for all data transferred to and from the Web Server. Security for non-HTML components is provided via operating system, network, or application conventions. In addition, identification names/numbers and passwords will be defined for each user of the system.

Testing and Implementation

Overview

There are eight phases involved in the design, development, testing and implementation of the proposed system. These phases are defined in the attached document "Project Phases Summary" and are referred to below. Each phase outlines the estimated time to completion of the phase as well as the estimated resources involved.

Phase I: Requirements Planning

This phase was completed with the delivery of the original flowcharts and general specifications for the proposed system.

Phase II: Preliminary Design

This phase was completed with the development and review of the World Wide Web based interface.

Phase III: Detailed Design

This phase is complete for all units expect those related to the management of interview schedules. It is estimated that many components of this phase will be modified as testing of the developed system commences.

Phase IV: Programming and Unit Testing

This phase will begin on approval by Client of resources required at Client site. As Units of the system are developed, testing goals will be developed for each Unit to be performed first by ASI staff and then Client staff. If test results are successful, the Unit will be incorporated into the rest of the system for Integration Testing.

Phase V: Integration Testing

This phase will begin on completion of the testing of each Unit. Each Unit will be added to system and it's relation to other components of the system will be tested first by ASI and then Client staff. Many components may only be tested based on their relation to other aspects of the system, in which case Unit Test and Integration Testing may be one and the same.

Phase VI: System Testing

This phase will begin once the entire system has been completed as specified. During this phase, the entire system will be run parallel to the existing system or with some subset of the entire system to reduce risk in the event of failure during testing. Benchmarks will be developed prior to this phase to evaluate performance. Testing goals will be developed to determine when system installation can occur. This will be a labor intensive process for the Client as two systems must be maintained. This phase should span at least one full term. Training will be developed for key personnel responsible for testing jointly by ASI and Client.

Phase VII: Installation

The beginning of this phase will mark use of the system as the production environment. During an initial period of this phase, performance of the system will be monitored closely and any problems will be immediately investigated and resolved. Training will be developed for all personnel to use the system jointly by ASI and Client.

Phase VIII: Operations and Maintenance

This is a continuos phase that represents the use of the system on a regular basis.