Return to the Integrated Systems Project Home Page

 

University of Virginia

Integrated Systems Task Force

Study Group #2

Integrated Systems Task Force Study Group #2 was charged with the following mission:

To develop a list of critical features that a purchased product must have before it can be considered a viable candidate for replacement of the following core applications: Financial, Student, Human Resources and Development.

The Study Group was comprised of individuals who hold primary responsibility for the major core systems at the University. Through this responsibility, these individuals are considered both the stewards and functional experts of these systems. The study group members are as follows:

Jay Scott (leader) - Budget Office

Shelley Payne (facilitator) - Organizational Development and Training

Nancy Rogers (scribe) - ITC

Ann Antrobus - Registrar's Office

Julian Bivins - Development

Jack Blackburn - Admissions

Glenn Fielding - Medical Center Computing

Tom Gausvik - Human Resources

Larry Groves - Admissions

Dolores Hildebrand - Purchasing and Materials Services

Bernie Hill - ITC

Yvonne Hubbard - Financial Aid

Jeanne Inge - Purchasing and Materials Services

Steve Kimata - Bursar's Office

Jim Paul (until his departure) - Medical Center Computing

Shirley Payne - ITC

Larry Simpson - Office of Career Planning and Placement

Ken Sinarski - Financial Administration

George Stovall - Institutional Assessment and Studies

Matt Waldron - Medical Center Computing

The Study Group undertook a multiphased approach to the development of this list of requirements. The first phase involved the collection of a list of "must haves" from the perspective of the stewards of the systems. Each member of the group consulted with their respective areas and compiled a list of 25 high level requirements that they felt any replacement system would need to have in order for the implementation to be successful.

The second phase involved participating in focus groups that were held with the end users or customers of the various systems. In order to minimize the time burden on the participants, these were held in conjunction with Study Group #1. Study Group #2 members who participated in the focus groups were able to obtain additional critical requirements as defined by the end users/customers of the systems and incorporate these requirements into this document.

The third and final phase of the data collection took place through the review of data submitted by members of Study Group #1 regarding their thoughts on critical features required of any replacement system. Upon completion of all three phases, the members of Study Group #2 consolidated all of the information that they had collected and present it below as a final report to the Integrated Systems Task Force.

Critical Features for the University and any Replacement System

 

Throughout the deliberations of Study Group #2, one overriding concern continually surfaced - that the University of Virginia not lose sight of the reputation it has earned over the past many years of being the number one public institution in the country. It was strongly voiced by all present that this ranking was not an accidental one, but one that had been preserved by those stewards of the institution, both academic and administrative, who have placed the interests of the University in the highest regard. These stewards include, but are not limited to, the members of the Board of Visitors, our learned faculty, our academic deans, the Senior Cabinet, and the administrators of systems.

 

It has long been evident that the University is driven by the needs of our faculty and students, and that administrative tools (generally described as our systems) are implemented to satisfy those needs. We ask the decision-makers to continue to give credence to this philosophy as they wrestle with the issues inherent with a purchased, integrated system. For if we subjugate the unique and diverse needs of our faculty and students to the pursuit of technology, do we risk losing that which has made the University great?

The paramount concept that must be preserved throughout the evaluation, decision and selection processes is that any system(s) which the University acquires and implements should support the mission and values of the University. Although changes in business processes may be precipitated by this initiative, the acquisition of new administrative systems should not be the driving force behind major shifts in the University's management philosophy. Preserving the University's decentralized management structure can be accomplished through the proper identification and replacement of the core administrative systems with systems that are designed to provide integration while supporting the varied shadow systems in the field. Once properly defining the scope of what is truly a core system has been accomplished, then the selection and implementation process can begin.

In order to select an appropriate administrative system for the University, certain requirements will have to be met. Not only is it important to generate a set of critical requirements that are necessary of an integrated system and its vendor in order for it to be acceptable to the University, but it is also vital that the members of the University community develop and support a set of requirements placed on the community itself. Without this second set of requirements, any integrated system is likely to fail.

  1. The entire University community, as well as systems caretakers (ITC and stewards) and users/customers, must adopt a spirit of cooperation and compromise if an integrated system is to have any hope of succeeding.
  2. Stakeholders must be willing to accept some system features which may not be ideal, or in some cases might even be less desirable than features of the current system, in order to reap the overall benefits which an integrated system can provide. The overall project benefits to the institution must be defined in order that the units can see what benefit is derived from the sacrifices they may need to make on a local level.
  3. In some cases, administrators (both central and unit) must be willing to change the way they do business to accommodate the integrated system. Can we have an integrated system if a large unit says that they won't participate?
  4. In order to insure an efficient, effective, and compact set of integrated data elements, system caretakers must compromise with each other when developing data definitions across systems. It may be necessary to appoint a "steward" for each data element.
  5. A formal procedure should be developed for resolving conflicts between users and caretakers of different systems, particularly in cases where the conflict crosses vice presidential lines. All system caretakers, as well as the vice presidents, must support the procedure and abide by the results.
  6. The process of implementing new systems and reengineering business practices could result in the elimination of positions and/or the redefinition of job duties. A formal plan of dealing with these types of changes will need to be an integral part of any implementation.
  7. Once the scope of the project has been defined, it is essential that as many of the stakeholders as possible are included in the final decision. This will minimize resistance to conversion at a point in the process that is beyond the point of no return.
  8. This project should be marketed as a University wide project and not just an administrative systems project. It will impact all areas of the University and communication with, as well as input from, the University at large needs to be an integral part of the selection and implementation.


GLOBAL REQUIREMENTS

  1. The new system must meet all existing mandatory, regulatory, and cost beneficial system requirements unless changed by the appropriate level of management.
  2. It must be flexible and provide simple methods for modifying functionality to quickly meet the requirements of both administrative and academic units.
  3. It must provide a link to third party desktop software for calculations, decision support, graphics, and report presentation or allow for simple download of raw data in standard format for use in shadow systems.
  4. It must have an acceptable interface with ITC's security system (currently Top Secret), integrate with ITC's security strategy (file security and application security) and have an end product that allows for a single login ID and password for all applications.
  5. It must provide on-line, real-time windows based data entry and system update for all functions of the system across all subsystems. It must selectively allow view-only access in addition to view and update access as well as concurrent batch updating.
  6. It must interface with existing systems (e.g. FAS, Accounts Payable, OSP, Property Accounting, Facilities Management, GL for account validation, HR, Payroll and ISIS, Materials Management and Stores, and required State systems) until the integrated modules replace them. This interface must allow for cross referencing that will identify potential conflicts of interest.
  7. It must have pull down screens for data validation and help, error messages, various search features and ability to attach notes to transactions.
  8. It must allow for data entry via the World Wide Web and must support future web applications, such as UVA's electronic forms.
  9. It must provide for batch submission of data, such as user-generated data from SAS programs (datapools).
  10. It must allow authorization routing with multiple approval levels within and outside the requesting department.
  11. It must allow inquiries on transactions which are in progress and on-line notification of completed transactions with the ability to see comments of persons involved in the process.
  12. It must interface with the University's electronic mail and telephone communications systems.
  13. Security must be on a data element basis, controlling view and update capabilities. This security should provide protection against unauthorized access while giving users the ability to easily access the data (for view and download) to which they have a legitimate need for access.
  14. It must interface with the University's Information Warehouse, currently on a SYBASE platform, or provide an information warehouse module that allows for migration of our current data to the new system.
  15. It must provide simple methods for modifying screens, data tables and standard reports.
  16. It must have security which is easy to maintain but protects the integrity of the system - using security access by level as assigned to a user ID vs. security codes.
  17. It must require minimal hardware requirements -- accessible by all platforms (UNIX, PC and MACS).
  18. It must have an infrastructure which will accommodate massive usage of the system without affecting response time.
  19. It must provide general access to general routines and abilities that facilitate added custom development by the University e.g. the adding of new data and new screens and the ability to change existing screens without substantial impact to ongoing support.
  20. It must provide for edit and reasonability checks for online and batch transactions.
  21. It must accommodate future dated transactions in an online user accessible file that is easy to maintain and update.
  22. It must accommodate existing processes and management reporting requirements as defined by DPT, DOA, DPB as well as those of the federal government.
  23. It must integrate A/P, Payroll and Student systems with our Non-resident Alien Tracking System (ALIEN) in order to provide tracking of payments, tax withholding, treaty benefits, and other information necessary for reporting purposes or provide such a system.
  24. It must accommodate non-12 pay schedule and escrow of benefits (e.g., faculty who work and are paid over 9 or 10 months but whose benefits are paid over 12 months) and employees who are on variable length work schedules (flexible staffing model).
  25. It must provide adequate audit trails or audit reports for all transactions.
  26. Selected firm must provide ongoing maintenance and support for the system software. The support may be by telephone, electronic mail, or on-line problem resolution with the ability to download program updates and other system information.
  27. It must allow data access from multiple workstations simultaneously. Number to be predetermined prior to purchase of new system.
  28. Any new implementation must include easy access to training from people who know the system and the University processes well.
  29. The implementation of a new system may reduce accessibility for the end users as the core system technology outpaces the departmental technology. The implementation may require significant upgrades of local equipment in the units. This represents a significant cost and these financial concerns must be addressed as part of the implementation process.
  30. It must be user friendly, e.g., pull down menus, point and click fields, ability to produce a hard copy of any given screen; allow for general ease of navigation; clarity of use; ability to logically group screens by function to minimize menu levels; easily move among modules; ability to leave screen and return to it without losing data partly keyed; provide user defined on-line help at the field level; provide values of fields, customize screen sequence.
  31. It must be table driven.
  32. It must allow for authorization routing of transactions with multiple levels (from departments to central offices) i.e., user-defined and/or predefined routing for individual transaction types, notification of routing to an alternate person, if approval is not complete by a specified time; support electronic signatures.
  33. It must be easy to maintain, modify and enhance.
  34. It must reduce paper processes and improve document management via document image processing and optical character recognition.


Integrated Student Information System

A new student information system must integrate the functions of the billing and receivables process (which includes student tuition, fees, dining, housing and other expenses) with student admissions (graduate, professional, and undergraduate), financial aid (federal, state, and institutional), and student registration data (including biographical data, course data, grades, degrees, and other academic achievements).

Regulatory Requirements

  1. It must interface with all financial aid packages such as PARS and INAS. A vendor must be able to react quickly to changing federal requirements, such as project EASI.
  2. It must allow for data input from outside agencies and for data transfer to external agencies. Particular examples are receiving data from the Educational Testing Services for standardized test score results, reporting data to the National Student Loan Clearing House, transferring transcripts to other institutions and agencies electronically via SPEEDE, as well as communication with EduServ and third party collection agencies.
  3. It must interface with the human resources system to verify faculty and student data and to monitor College Work Study programs.

 

Policy Requirements

1. It must interface with or provide comparable replacements for the Schedule25 classroom scheduling system (Facilities Management and Provost space management system), the PACE computer-assisted advising system (or provide another such system acceptable to academic units), the Griffin System for monitoring the photo identification card system and door access, and the EPOS telephone system. The data stewards of student systems are aware that other system replacements for these major components may be available. Nevertheless, in the decision-making process, the cost of replacing these components should be given high consideration.

  1. The grading schemes of each resident school must be maintained unless current policy changes are forthcoming.
  2. It must allow for applicants wishing to submit application to more than one school for any particular academic term and must accommodate the University's Early Decision admissions process.
  3. It must accommodate the University's variable and fixed tuition rate structures, including special areas such as non-topical research, class specific surcharges and the tuition waiver program for University employees. It must handle various school generated awards, such as tuition remission, tuition differential, and stipends.
  4. It must interface with the University's Division of Continuing Education and provide for its unique functionality.

 

Service to Customers/Students/Faculty

  1. It must work with or replace the master locator function. This function maintains and finds transcript data for students who attended the University from 1960 to 1975.
  2. It must provide for timely production, and security of academic transcripts for all current students and alumni.
  3. It must provide up-to-date information to all students, parents, and alumni about the status of admissions, bursar, financial aid and registrar data.
  4. It must be able to handle multiple terms of financial data, provide a third party billing module, and use estimated financial aid credits.
  5. It must interface with or replace the current on-line cash registers.
  6. It must provide "one-stop" access for students rather than force them to go to several locations for different services.
  7. It must provide the ability to automatically respond to e-mail inquiries from applicants.
  8. It must automatically load all e-mail inquiries into the database.
  9. It must provide a link between the prospective student database and the applicant database.
  10. It must provide a voice response system for admissions that interfaces with ISIS or its replacement.


Financial Systems

A new financial system should not only include features necessary to maintain the current level of service which we provide to our customers, but it should offer enhancements which will allow the University to take advantage of emerging technology and decentralization. The new system, while maintaining necessary controls, would allow for greater use of EDI, enhance reporting capabilities and data management, and allow for electronic interchange of information among internal and external customers.

Integrated Accounting System

Regulatory Requirements

  1. It must capture 1099, 1042s, and other tax-reportable activity based on transaction activity, not vendor. It must be able to withhold taxes for NRAs or backup withholding for vendors. It must provide full reporting capabilities, including printing laser documents, magnetic IRS files, and user mailings to individuals and/or departments.

 

Policy Requirements

  1. It must maintain transactional and account balances to continue to meet all state requirements for decentralization and cash management. It must allow for Electronic Data Interchange (EDI)/Comptroller Debt Setoff (CDS) processing, daily and monthly settlements, reconciliations, daily appropriation/allotment/cash monitoring, and fiscal year end closing. It must interface with state budget system (Probud).
  2. A/P system must be able to issue payments by check or electronically (Automated Clearing House). All payments must be issued by due date and consolidated into one payment per day per vendor.
  3. For bank reconciliation purposes, it must provide a mechanism to allow cash balances and transaction detail maintained at the individual account level to be aggregated according to the University's existing bank account structure.

 

Service to Customers/Students/Faculty

  1. It must generate transaction history files that contain all the direct records input/accepted by the accounting system. It must generate records in the transaction file for the indirect updates to cash, fund balance, and revenue, expenditure and budget controls.
  2. It must use self-balancing accounts that follow NACUBO fund accounting, user updateable attributes that facilitate the preparation of GASB financial statements and other national and state reports, and provide edit controls based on flexible user controlled parameters.
  3. It must allow for compound journal entries (IDT), create tables and transactions for computer generated transactions (mechanical entry).
  4. It must provide integrated two way interfacing with existing major systems (HR, ISIS, Accounts Payable (AP)/Purchase Order (PO) Inventory Management System (IMS), Budget) and subsystems (i.e., Physical Plant). An integrated system-wide vendor file that restricts the capability of creating duplicate vendors and allows the flexibility of keying variable data to be passed or updated on a transaction type basis (i.e., travel, foreign nationals).
  5. It must have enough flexibility to provide a base account and object code structure to meet the University's central budgeting, reporting and accounting needs which can then be adapted on a departmental or cost center basis to meet individual department's needs managing financial information.

 

Purchasing and Stores

Service to Customers/Students/Faculty

  1. It must provide Electronic Data Interchange (EDI) which offers digital interchange of IFBs, purchase orders, acknowledgments, invoices and electronic fund transfers.
  2. It must provide a means to electronically link RFPs, bid specifications and other correspondence to POs with the use of imaging and mapping to Microsoft Office documents.
  3. It must provide a means for users to order from on-line contracts and catalogs.
  4. It must allow payment tolerances to be set by purchase order type.
  5. It must provide a commodity based vendor file and processes to solicit IFBs, evaluate responses, transmit and award.
  6. It must be flexible in changing orders, choosing where, how and when to print an order.
  7. It must allow the use of multiple accounts and object codes on a single PO or line item.
  8. It must provide on-line means for manager to distribute incoming requests to buyers and monitor their performance.
  9. It must allow Stores to sell to other agencies such as the Medical Center.
  10. It must allow receipt of stock into inventory without a PO.
  11. It must be able to calculate Stores inventory levels, reorder points and order quantities automatically with manual override capabilities and monitor expiration dates of goods.
  12. It must be able to add and delete items from inventory easily.
  13. It must provide an on-line catalog of stock items and the ability to order from the catalog directly.
  14. It must be able to generate and read barcodes for receiving, delivery, inventory and tracking purposes in Stores.

 

Sponsored Programs

The proposed financial management system would need to accommodate the approved future enhancements for the processing of grants and contracts. This will probably mean allowing for electronic transmission of information at all process steps from P.I. submitting proposal to final billing and close-out of project. This could mean an entirely new system for OSP. Any new system must include the following:

Regulatory Requirements

  1. It must collect data for quarterly reports to agencies.
  2. It must have an effort reporting system.

 

Service to Customers/Students/Faculty

  1. It must have the ability to compute, charge and return overhead.
  2. It must be able to access to cash position for proper draw down & deposit.
  3. It must have the ability to freeze an account when project end date is reached.
  4. It must have deficit controls/edits.
  5. It must allow for project specific cost-sharing commitment identification.
  6. It must provide quarterly receivables reporting.

 

Budget

None of the required features listed below are required as the result of policy or government mandate. However, in the process of conducting an extensive survey (over two years ago) while developing an RFP for the purchase of a new budget and financial management system, it was determined that the below requirements would be necessary if we were to deliver a user friendly time efficient system.

Service to Customers/Students/Faculty

Budget and Financial Management

  1. It must support the preparation of budgets at department, school and University levels by providing a facility to build budgets from the lowest appropriate organizational levels. The system must support summarization of budgets at higher levels, based on user-defined criteria.
  2. It must support multiple versions of budgets (e.g., original, revised, prior year original and revised, next year, and future years).
  3. Data must be integrated throughout the processes of long-range planning, budget development, position management and financial analysis.
  4. It must provide the departments and schools with the capability to submit budgets, plans, and amendments from the workstation for review and approvals.
  5. It must provide the University's Budget Office with the means to monitor the completion of the budgets by departments and schools.
  6. It must support the ability to budget multiple fund types (e.g., unrestricted and restricted; grants, gifts and endowments).
  7. It must support the budgeting of all revenues, transfers, encumbrances, and expenditures.
  8. It must be able to access human resources information (e.g., position status, history of position changes, and actual payroll history). This data will be used to support salary setting by capturing position information. It must allow for retroactive and future-dated payroll transactions to more accurately project and budget actual salary costs.
  9. It must support the funding of a single position from multiple sources such as state funds, local funds, and grants. The fund split could be based on percentage of effort or on specific dollar amounts.
  10. It must support concurrent multi-year budgeting.
  11. It must allow for multiple approvals of a single transaction (e.g., budget amendment, interdepartmental transfer, purchase order) across school and department lines.
  12. It must provide the ability to record and monitor transactions, such as purchase orders, interdepartmental transfers, etc., as encumbrances and accordingly reduce available budget balances.

 

Decision Support

  1. It must support budget variance analysis.
  2. It must enable a user to analyze information at successive levels of detail.
  3. It must support a variety of planning and forecasting methods using multiple bases and projection parameters.

 

Technical

  1. It must provide tag accounts so that department finance managers can perform detail level reporting.

 

HUMAN RESOURCES

It must have the following subsystems:

Benefits Administration

  1. It must support Section 125 Plans.
  2. It must support defined contribution plans and support defined benefit plans.
  3. It must provide automated Maximum Exclusion Allowance computations for 403(b) plans.
  4. It must support unlimited deductions.
  5. It must use tables to determine eligibility rules and calculation methods for both coverage and contributions to the plans. Tables will be constructed to simplify plan set up and future maintenance when a plan's rules change.
  6. It must support multiple health insurance plans.
  7. It must support life insurance, short term/long term disability insurance plans, etc.
  8. It must support online benefit deduction setting.
  9. It must support COBRA processing.

 

Compensation

  1. It must support multiple pay plans and premiums pay e.g. overtime, shift differential, on call, call back, unit pays, lump sum payments, piece rate, salaried, and hourly employees
  2. It must ensure compliance with Federal Fair Labor Standards Act

 

Employee Master File

  1. It must allow for dual employment e.g. multiple jobs at different rates of pay.
  2. It must accommodate faculty appointments e.g. tenure dates, up to five titles, educational credentials etc.
  3. It must accommodate classified staff processing as defined by the State (VA Personnel Act).
  4. It must provide online work history and training records of employees for a specific period of time.
  5. It must provide online update.
  6. It must deal with multiple date fields i.e. hire date, service date, benefits date, performance review date, etc.
  7. It must allow for at least 25 funding sources for a position/person.
  8. It must accommodate tracking of non-pay individuals i.e. retirees, visiting faculty.

 

Position Control

  1. It must accommodate existing state constructs and support position coding for ODT, orientation and other central administrative training purposes.
  2. It must accommodate multiple employees in a single position.
  3. It must integrate with the University Budget System.
  4. It must relate position to employee and vice versa.

 

Payroll

  1. It must support standard payroll processing including multiple pay cycles, delayed and prospective pay, support retroactive pay adjustments, automated special check processing.
  2. Summary payroll and fringe benefit transactions must update the Financial Information System on a pay period basis and must be distributed by account number and object code.
  3. It must support on-line payroll history for at least one year.
  4. It must capture both fiscal year and calendar year to date information for pay, employer paid deductions, and other relevant data.
  5. It must provide for proper taxation (students, foreign nationals, etc.) and deduction for all pay, including supplemental pay. Special needs include "departmental paid" employee deductions and the ability to "turn off" FICA tax prior to reaching minimum earnings.
  6. It must support W2 preparation including the ability to make additions to gross income for non-payroll reimbursements (i.e. moving and relocation reimbursements and meals) and non cash fringe benefits.
  7. Payroll information must be available to complete the federal requirements for effort reporting on a periodic basis (i.e. bi-monthly, semi-monthly, etc.)
  8. It must support a fully integrated time and attendance system including leave processing of up to 40 different leave types (unless the University is successful in reducing this number). The system must provide leave processing with tracking of accrual and use, on-line update and query access, stored leave history for a predetermined number of years, leave liability reporting, periodic warning reports, and retroactive processing capability.
  9. It must incorporate a mechanism for automatic accrual of multiple leave types (vacation, sick, paid time off) with calculation of accruals based on pay cycle, employee type, years of service, and maximum accrual tables, as well as mechanism for automated reporting, accumulation, and automatic reduction of compensatory time earned.
  10. It must allow for the creation of new and innovative human resource services and programs, and facilitate the reengineering and process simplification of existing workflow processes
  11. It must reduce manual systems
  12. It must improve control mechanisms and audit trails
  13. It must provide for simplified management reporting; e.g., provide on-line inquiry (queries) facilities for Human Resources and University (user) departments and interface with the Information Warehouse
  14. It must have a high level of system integrity and security; e.g., at data element level for human resource and payroll data
  15. It must either replace or interface with the University's On-Line Employment & Personnel Action System

 

Development

Even though the ISTF decided that Development would not be part of the total overall analysis, as Study Group #2 had already collected development data, we offer it here as a supplement to our final report. Should the purchase decision come down to two comparable vendors, this may provide some additional selection support.

 

Regulatory Requirements - None

Policy Requirements

  1. It must interface with FAS and other financial systems and have appropriate audit
  2. It must be able to provide financial reporting for the University and the Foundations in accordance with necessary internal and external requirements (e.g. GASB, FASB).
  3. It must be able to support flexible and sophisticated campaign planning and reporting.
  4. It must support distribution across multiple business locations.
  5. It must be flexible and robust enough to reflect the University's business procedures without major customization.
  6. It must allow the tailoring of user access to various components of the application according to business functions.
  7. It must allow the monitoring of campaign progress from many different aspects: by school, by Foundation, with the ability to roll up into broad categories, as needed;
  8. It must allow for the management and tracking of major University donors, and provide reports of these activities for subsequent review by management;

 

Service to Customers/Students/Faculty

  1. It must facilitate the data entry process of both gift and biographical information.
  2. It must have robust gift entry, suitable for heads-down data gift processing.
  3. It must have capability of interfacing with other University systems: Admissions, OSP, Scholarships, Endowments, Purchasing - for vendor information, VSAF's point system, etc.
  4. It must provide flexible ad hoc reporting by the user community.
  5. It must have sophisticated Annual Giving modules, which provide flexibility for our various schools and divisions to tailor their individual programs.
  6. It must have a Special Events module which allows for the tracking of invitations and attendees at the various sponsored University events.
  7. It must have a Planned Giving module that reflects the various instruments and methods used by the University.
  8. It must have the ability to distribute information easily to users in the University community.
  9. It must have an integrated messaging capability, to let development officers know that activity has taken place with a particular prospect.


This list of requirements is by no means an all inclusive list as there are many more features that would be "nice" to have. The above information is simply those items that if unavailable in a new system, would create significant hardship on the stewards and users of the system(s). It is however, designed to be a guide for use while evaluating potential integrated systems or best of breed selections. Study Group #2 is extremely grateful to have been given this opportunity to contribute towards such a significant project at the University and would be more than happy to provide additional information if the task force would find it helpful in making this important decision.

 


Return to the Integrated Systems Project Home Page

Site maintained by kat4w@virginia.edu
Updated January 12, 1999