UNIVERSITY OF CALIFORNIA, SAN DIEGOREQUEST FOR PROPOSALS (“RFP”)

UCSD RFP #0803 RMNNOTICE OF ISSUANCE OF RFP

UCSD Extension English Language Institute Information Management System (ELI IMS)

RFP Objective: The University of California, San Diego is seeking to establish a preferred Bidder for updating the English Language Institute’s information management system.

RFP Release Date: February 15th , 2008

RFP Due Date: Proposals must be received no later than:4:00 p.m. on Tuesday, March 11th, PDT.

Deadline for Submission of Bidder Questions:

February 29th th, 2008 – Bidder’s conference March 5th, 2008 – Final questions

UCSD Contact: Bryan HurleyUCSD Purchasing 9500 Gilman Drive-Mail Code 0914La Jolla, CA. 92093-0914 Telephone: Fax: (858) 534 1940Email: bhurley@ucsd.edu

Street Address for Hand Delivery or Private Carrier:Bryan HurleyUCSD PurchasingUniversity of California, San Diego10280 N. Torrey Pines RdSuite 350La Jolla, CA 92037

***IMPORTANT INFORMATION FOR ALL PROSPECTIVE BIDDERS***

Any addenda to this RFP will be distributed to those who request this RFP. Notification of the issuance of an addendum will be posted on-line at the University of California, San Diego, Purchasing Department web site: http://www-bfs.ucsd.edu/pur/services/rfirfq/rfirfqpg.htm. It is solely the responsibility of the prospective BIDDERS, not UCSD, to ensure they have all the addenda prior to submitting a proposal. If, for any reason, you are unable to access the site or wish to receive a paper copy of the RFP, or any part of the RFP, please request a copy from the UCSD Contact.

I. PRE-PROPOSAL INQUIRIES

If there are any discrepancies in, or omissions to, the RFP, or if there are any questions as to any information provided in the RFP or by any other source, a request must be submitted in writing (fax or email is acceptable) for clarification, interpretation, or correction. Such inquires must be directed to the UCSD Contact only. In the event that it becomes necessary to clarify, interpret, or correct any part of this RFP, the information will be provided in writing to all who have registered pursuant to the instructions above. UCSD may be unable to respond to inquiries received too close to the proposal submission deadline to permit a timely and comprehensive reply to all registrants. Prospective Bidders who contact other UCSD staff or consultants with inquiries may be disqualified.

INDEX

I. PRE-PROPOSAL INQUIRIES.................................................................................................................................................. 1A. INTRODUCTION............................................................................................................................................. 6A.1 PURPOSE OF RFP.......................................................................................................................................... 6

A. PREFERRED BIDDER:............................................................................................................................................................. 6A.2 RFP SCHEDULE AND DEADLINES.................................................................................................................................... 6A.3 DEFINITION OF TERMS...................................................................................................................................................... 6

1

B. PROPOSAL FORMAT AND GUIDELINES.................................................................................................... 7B.1 GENERAL FORMAT REQUIREMENTS.......................................................................................................... 7

PROPOSAL STYLE AND FORMAT............................................................................................................................................ 7SUBMITTAL COPIES.................................................................................................................................................................. 7

PRICE PROPOSAL:................................................................................................................................................................ 7TECHNICAL PROPOSAL........................................................................................................................................................ 7

PROPOSED SOLUTION.............................................................................................................................................................. 7OVERVIEW.................................................................................................................................................................................. 8DETAILED RESPONSE............................................................................................................................................................... 8RFP EXCEPTIONS...................................................................................................................................................................... 8GENERAL EXCEPTIONS............................................................................................................................................................ 8FUNCTIONAL AND TECHNICAL EXCEPTIONS........................................................................................................................ 8UNIVERSITY RESOURCES REQUIRED FOR IMPLEMENTATION...........................................................................................8COST WORKSHEETS................................................................................................................................................................. 8A. EXPERIENCE...................................................................................................................................................................... 8B. HARDWARE........................................................................................................................................................................ 8C. DOCUMENTATION REQUIREMENTS............................................................................................................................... 9G. ATTACHMENTS....................................................................................................................................................................... 9

B.2 PROPOSAL REQUIREMENTS........................................................................................................................ 9B.2.1 PROPOSAL CONTENTS, PAGE LIMITS, AND FORMATTING RECOMMENDATIONS..........................................................................9

a. Company background................................................................................................................................................. 10b. Organizational and Project Team Experience/Qualifications..................................................................................10The Bidder must provide references for all work performed for the University of California at any facility during the past ten years. The University may solicit and consider references from any Bidder’s customer...............................10c. Example of previous projects........................................................................................................................................ 10a. Overall Technical approach........................................................................................................................................ 101. Detailed approach........................................................................................................................................................ 11

A. PROJECT PLAN.................................................................................................................................................................... 11i. Project Management Approach.................................................................................................................................. 11ii. Project schedule.......................................................................................................................................................... 11

III. POST-RELEASE PRODUCTION SUPPORT AND FUTURE DEVELOPMENT......................................................................................11C. CURRENT SYSTEM, FUNCTIONAL REQUIREMENTS/SOW AND PRICING............................................11C.1 CURRENT SYSTEM DESCRIPTION............................................................................................................ 11

C.1.1 USERS AND TRANSACTIONS............................................................................................................................................... 12C.1.2 DATABASE ORGANIZATION.................................................................................................................................................. 13

C.1.2.1 User Interface.......................................................................................................................................................... 13C.1.2.2 Tables...................................................................................................................................................................... 13C.1.2.3 Forms and Reports................................................................................................................................................. 14C.1.2.4 Code......................................................................................................................................................................... 14C.1.2.5 Security.................................................................................................................................................................... 14

C.2 REQUIREMENTS FOR NEW SYSTEM........................................................................................................ 14C.2.1 FUNCTIONAL REQUIREMENTS.............................................................................................................................................. 14C.2.2 DATABASE TECHNOLOGY.................................................................................................................................................... 14C.2.3 CLIENT INTERFACE............................................................................................................................................................. 15C.2.4 END USER CHARACTERISTICS............................................................................................................................................. 15C.2.5 HARDWARE ENVIRONMENT.................................................................................................................................................. 15C.2.6 NETWORK COMMUNICATIONS.............................................................................................................................................. 15C.2.7 PERFORMANCE AND QUALITY REQUIREMENTS..................................................................................................................... 15C.2.8 TRANSITION REQUIREMENT AND TIMEFRAME........................................................................................................................16

C.3 SCOPE OF WORK AND DELIVERABLES.................................................................................................. 17C.3.1 SCOPE OF SERVICES AND EXPECTED DELIVERABLES...........................................................................................................17

C.3.1.1 Conduct technical pilot.......................................................................................................................................... 17C.3.1.2 Inventory functional modules................................................................................................................................ 17C.3.1.3 Port Access database to SQL Server database...................................................................................................17C.3.1.4 Port Access 1997 client to Access 2007...............................................................................................................17C.3.1.5 Migrate data from Access database to SQL Server database.............................................................................17

C.3.2 PROCESS RELATED REQUIREMENTS.................................................................................................................................... 17C.3.2.1 Extension development environment...................................................................................................................18C.3.2.2 Agile development process................................................................................................................................... 18C.3.2.3 Testing..................................................................................................................................................................... 18C.3.2.4 Data migration and production deployment.........................................................................................................18

2

C.3.2.5 Training and knowledge transfer........................................................................................................................... 19C.3.2.6 Other Deliverables................................................................................................................................................... 19C.3.2.7 Project management support................................................................................................................................ 19C.3.2.8 Extension-provided resources.............................................................................................................................. 19C.3.2.9 Extension project team.......................................................................................................................................... 19

C.4 PRICING REQUIREMENTS.......................................................................................................................... 20C.4.1. FIRM PRICES.................................................................................................................................................................. 20C.4.2. COMPLETE PRICES....................................................................................................................................................... 20C.4.3. PRICE LEVELS AND DISCOUNTS................................................................................................................................ 20C.4.4. PRICING FORMAT.......................................................................................................................................................... 20C.4.5. PRICING METHODOLOGY............................................................................................................................................. 20C.4.6. PAYMENT SCHEDULE................................................................................................................................................... 21PRICING/FEES.............................................................................................................................................................................. 21

SECTION D. TERMS AND CONDITIONS............................................................................................................ 21D.1. PERIOD OF CONTRACT................................................................................................................................................... 21D.2. COSTS................................................................................................................................................................................ 21D.3. PAYMENT........................................................................................................................................................................... 22D.4. SOFTWARE OWNERSHIP TERMS................................................................................................................................... 22D.5. ACCEPTANCE TERMS...................................................................................................................................................... 23D.6. NON-DISCLOSURE TERMS.............................................................................................................................................. 24D.7. MISCELLANEOUS TERMS................................................................................................................................................ 26D.8. UCSD TERMS AND CONDITIONS - APPENDIX A

SECTION E. INSTRUCTIONS TO BIDDERS....................................................................................................... 32E.1. NEGOTIATION OF CONTRACT........................................................................................................................................ 32E.2. CONTACTS WITH UNIVERSITY MANAGEMENT.............................................................................................................32E.3. SUBMITTAL DEADLINE.................................................................................................................................................... 32E.4. RESPONSIVE PROPOSALS.............................................................................................................................................. 32E.5. AUTHORIZED PROPOSAL................................................................................................................................................ 32E.6. OWNERSHIP AND COPYING OF PROPOSAL.................................................................................................................32E.7. PROPOSAL ACCEPTANCE PERIOD................................................................................................................................ 32E.8. BIDDER'S WITHDRAWAL, MODIFICATION, AND RESUBMISSION OF PROPOSALS.................................................32E.9. UNIVERSITY’S AMENDMENTS TO RFP...........................................................................................................................33E.10. REJECTION OF PROPOSALS........................................................................................................................................ 33E.11. INTEGRITY OF RESPONSE............................................................................................................................................ 33E.12. COSTS OF RESPONSE TO RFP..................................................................................................................................... 33E.13. LOW BALL SUBMITTALS............................................................................................................................................... 33E.14. BID PROTEST.................................................................................................................................................................. 33E.15. PENALTY FOR COLLUSION........................................................................................................................................... 34E.16. MULTIPLE AWARDS....................................................................................................................................................... 34

SECTION F. REQUIRED SUBMITTALS – PROPOSAL FORMAT.....................................................................34F.1. NOTICE OF INTENT TO RESPOND TO RFP AND RESPONSE COVER PAGE (EXHIBITS A & B)............................................34F.2. INSURANCE CERTIFICATION FORM (EXHIBIT C)..................................................................................................................... 34F.3. BUSINESS INFORMATION FORM (EXHIBIT D).........................................................................................................................34F.4. CONFLICT OF INTEREST FORM (EXHIBIT E)..........................................................................................................................34F.5 BIDDER’S REFERENCE FORM (EXHIBIT F)......................................................................................................................... 34F.6. BIDDER’S TECHNICAL PROPOSAL, INCLUDING FUNCTIONAL AND TECHNICAL SPECIFICATIONS (EXHIBIT G)....34F.7. BIDDER’S PRICE PROPOSAL INCLUDING MANDATORY PRICING FORM (EXHIBIT H).................................................34F.8. HARDWARE RECOMMENDATION SHEET (EXHIBIT I) – NOT APPLICABLE................................................................34F.9. STANDARD BIDDER AGREEMENTS............................................................................................................................... 34F.10. PRODUCT DOCUMENTATION........................................................................................................................................ 34F.11. PRODUCT DEMONSTRATION........................................................................................................................................ 35F.12. PILOT TESTING............................................................................................................................................................... 35

SECTION G. BASIS OF AWARD G.1. COST PER QUALITY POINT SCORE:............................................................................................................................ 36

G.2. REJECTION OF PROPOSALS.......................................................................................................................................... 36G.3. EVALUATION PROCESS.................................................................................................................................................. 36G.4. BIDDER DISQUALIFICATION........................................................................................................................................... 36G.5. CONTRACT NEGOTIATION.............................................................................................................................................. 36

SECTION H. LIST OF EXHIBITS.............................................................................................38 AND APPENDIX

3

SECTION K. DEFINITION OF TERMS.........................................................................................................................39

APPENDIX B- EXISTING SYSTEM DESCRIPTION............................................................................................501 ABSENCES........................................................................................................................................................................... 502 ACCOUNTING....................................................................................................................................................................... 52

2.1 Accounting Reports................................................................................................................................................ 532.2 Agency Fee Request Letter.................................................................................................................................... 542.3 Agency Fee Posting................................................................................................................................................ 542.4 Create Agency Invoices.......................................................................................................................................... 552.5 Agency Payments for Students.............................................................................................................................. 552.6 Accounts Receivable Transactions.......................................................................................................................55

3 CLASSES............................................................................................................................................................................. 563.1 Copy Class Schedules............................................................................................................................................ 573.2 Schedule Classes by Program Group................................................................................................................... 583.3 Rosters and Room Scheduling.............................................................................................................................. 603.4 Book Ordering......................................................................................................................................................... 69

4 CONVERSATION LEADERS.................................................................................................................................................... 704.1 Conversation Leader Attendance Entry................................................................................................................704.2 Conversation Leader Evaluation Entry.................................................................................................................. 724.3 Conversation Leaders Classes.............................................................................................................................. 734.4 CL Class Assignments By Class............................................................................................................................ 744.5 CL Class Assignments By Conv Leader...............................................................................................................754.6 CL Task Assignments By Conv Leader.................................................................................................................764.7 Conversation Leader Reports................................................................................................................................ 774.8 Evaluations.............................................................................................................................................................. 79

5. EVALUATIONS...................................................................................................................................................................... 805.1 Program Evaluations............................................................................................................................................... 805.2 Generate Evaluation Reports (Instructors)...........................................................................................................815.3 Process Instructor Evaluation Scranton File........................................................................................................815.4 Instructor Evaluation Reports................................................................................................................................ 82

6. GRADES AND CERTIFICATES................................................................................................................................................. 836.1. Detailed Grades by Class (Core)............................................................................................................................ 836.2. Enter Grades by Class (not Core)..........................................................................................................................846.3. Enter Grades By Student........................................................................................................................................ 846.4. Enter Faculty Advisor Comments.......................................................................................................................... 856.5. Grade Reports & Certificates (Office Use Only)....................................................................................................85

7. INSTRUCTORS...................................................................................................................................................................... 887.1. Instructor Reports................................................................................................................................................... 887.2. Instructor Attendance Entry................................................................................................................................... 907.3. Instructor Attendance Report................................................................................................................................. 90

8. MAINTENANCE..................................................................................................................................................................... 918.1. Restore the Cursor.................................................................................................................................................. 918.2. Add Users and Groups, Assign Permissions.......................................................................................................918.3. Utilities: Student numbers and deletions..............................................................................................................938.4. Master Maintenance................................................................................................................................................ 94

9. MARKETING......................................................................................................................................................................... 999.1. Marketing Reports................................................................................................................................................... 99

10. MEDIA FILE................................................................................................................................................................... 10110.1. File: For Instructors............................................................................................................................................... 10210.2. Media File Management: For Office Use Only.....................................................................................................105

11. REGISTRATION............................................................................................................................................................... 10911.1. Enter/Edit Inquiries................................................................................................................................................ 10911.2. Student Registration and Enrollment..................................................................................................................11011.3. Enrollment Reports (including Leads)................................................................................................................. 111

12. SINGLE STUDENT DATA................................................................................................................................................. 11412.1. Single Student Reports......................................................................................................................................... 11512.2. Student Academics............................................................................................................................................... 115

13. STUDENT SCHEDULING.................................................................................................................................................. 11813.1. Schedule Reports.................................................................................................................................................. 11813.2. Assign Core Levels............................................................................................................................................... 11913.3. Change Core Level to HOLD................................................................................................................................. 120

4

13.4. Assign Core / Required Courses..........................................................................................................................12013.5. Assign Class Sections.......................................................................................................................................... 12113.6. Process Continuing Students.............................................................................................................................. 12213.7. Single Student Scheduling (Non-graphical)........................................................................................................12313.8. Single Student Scheduling (Graphical) – PLACEMENT WK ONLY...................................................................12313.9. Elective Selection Reports.................................................................................................................................... 124

14. TESTING........................................................................................................................................................................ 12514.1. Enter Placement Test Scores............................................................................................................................... 12514.2. Post Test Authorization........................................................................................................................................ 12614.3. Enter Post Test Scores / Comments by Core Class...........................................................................................12714.4. Enter Post Test Scores by Alpha.........................................................................................................................12714.5. Administrative Test Reports (Office Only)..........................................................................................................12814.6. Late Test Scoring.................................................................................................................................................. 129

15. VENDORS...................................................................................................................................................................... 13015.1. Vendors.................................................................................................................................................................. 13015.2. Vendor Events....................................................................................................................................................... 13015.3. Vendor Sponsorship Entry................................................................................................................................... 13115.4. Vendor Reports...................................................................................................................................................... 131

16. STUDENT FOLDERS........................................................................................................................................................ 13216.1. Instructor Absences.............................................................................................................................................. 132

Appendix C: Glossary....................................................................................................................................... 133

5

A. INTRODUCTION

“Innovation is our tradition”

Nestled along the Pacific Ocean on 1,200 acres of coastal woodland, UCSD is a powerful magnet for those seeking a fresh, next-generation approach to education and research. Since its founding four decades ago, UCSD -- one of the ten campuses in the world-renowned University of California system -- has rapidly achieved the status as one of the top institutions in the nation for higher education and research. UCSD’s interdisciplinary ethos and tradition of innovation and risk-taking, underlie its research strength and ability to recruit top scholars and students.

Economic Impact:UCSD is an engine for regional economic growth. UCSD faculty and alums have spun-off close to 200 local companies, including over a third of the region’s biotech companies. In addition, UCSD is San Diego County’s largest single employer, with a monthly payroll in excess of $71 million, and over 24,000 employees.

A.1 PURPOSE OF RFP

a. Preferred Bidder:

i. The University of California, San Diego (“University”) is seeking to establish a preferred Bidder for updating the English Language Institute’s Information Management System (“ELI-IMS”). The intention is to establish through open competition a contractual agreement with a third party for updating of UCSD Extension’s ELI-IMS.

b. Immediate Requirements: i. UCSD Extension is seeking proposals from qualified firms to perform a technology update to the English

Language Institute’s (ELI) information management system (ELI-IMS). The amount of funding available for this project has not been established.

ii. ELI-IMS is a multi-user, custom-developed application that has been in service since 2001. The client-server application is based entirely on Access 97. The essential nature of this task is to port the database to SQL Server 2005 and the client application to Access 2007. From a user perspective, the underlying functionality and user experience should not significantly change.

A.2 RFP SCHEDULE AND DEADLINES.

Listed below are the important actions in the RFP process and the dates and time by which they are to be taken or completed. Action on any of these dates shall occur between 8 a.m. and 4:00 p.m. Pacific Time, unless otherwise noted. The University does not guarantee the schedule below and reserves the right to modify the schedule to meet the University’s needs.

University of California, San Diego Request for Proposal (RFP)

RFP Issued February 15th, 2008

Bidder’s Conference questions due

Optional Bidder’s Conference and submission deadline for Exhibit A.

February 27th, 2008

February 29th, 2008

Deadline for additional Questions

March 5th, 2008

6

Responses due from Bidders

March 11th, 2008, 4PM Pacific Time

Complete final review of Proposals and if necessary take Reference account visits

March, 2008

Notify Selected Bidder March, 2008

Negotiate Contract April 2008

Sign Contract and Issue Order

April 2008

A.3 DEFINITION OF TERMS.

This RFP uses a variety of terms in specially defined ways. This terminology includes business, technical, and project terms that are required to understand this RFP. The definitions are provided in SECTION K. Terms that are generally understood in the information technology industry are not included.

B. PROPOSAL FORMAT and GUIDELINES

B.1 General Format Requirements

In the Proposal, each Bidder must provide responses to all parts of Section B, in the order of Headings shown below. Each part of the response must be numbered corresponding to the part of each Section and Exhibit. Exhibit G, which is referenced below, must be filled out and submitted as part of the Technical Proposal packet. FAILURE TO DO SO WILL INVALIDATE YOUR BID.

PROPOSAL STYLE AND FORMAT.

The Proposal should be clearly and concisely written and well-organized. It should provide sufficient detail to permit comparative evaluation. The approach should be factual and reasoned, with marketing language kept to a minimum.

The Proposal must follow the format for responses described in this RFP. To the maximum extent possible, responses should follow the sequence of topics presented in the RFP.

PLEASE: USE THE SAME SECTION NUMBERS AND PARAGRAPH HEADINGS IN YOUR RESPONSE AS ARE USED IN THIS RFP. THIS WILL GREATLY ASSIST THE UNIVERSITY IN EVALUATING PROPOSALS.

The Proposal should include a table of contents with page numbers covering all parts including exhibits and addenda, to enable easy reference to all requested information.

The Proposal and other required submittals must be presented in English.

SUBMITTAL COPIES.

Bidders are required to submit their Proposal as follows:

PRICE PROPOSAL:

The Pricing Proposal must include all of the completed EXHIBIT H, MANDATORY PRICE SHEET. Submit one (1) electronic copy of the complete Price Proposal, and one (1) hard copy printed Price Proposal which must be marked “Original” and contain an original signature of an officer or employee of the firm authorized to bind the bidder to a contract of the type considered in this RFP.

The complete electronic copy must be submitted in the form of an Adobe Acrobat PDF file on a compact disk (CD) formatted to be readable by a personal computer running Microsoft Windows 2000 or

7

Windows XP. The Bidder is encouraged to send the final electronic copy to the buyer listed for distribution to the RFP evaluation committee.

TECHNICAL PROPOSAL

One (1) complete printed Technical Proposal, which must be stamped “Original” and contain an original signature; and four (4) complete printed copies; and four (4) complete electronic copies in the form of an Adobe Acrobat PDF file on a compact disk (CD) formatted to be readable by a personal computer running Microsoft Windows 2000 or Windows XP. The Bidder is encouraged to send the final electronic copy to the buyer listed for distribution to the RFP evaluation committee.

Copies of Proposals submitted by fax will not be accepted.

PROPOSED SOLUTION.

The Bidder should provide a comprehensive written description of its proposed solution, or if applicable, alternative solutions. To the extent that the Bidder’s solution provides functionality or performance that exceeds the requirements of this RFP, or that is unique in the industry, the Bidder is invited to explain such advantages. The description should include the following:

OVERVIEW.

Provide a summary of the proposed solution and any suggested alternatives. Provide the rationale for each alternative, and describe the strengths and limitations of each.

DETAILED RESPONSE.

Provide detailed responses to all pertinent Sections of the RFP. This detailed response shall use the headings and paragraph numbering GIVEN IN THIS RFP.

RFP EXCEPTIONS.

The Bidder must specifically state any exceptions to the requirements of the RFP so that the responsiveness of the Proposal can be evaluated and the exceptions can be addressed in any Contract that may be issued as a result of the RFP.

GENERAL EXCEPTIONS.

The Bidder shall clearly state any objections, exceptions, or alternatives to the general (non-technical) requirements stated in this RFP, including Appendix A. All such exceptions must be presented together in a separate attachment to the Proposal.

If the Bidder has no general exceptions to put forward, this fact should be stated in the Proposal.

The University does not consider the submission of the Bidder’s standard software license and maintenance agreements to be a presentation of exceptions. Every exception must be declared specifically in the document cited above.

FUNCTIONAL AND TECHNICAL EXCEPTIONS.

In its responses to the functional and technical requirements of the RFP, the Bidder shall clearly state any and all deviations from the requirements as described, including mandatory (“shall” and “must”) and preferred (“should”) requirements.

UNIVERSITY RESOURCES REQUIRED FOR IMPLEMENTATION.

Bidders must clearly identify all resources which must be provided by the University for successful implementation of the solution. The costs of such resources may be considered in the calculation of the cost of the proposal

COST WORKSHEETS.

The Bidder must present complete cost information for any Software, Software Support, Bidder implementation services, and other components of the Bidder’s Proposal. The presentation of costs must follow the requirements of Section C (Pricing Requirements).

8

The University may consider all elements of the total cost of ownership in performing its evaluation whether or not they are identified by the Bidder.

a. EXPERIENCE.

i. To be responsive Bidders must have demonstrable experience in successfully creating, updating and/or developing Access and SQL programs and databases that are:

ii. at least equal in size to the work required herein; and,

iii. at least equal in complexity to the work required herein; and,

b. HARDWARE.

i. The provision of hardware is not a requirement of this RFP. Bidder’s software solution must work within the UCSD Extension Environment. If applicable, Bidder should inform University of any hardware recommendations that might improve system performance. Any such information provided by Bidder shall be informational only, and receipt of such information shall not be construed as a waiver by the University, of any performance requirement, delivery date, or any rights or remedies provided by law or under the terms of the resulting Contract for this RFP.

c. DOCUMENTATION REQUIREMENTS.

d. Scope of Documentation.

i. The University requires that the Bidder provide high-quality Documentation explaining all concepts, functions, coding, programming, configurations, installation requirements, installation procedures, maintenance routines, methods of applying functions to accomplish the tasks for which the Product was designed, and other information necessary to operate the Products.

e. Types of Documentation.

i. The University prefers that Documentation be provided in at least the following formats: printed documentation, electronic versions of the printed documentation in a standard format (e.g., PDF), and online help files.

f. Bidder Notice Requirements.

i. The University requires a Bidder to provide the following written notices in addition to any others that may be specified in the Contract:

ii. The Bidder must provide prompt notice in case the Bidder is encountering difficulties in meeting any performance requirements or schedule under the Contract. This notice must provide pertinent details, including the scope of the problem and any projected delays.

iii. However, this notice shall be informational only, and receipt of such information shall not be construed as a waiver by the University of any Bidder performance requirement or delivery date, or any rights or remedies provided by law or under the Contract.

iv. The Bidder must provide prompt notice in case the Bidder’s work under the Contract is impeded because University staff are not available as agreed in the Contract, so that appropriate corrective action can be taken.

v. The Bidder must provide prompt notice in case the Bidder considers any work requested by the University to be outside the Scope of Work defined in the Contract.

g. Attachments

The following should be included as part of the proposal. These do not count against the page limits noted earlier.

i. Resumes of all key project team membersii. Other attachments you feel may further describe your organization’s ability to deliver on this project

B.2 Proposal Requirements

9

Each bidder is requested to submit a proposal in the format described below. The proposal should clearly demonstrate the bidder’s ability to provide the requested services. Proposals should be organized and assembled as follows. Proposals should be submitted in 12 point, double-spaced, single-sided, with 1 inch margins. The body of the proposal should be numbered consecutively starting at 1 (not including the title page and table of contents). Attachments should be numbered in a manner that is clearly distinct from the main body of the proposal.

B.2.1 Proposal contents, page limits, and formatting recommendations

Bidders shall make reasonable efforts to adhere to the following page limits and formatting requirements:

i. Title page – 1 page

Name of the RFP; name and address of bidder’s company; point of contact name, phone, e-mail; authorized signature and date.

ii. Table of contents – As necessary

iii. Executive Summary – 2 pages Describe the overall approach to fulfilling the objectives of the project; discuss project management approach, give pricing summary, company overview.

iv. Qualifications – maximum of 5 pages

a. Company background

Bidders must provide a description of their organization, including the following: i. General area of business and profile of client and product baseii. Primary place of businessiii. Other officesiv. Organizational chart that depicts corporate management structure and key proposal program personnelv. Number of employees at each locationvi. The location of the office from which the work is to be done vii. An audited financial statement (or comparable financial information) for the last two years of operation.

The organizational chart and the audited financial statements should be included in the Attachments.

b. Organizational and Project Team Experience/Qualifications

The Bidder must describe in detail the following:i. The company’s experience working with the higher education sectorii. Experience developing applications for the management of students and instructional programsiii. Software development methodologyiv. Names of key individuals serving on the project teamv. A brief description of the relevant experience and qualifications of key members of the proposed teamvi. Experience porting Microsoft Access data to SQL Server as well as upgrading to more recent versions of

Access front ends. Familiarity with Access 2007 is important. Availability of off-the-shelf or custom tools which facilitate both porting and upgrading is a plus.

The Bidder must provide at least 3 client references to support its recommended solution and the Bidder services required to implement that solution.

No less than two references must be for implementations equal in size and complexity to the implementation required herein and must include integration with Access and MS SQL.

Reference information must include the customer and division name, the name of the relevant project, and a contact name with job title, location, phone number, and email address.

References should be relevant to the requirements of this RFP, including the requirements for the scale of operation and system performance. References may be from either for-profit corporations or non-profit institutions; references from universities are especially desired.

10

The Bidder must provide references for all work performed for the University of California at any facility during the past ten years. The University may solicit and consider references from any Bidder’s customer.

c. Example of previous projects

Bidders should provide profiles of previous projects that demonstrate their ability to deliver on this project. These should include descriptions of the projects for which references are given in Section 4.4.3.

v. Technical Approach – maximum of 20 pages

a. Overall Technical approach

Describe the overall development approach you intend to use for this project.

1. Detailed approach

For each of the services described provide a detailed description of your approach on this project. This should, at a minimum, address the following:

i. What you see as the major challenge of the task

ii. What is your porting strategy

iii. Tools, package, or technology you propose to address the taskiv. Your rationale for using this approachv. Risks associated with this approachvi. Your approach to mitigating these risks

vi. Project plan and Current System Description– maximum of 10 pages

a. Project Plan

i. Project Management ApproachVendor-provided description of approach to project management.

ii. Project scheduleProjected time to complete each project deliverable.

iii. Post-release production support and future development

Vendor should indicate any interest in providing post-release production support and future architectural redesign work, both of which are outside the scope of the RFP project.

vi. Pricing – 5 pages

Per Section C and the Exhibit H.

vii. Appendices – 75 page limit

C. CURRENT SYSTEM, FUNCTIONAL REQUIREMENTS/SOW AND PRICING

C.1 CURRENT SYSTEM DESCRIPTION

This section provides a high-level description of the current application. This is intended to provide bidders with sufficient detail to assess the technical development tasks and associated costs. Detailed descriptions of nearly all

11

existing functionality in the current ELI system are provided in Appendix A of this document. The information has been compiled based on the best estimates available at the time. The actual requirements may differ at the time of the installation

Overview: The current stand-alone, mission-critical system serves as the database of record for the English Language Institute’s (ELI) administrative and academic needs. (Note: When the database was created, ELI was called “English Language Program;” hence the reference in the database file name and screen headers to “ELP.”) The ELI delivers numerous programs in English as a Second Language (ESL) instruction, from beginning language learning to advanced certificate programs in teacher training. In addition to its ESL-related activities, the ELI also serves as the primary source for the administration of all foreign and non-resident students throughout UCSD Extension. The application contains a program file (mde) and a data file (mdb). The data file is currently approximately 180 Mb in size, compacted. There are close to 12,000 records in the student table and 20,000 records in the registration table.

The purpose of the database is thus two-fold. Key primary functions are listed in the table below. Agents refer to individuals or groups, usually in other countries, who market ELI programs and facilitate student enrollment while providing a variety of related services. SEVIS (Students and Exchange Visitors Information System) is a federal database which tracks foreign students in the U.S. and is separate from the ELI IMS. The system includes internal group-based security. Following is a summary of major functions. The list is not exhaustive.

Purpose Functions Administrative student personal data

enrollment in programs registration-related accounting agents and commissions marketing reports leads room reservations transfers visa status (in conjunction with SEVIS) student services (housing, insurance, etc.) email exporting

Academic classes class requirements placement in classes based on preliminary level tests testing instructors conversation leader teaching assistants absences grades and certificates evaluations of instructors and programs instructional media student and class scheduling

The DBMS was developed with the help of a small outside consulting company, but for most of the life of the system it has been administered and significantly revised and expanded by the application administrator. A number of these changes are the indirect result of 9/11, after which the ELI was obliged to substantially augment its offerings, adding complexity that the system as originally designed was not easily able to handle. As a result, the following facts will present challenges to the development of a new system:

The tables are not normalized Tables may contain multiple keys and knowing which are actually linked is not always obvious Final migration must be done in a single overnight operation, probably requiring numerous scripts Data types are primarily numeric (mainly long or integer), Boolean, string, and date. Short-date format is preferred. There are also some auto-numbers and currency.

A more detailed description is provided below.

C.1.1 Users and Transactions

Approximately 20 ELI staff members use the database on a regular basis, based on their job function. The main staff positions and representative database-related functions are listed below:

12

Reception (data queries, leads) Visa Counselor (student registration data) 2 Academic Coordinators (all academic functions) 2 Business Manager and Assistant (accounting, student registration data) Director (marketing reports, data queries) Marketing Manager (marketing reports) Activities/Conversation Leader Coordinator (conv. leaders – similar to teaching assistants) Applications Processing (housing, registration and related functions) Program representative (academic functions in support of director and coordinators) Program support (selected academic functions in support of coordinators and instructors) Student Advisor (selected academic functions) Database Administrator and Developer (all functions)

In addition, between 40 and 70 instructors use selected academic functions on an occasional but recurring basis. During the beginning and end of each academic term, most if not all of the approximately 35 department workstations are using the database concurrently. At peak times around 100 logins occur per day, on an average day around 50-60.

C.1.2 Database organization

C.1.2.1 User Interface

The database is not strictly speaking modularized in either structure or function, but there are areas that are functionally thought of as separate, as reflected in the main menu system. At this time, these include

accounting and agents (agents meaning representatives abroad who recruit students) classes (class and section setup, rosters, book ordering) conversation leaders (management of these ‘teaching assistants’) student evaluations of instructors grades and certificates instructors maintenance (maintenance of primary tables, security, restricted utilities, data exporting) marketing reports instructional media tracking registration student scheduling and student academic data testing entry and processing other are added periodically to serve new program/administrative needs

C.1.2.2 Tables

There are close to 200 tables in the application, about 150 of which reside in the database file with the others being mainly temp tables. New tables are added as programs are developed and business services evolve. Key representative tables are as follows:

Administrative: Student Student Registration Citizenship Housing Agency Enrollment Accounting (AR) Programs Program starts Program group (collection of related programs) Program group starts

13

Academic: Attendance Classes Catalog (subset of classes, including requirements, associations with various programs) Class Schedule (instances of classes, including sections and rooms) Instructors Books Time Slots (time periods when classes are scheduled) Grades (student class records) Tests Program Tests (association of tests with programs)

C.1.2.3 Forms and Reports

There are approximately 180 forms and 250 reports.

C.1.2.4 Code

The great majority of VBA code is behind the forms and reports. A limited number of key routines are stored in a single separate code module containing numerous routines. There is also a module for global variables.

Macros are very rarely used. SQL statements are generally embedded in code rather than in stored queries.

C.1.2.5 Security

Database security is implemented by group permissions, some examples of which are found below. These provide form-level security only. Control-level security exists on an individual level. The latter allows users, for example, to maintain specific tables accessible from a single maintenance form.

Selected Security Groups: Accounting Conversation Leaders Upper Academic Limited Academic Upper Office Limited Office Evaluations Maintenance Media resources Student worker Restricted utilities

C.2 REQUIREMENTS FOR NEW SYSTEM

This section defines various requirements of the new application system. Bidder should fully discuss their proposed methodology, tools and processes for achieving each requirement based upon University’s current environment and system.

C.2.1 Functional requirements

The current ELI-IMS provides a rich set of functionality in nearly 20 modules and over 100 reports. Users are content with its value in supporting the daily administrative and academic activities. The new system should preserve current functionality as described in C.1, except for a small number of obsolete modules which will be specified during the beginning of the project.

14

C.2.2 Database technology

Over the past several years, ELI-IMS has grown in volume and functional complexity so that its scalability, availability, reliability and inter-connectability with other application systems are becoming increasingly important. It has become apparent that ELI-IMS has outgrown the foundation built upon simple Access database technology.

Meanwhile, MS SQL Server has become the standard database platform of Extension. Multiple environments of SQL Server are available, and a database administrator is in place. The conversion of the ELI-IMS database platform from Access to SQL Server is the logical next step.

The ELI-IMS database should use MS SQL Server 2005 provided by the Extension, or the latest version of the database server which is approved by the Extension project team.

C.2.3 Client interface

The client interface should be Access 2007. This new interface will allow ELI-IMS to take advantages of SQL Server and many other new capabilities of Access, such as using Windows SharePoint Services for future enhancements.

C.2.4 End user characteristics

C.2.4.1The user interface design has changed little from the early versions; at this point, changes in this regard are not a priority. It is expected that menus will be little changed at the end of this project, but if programming or business needs warrant menu changes then it must be possible to put them into effect without delay..

C.2.4.2Forms contain both built-in data-type validation and application-specific validation where necessary, but not all data is validated. It may be advisable to add some validation based on the requirements of the revised system.

C.2.4.3The application contains some functionality which is no longer required though all menu items currently visible to users are actively used

C.2.5 Hardware environment

UCSD Extension is predominantly a Microsoft Windows environment. The MS SQL server environment will be a Dell PowerEdge 2850 or similar class server running Windows server 2003 at the current patch level with the current version of MS SQL server. The MS SQL database will co-exist with other application databases that support 3 rd party and in-house developed applications.

UCSD Extension desktop computers are on a 3 year replacement cycle and are primarily Dell business-class desktop systems.

C.2.6 Network communications

The UCSD Extension network is 100 Megabit switched between the servers and desktop computers. Internet connection speeds are T1 equivalent or faster.

Security requirements

System architecture must comply with UCSD’s Minimum Network Security Standards. The most current version is available online at:

http://adminrecords.ucsd.edu/ppm/updates/135-3.PDF

UCSD Extension is moving towards Microsoft Active Directory based on Single Sign On. However, given the goal and the scope of this project, the new system will maintain its current authentication and authorization scheme until a complete redesign in the future.

Personally Identifiable Information (PII) is not allowed in the database and is not allowed according to UCSD policy, even in encrypted form. PII includes data such as social security numbers and credit card numbers. No credit card data is collected in the current system and should not be collected in the future system. 4-digit SSNs are currently

15

used to identify conversation leaders. The new system should continue to allow no PII.

C.2.7 Performance and quality requirements

Performance requirements are typical for a system expecting several thousand transactions per day.

The system must be capable of supporting up to 50 concurrent users. This is a mature system though some bugs still exist. It is expected that porting the application to SQL Server and upgrading to Access 2007 will introduce new bugs, which must be identified through rigorous testing and bug resolution. To ensure the data retrieval activities demonstrate visible performance improvement faster on the new platform than on the old when simulating maximum-user activity (approximate 50 users), a few existing processor-intensive routines will be selected for comparison.  The speed of completion must be faster running under SQL Server / Access 2007 than it is running under Access 97. For data > input activities, the new system is expected to deliver subsecond response time, also during simulated maximum–user activity of about 50 users.

C.2.8 Transition requirement and timeframe

The transition from the current production system to the new system should be as transparent as possible. Zero or minimum impact to the ELI business is expected. Data migration from Access to SQL Server is within the project scope, and should be completed upon the production release of the new system.

16

C.3 SCOPE OF WORK AND DELIVERABLES

C.3.1 Scope of services and expected deliverables.

C.3.1.1 Conduct technical pilot

At the beginning of the project, one functional unit of the system will be selected by UCSD Extension for the vendor in order to perform a technical proof of concept. The objective is to quickly prove the feasibility of the technical approach before a fully engaged implementation takes place. The Vendor is to port Access client and the related database independent of any integration requirements, and deliver the unit to the development environment, which should be populated with sufficient data for the Extension project team to assess. This will be the first milestone of the project.

C.3.1.2 Inventory functional modules

Appendix A provides a detailed breakdown of the majority of features of the existing application. It is a primary goal of the project to reproduce this functionality in the new application. However in the intervening months since Appendix A was developed, minor enhancements have been added that will be part of the development effort. There are also a few features in the existing application that are no longer required.

During the first month of the project, the Extension project team will work with the selected vendor to review all current and planned features and finalize an inventory to serve as the functional scope of the development effort. Enhancement activities to the current system will be frozen upon the delivery of the document by vendor and acceptance by Extension.

C.3.1.3 Port Access database to SQL Server database

The goal is to change tables and relations only where absolutely necessary so as to require a minimum of changes to forms and reports.

Review table structure in light of functional scope. Making structure changes as needed only, or those that can be made without impacting the functionality of the application as a whole. Update and eliminate tables as necessary Create new ELI-IMS instance and load data for project development

A new SQL Server backend database replacing existing Access database should be delivered. The database should support the new and fully functional Access client. The deliverable includes, but is not limited to, all database scripts used in defining the SQL Server database structure.

C.3.1.4 Port Access 1997 client to Access 2007

Vendor should upgrade client codes from Access 97 to Access 2007, and make the new codes fully compatible with the new SQL Server database, which is specified in C.3.1.3. The deliverable should run without any unexpected issues or functional deviation from the current system, unless otherwise specified in the scope document and approved by the Extension project team.

C.3.1.5 Migrate data from Access database to SQL Server database

Vendor should migrate all ELI-IMS data, stored in the current Access database and relevant to the defined scope, to the new SQL Server database as specified in C.3.1.3.

The deliverable should include the end results and the data migration scripts, all final documentation, and admin/key user training (see sections C.3.2.5 and C.3.2.6).

C.3.2 Process related requirements

17

C.3.2.1 Extension development environment

UCSD Extension will provide one onsite workstation and an SQL Server database environment for the vendor to facilitate implementation of the project. Vendor will have accounts and VPN access to the Extension network if remote access is needed. The vendor is expected to have a representative working at least 30 hours per week onsite until the completion of the pilot.

A QA database server will be provided by Extension for the purpose of beta testing in the QA environment. This will allow vendor to continue development effort while beta testing is in progress.

C.3.2.2 Agile development process

Vendor should be attuned to the Agile software development process throughout the project and follow the methodology closely. Working with the Extension project team, vendor will divide the implementation into three to five iterations of activities ; each will cover planning, requirement gathering, analysis, conceptual design, implementation, alpha testing and beta testing for a functional grouping of system modules.

Populate tables in the databases Each iteration of the development process will require vendor to populate the QA database with production data,

and prepare for beta testing at the end. Although a functional focus exists for each iteration, the QA database will need to be completely populated in order to test.

Requirement gathering and analysis as needed Although the core of this project focuses on technology upgrade, there may be times when requirement gathering

and analysis are necessary. For example, when a deviation of current functionality is approved by the Extension project team, vendor should document the definition of new requirements and provide impact analysis.

Conceptual /visual design and user review If a new form or a change to the existing user interface is necessary, vendor should provide a visual design of the

new form, get feedback and acquire approval from the Extension project team. Logical/ physical design and implementation If any conceptual design is required, vendor should perform logical design and physical design after the

conceptual design is approved. Vendor should use the source control system provided by Extension and ensure all source codes, scripts and

documents are updated in the system in a timely manner. Code review will be conducted periodically. Vendor should strive to maintain good organization and comments in

the source codes, whenever applicable, to ease the long-term support efforts.

C.3.2.3 Testing

Vendor should perform their own unit testing and integrated alpha testing in the development environment, against the development database server, before releasing source codes to the QA environment for beta testing. Extension project team will participate in the beta testing and report issues to the vendor. Vendor project manager is responsible for keeping track of the bugs and reporting back the status. If any bug is found in the new system and not the current system, vendor should resolve the bug independently. If any bug is found in both current system and new system, vendor should work jointly with the ELI-IMS developer to get the fix in place. All bugs in the second category are expected to get resolved as soon as possible. Once a new version is ready, another round of beta testing process will be repeated. At the last iteration of the project development process, a fully integrated beta release will be conducted for final user acceptance testing against the QA database. Vendor should refresh the QA database with the latest data from the production database to facilitate a comparison of data validity and functional consistency across the current system and the new system.

C.3.2.4 Data migration and production deployment

Once the Extension project team approves the new Access client, SQL Server database structure and the results of data migration scripts, vendor should coordinate with the Extension project team to select an optimal go-live date given the business calendar.

ELI-IMS system administrator will freeze data entry activity during the transition period Vendor will perform a final round of data migration to production database and get the client ready for production release Extension project team will perform a final quality check

18

New system will be released to production on the scheduled go-live date

C.3.2.5 Training and knowledge transfer

The in-house database administrator and ongoing developer is not an IT professional but is very familiar with VBA in Access 97. He knows SQL and has some notions of TRANSACT-SQL though he has never actually worked with MS SQL Server or Access 2007. Sufficient knowledge transfer (in the form of meetings, documentations, recommended books or courses) must be provided to allow him to continue in this role at the conclusion of the project.

End-user training should be minimal if the goal of maintaining the user interface and functionality is achieved.

C.3.2.6 Other Deliverables

Systems administrator documentation - which covers installation, trouble shooting, Application administrators documentation - intended for the ELI staff responsible for supporting end-users Development documentation - intended for the in-house developer to enhance and debug the new system Database maintenance documentation - for Extension DBA to perform production support

C.3.2.7 Project management support

We expect the vendor to provide a dedicated Project Manager (PM) for the life of the project. The individual should have the technical background and experience appropriate for the project, as well as experience managing a complex development project. The PM must be budgeted and committed to spending at least 20% of their time on this project.

The PM is responsible for managing the day-to-day project activities, providing weekly updates on budget and project status, participating in regular onsite meetings to review technical and contract progress, and identifying project risks and suggesting steps to mitigate them. The PM is expected to provide the following as part of the contracted activities:

Project schedules, milestones, resources using MS Project Weekly status, bug reports, meeting minutes and other documentation as appropriate for reporting project status

C.3.2.8 Extension-provided resources

End-user liaison Access to in-house application developer Development, QA and production database environments

C.3.2.9 Extension project team

Title RoleJen-Yi Wang Manager,

Extension Application Development

Project coordinator

Kim Renner Manager, Extension Computing Services

Hardware, network support

David Fein ELI Database Administrator

Database maintenance, support, development, functional lead

Roxanne Nuhaily Director of ELI End-user supervisor, project champion

C.4 PRICING REQUIREMENTS

19

C.4.1. FIRM PRICES.

All prices quoted in the Bidder’s Proposal shall be firm and fixed for one hundred and eighty (180) calendar days following the deadline for RFP submissions, or until a Contract is negotiated and signed that establishes future pricing, whichever comes first.

C.4.2. COMPLETE PRICES

Proposals must include all charges required to complete the work required herein.

If applicable, all costs for freight, shipping, crating, and delivery must be quoted in the Proposal. Proposals quoted “FOB delivered freight prepaid and allowed” will be considered to meet this requirement.

Bidders must quote maximum “not to exceed” amount for travel and per diem expenses. These costs will be included in the evaluation of cost.

C.4.3. PRICE LEVELS AND DISCOUNTS.

The Bidder should propose any alternative price models or payment terms that would lower the University's overall cost for the initial one-year and five-year periods following the effective date of the Contract.

The Bidder should offer options such as caps on maintenance fee increases to enable the University to meet its need for cost stability.

The Bidder should clearly specify any additional discount that would be applicable if a Contract is approved by the University prior to a date convenient to the Bidder.

The Bidder warrants that the prices offered in its bid are equal to or are lower than those offered for equivalent quantities of Products and services to similar institutional accounts. The Bidder shall apply any special university or educational pricing that will lower the cost to the University.

In order to allow a fair comparison of proposals all prices should be quoted FOB delivered freight prepaid and allowed.

C.4.4. PRICING FORMAT.

The Bidder must complete one EXHIBIT H, MANDATORY PRICING. All spaces must be filled in. Specific dollar amounts, “N/C” (no charge), “included in line __ above” are acceptable entries.

The Bidder shall quote the costs for each price category quoted on the mandatory pricing sheet. Bidder must set out all assumptions and expectations built into bidder’s pricing. All pricing alternatives should be quoted in these cost worksheets. By submitting such worksheets the University will be able to determine what costing assumptions were made to make up the Bidder’s PRICE, per mandatory pricing sheet (Exhibit H).

The Bidder shall quote prices in U.S. dollars.

The Bidder shall identify the exact amount of the Price quoted that is subject to California Sales or Use Tax. The University is subject to California Sales and Use Tax.

To the extent possible, any applicable discounts should be shown separately from the prices for products and services, as global figures.

Separate subtotals should be shown for the core or essential elements of the proposed solution and for any layers of optional elements.

C.4.5. PRICING METHODOLOGY.

The Bidder should make clear the rationale and basis of calculation for all fees.

The University prefers that separate costs be quoted for all items in the proposed solution, including hourly fees and fees for licenses, maintenance, support, consultation, training, customizations, etc. However, the Bidder should also present alternatives to itemized costs and discounts, such as bundled pricing, if such pricing would be advantageous to the University.

In presenting fees, the Bidder should:

20

1. Explain all factors, assumptions and expectations that could affect the fees.

2. With regards to a license, make clear what type of license is offered for each price (perpetual, annual, named user, concurrent user, installed copies, processor-based, etc.).

3. Should include in their proposal any third party license agreement that is proposed as part of any agreement that may result from this RFP.

4. Indicate which Product versions, Operating Platform(s), and machine classes are recommended for the solution.

5. Indicate whether a Product is for “server” or “client,” as appropriate.

6. Make clear the extent of any implementation services that are included in the license fees (installation, configuration, training, etc.).

The Bidder should provide an explanation of the constraints affecting the pricing, warranty, and other aspects of its Proposal that arise from the Bidder’s way of managing revenue recognition.

C.4.6. PAYMENT SCHEDULE.

The University’s initial orders under the Contract shall be payable thirty (30) days following the effective date of the Contract or following delivery and successful installation, whichever occurs later.

SECTION D. TERMS AND CONDITIONS.

The following provisions shall be incorporated into the Contract that results from this RFP.

D.1. PERIOD OF CONTRACT.

The period of the Contract shall begin on the date of the Contract’s approval by both parties and shall last at least until the completion of all stages of testing and implementation as well as the expiration of any warranties as defined in the Contract. The selected Vendor is expected to complete the project and acquire formal acceptance within a seven-month timeframe starting the beginning of the Phase 1 implementation.

The period of the Contract may be extended by mutual agreement of the parties in writing.

Terms and conditions that survive the expiration or termination of the Contract will be specified in the Contract.

D.2. COSTS.

D.2.1. Tax on Products and Services.

Taxes that are applicable for Products and services purchased by the University under the Contract will be specified in the Contract based on current excise tax regulations of the State of California that apply to software and services.

D.2.2. Bidder Expenses.

If any travel and related expenses for On-Site services by Bidder personnel are to be paid by the University under the Contract, the Bidder shall use its best efforts to include estimates of those expenses it their bid, and subsequently minimize such expenses during performance of the contract. All such expenses must have the prior written approval of the University, which shall not be unreasonably withheld or delayed.

Regardless of the amount quoted the University will pay only for actual, necessary, customary and reasonable travel and expenses supported by valid receipts up to the amount quoted in the winning Bidder’s Proposal. The University will not be responsible for any travel and per diem expenses over the amount quoted unless such expenses are required for work outside the scope of this RFP and approved in advance in writing

21

D.3. PAYMENT.

D.3.1. Payment Terms.

The University’s standard payment terms are net 30 days after completion of a payment milestone and receipt of invoice. The payment milestone for Software is Acceptance. The University shall not be subject to any late fees or finance charges. The University also will consider prompt payment discounts of 2% ten, net 30.

D.3.2. Timely Notification of Past Due Invoices.

The Bidder shall notify the University if payment has not been received forty-five days after University’s receipt of invoice.

D.3.3. Renewal Notices.

Notices of renewal of Software Support must be delivered to the University between thirty (30) and ninety (90) days prior to the renewal date.

Notices of price changes for Software Support renewals must be delivered to the University between sixty (60) and one hundred twenty (120) days prior to the renewal date.

D.4. SOFTWARE OWNERSHIP TERMS.

D.4.1. UCSD Software

UCSD owns all right and title to the layout, content and processes related to the ELI-IMS system

D.4.2. Bidder SoftwareBidder acknowledges and agrees that any and all Developments, made or conceived solely or jointly by Bidder or created wholly or in part by Bidder, in connection with the Services are "works made for hire" within the meaning of the Copyright Act, 17 U.S.C. Section 101 et. seq., and are the exclusive property of University. Bidder hereby assigns to University all proprietary rights, if any, including, without limitation, all copyright and patent rights, that Bidder may now or hereafter have to any such Developments. Bidder agrees, at the request of University and for no additional consideration, to execute such documents and perform such other acts as University deems necessary in connection with such assignment. Notwithstanding the foregoing, Bidder shall retain a perpetual, royalty-free, worldwide, non-exclusive, transferable license to possess, copy, use modify, disclose, distribute and sublicense without restriction those portions of the Bidder’s software not specifically developed or modified as a part of the Services, such as previously developed source code derived from the Bidder’s toolkit, used in developing the University’s solution. Bidder shall not be liable for any damages or claims of infringement based on changes, alterations or modifications made to the Developments by University.

D.4.3. Disabling Code. Bidder agrees that, except as specifically permitted in the Contract, the Software delivered under the Contract shall be free of any code or mechanism that is designed to disable operation of the Software on any date or after any lapsed period of time or to enable the Bidder or any third party to disable operation of the Software by any technical means (“Disabling Code”).

D.4.4. Virus Protection. Bidder agrees to take reasonable steps to test Software delivered under the Contract for Virus Code as defined below and represents that the Software will be free, to the best of Bidder’s knowledge, of Virus Code as of the date of receipt from Bidder. Bidder agrees to take such steps with respect to future enhancements or modifications to the Software. Bidder further agrees that it will maintain an object-code master copy of each supported version of the Software free and clear of any known Virus Code. In the event that the University discovers an error in the Software that may be attributable to Virus Code, upon the University’s written request, Bidder agrees to duplicate a copy from the master copy and make such duplicate copy available to the University for comparison with and, if necessary, correction of the University’s copy of the Software.

D.4.5. Proprietary Rights Indemnity. Proprietary Rights. Bidder shall indemnify, defend, and hold harmless University, its officers, agents, and employees against all losses, damages, liabilities, costs, and expenses (including but not limited to attorneys' fees) resulting from any judgment or proceeding in which it is determined, or any settlement agreement arising out of the allegation, that Bidder's furnishing or supplying University with software code, components, programs, practices, or methods under this order or University's use of such software code, components, programs, practices, or methods supplied

22

by Bidder under this order constitutes an infringement of any patent, copyright, trademark, trade name, trade secret, or other proprietary or contractual right of any third party. The foregoing shall not apply unless University has informed Bidder as soon as practicable of the suit or action alleging such infringement. Seller shall not settle such suit or action without the consent of University. University retains the right to participate in the defense against any such suit or action.

If Software provided under the Contract is, or in Bidder's opinion is likely to become, the subject of a claim, suit, or proceeding of infringement, Bidder (1) may procure for the University, at no cost to the University, the right to continued usage of the Software, or (2) may replace or modify the Software to make it non-infringing, at no cost to the University, provided that the functionality of the Software is not impaired. If none of the foregoing options is feasible, at Bidder’s sole discretion, the Bidder may terminate the license for such Software. In the event of such termination, the University shall be entitled to a pro-rata refund based on the depreciation of license fees on a straight-line sixty (60) month basis commencing with the delivery of the Software to University or the Effective Date of this Agreement, whichever comes first, added to a pro-rata refund of the current year’s maintenance fees on a straight twelve (12) month basis.

The foregoing indemnification does not extend to any claim arising out of a modification of the Software by University, or any claim arising out of the combination, operation, or use of the Software with software or hardware not provided or recommended by Bidder, except to the extent that the claim is based solely on the portion of such combination that is delivered or recommended by Bidder.

Any limitation of Bidder's liability included in the Contract shall not apply to this proprietary rights indemnity.

D.4.6. Warranties.

D.4.6.i. Software Warranty. The Bidder warrants that software and software code received by the University under the Contract shall operate substantially without Errors as defined in the Contract for a period of one year beginning with the Acceptance Date of the Contract (the “Warranty Period”). During the Warranty Period, the University shall provide prompt written notice and evidence of Errors to the Bidder, and the Bidder will perform services necessary to correct Errors without additional charge to the University. If during the Warranty Period the Bidder is unable to correct any Error that substantially affects the operation of the Software, the University is entitled to the refund of all fees paid by the University under the Contract.

D.5. ACCEPTANCE TERMS

During the Acceptance Period, The University shall perform whatever acceptance tests on the Software it may wish to confirm that the Software is Operating according to the specified requirements. If The University discovers during the Acceptance Period that any Software is not Operative, The University shall notify The Bidder of the deficiencies. The Bidder, at its own expense, shall modify, repair, adjust, or replace the Software to make it Operative within ten (10) days after the date of The University’s deficiency notice. The University may perform additional acceptance tests during a period commencing when the Bidder has delivered revised Software correcting all of the deficiencies The University has noted. This restarted Acceptance Period shall have duration equal to that of the initial Acceptance Period, unless The University earlier accepts the Software in writing. If the Software, at the end of the Acceptance Period as so extended, still is not Operative in The University’s judgment after consultation with the Bidder, The University may reject the Software and terminate this Agreement for material breach or, at its option, repeat the procedure of this paragraph as often as it determines is necessary. If The University does not notify the Bidder of acceptance or rejection of the Software, it shall be deemed accepted at the end of the Acceptance Period extended pursuant to this paragraph.

Acceptance by the University shall not waive any rights that University might otherwise have at law or by express reservation in the Contract with respect to any nonconformity subsequently discovered.

D.6. NON-DISCLOSURE TERMS

The parties to the Contract shall hold in confidence, and withhold from third parties, any and all Proprietary Information (as defined below) disclosed by one party to the other and shall use the other party’s Proprietary Information only for the purposes stated herein (the “Permitted Purposes”) and for no other purpose unless the disclosing Party shall agree herein or hereafter in writing.

23

Each party agrees to safeguard from theft, loss, and negligent disclosure the other party’s Proprietary Information received pursuant to this RFP or the Contract by utilizing the same degree of care as the receiving party utilizes to safeguard its own Proprietary Information of a similar character from theft, loss, and negligent disclosure, but in no event less than reasonable care. Each party agrees to limit access to Proprietary Information to those officers, directors, and employees within the receiving party’s organization, and to the party’s subcontractors, who reasonably require such access to accomplish the Permitted Purposes.

Each party agrees not to reproduce or copy by any means the Proprietary Information of the other party except as reasonably required to accomplish the Permitted Purposes. The parties shall not remove any trademark or proprietary rights legend from the Proprietary Information of the other party.

Each party agrees the confidential or proprietary information disclosed by one party to the other shall be deemed “Proprietary Information” when the information:

(1) consists of technical and commercial information owned or licensed by either party, including without limitation any and all software programs, data and data structures, descriptions of computing infrastructure and configuration, security technologies, and any and all related techniques, discoveries, inventions, processes, copyrights, know-how, trade secrets, source code, object code, algorithms, specifications, documentation, and passwords or other confidential methods of information access; or

(2) is provided to the other party in written or other recorded form and is identified as proprietary by means of an appropriate legend, marking stamp, or other clear and conspicuous written identification that unambiguously indicates the information being provided is the disclosing party’s Proprietary Information; or

(3) is disclosed in other than written or other recorded form, but only to the extent identified as the disclosing party’s Proprietary Information at the time of original disclosure and thereafter summarized in a written form that clearly identifies the Proprietary Information. Such summary shall be transmitted by the disclosing party to the receiving party within fifteen (15) calendar days of the disclosure to which it refers.

All Proprietary Information disclosed pursuant to this Contract shall be and remain the property of the disclosing party or its third-party suppliers. Except as expressly specified in this Contract, neither party to this Contract acquires any license, right, title, or interest in and to the Proprietary Information received from the other party. Each party shall inform such employees of the non-disclosure obligations set forth herein and shall obligate in writing any subcontractors to comply with the non-disclosure requirements stated herein.

Each party shall give prompt written notice to the other party upon becoming aware of any unauthorized use or disclosure of the Proprietary Information. Each party agrees to use its best efforts to remedy such unauthorized use or disclosure of the Proprietary Information at its own expense. Each party acknowledges and agrees that in the event of an unauthorized use, reproduction, distribution, or disclosure of any Proprietary Information, the other party will not have an adequate remedy at law and, therefore, injunctive or other equitable relief would be appropriate to restrain such use, reproduction, distribution, or disclosure, threatened or actual.

Neither party shall be liable for use nor disclosure of what would otherwise be considered Proprietary Information if it can establish by contemporaneous, clear, and convincing written evidence that such information, in substantially the same form and content:

1. is or becomes a part of the public knowledge without breach of the Contract by the receiving party; or

2. is known to the receiving party without restriction as to further disclosure when received; or

3. is independently developed by the receiving party without the use, directly or indirectly, of information received under this or other obligation of confidentiality with the disclosing party; or

4. becomes known to the receiving party from a third party who had a lawful right to disclose it without breaching the Contract; or

5. is approved in writing for release or use by an authorized employee of the other party; or

6. is disclosed in response to a valid order of a court of competent jurisdiction or other governmental body of the United States or any political subdivision thereof, or is otherwise required to be disclosed by law; provided, however, that the receiving party shall first have given prompt written notice to the disclosing party in order to allow objection by the disclosing party to any such order or requirement,

24

or to otherwise protect the rights of the disclosing party and its suppliers prior to the disclosure. If a particular portion or aspect of the Proprietary Information becomes subject to any of the foregoing exceptions, all other portions or aspects of such information shall remain subject to all of the above non-disclosure provisions. In the case of any conflict between this provision and D.7.f below Right to Know Legislation. the terms and conditions of Section D.7.f. shall take precedence.

D.6.1. Confidentiality of Personal Data.

In the course of providing services under this Contract, the Bidder may be given access to Personal Data, which shall mean any information related to individual University-related persons, including but not limited to personal names, University status, login IDs and passwords, as well as age, gender, home or office addresses, telephone numbers (including fax and cell phone numbers), physical characteristics, and preferences. The Bidder will maintain the confidentiality of all such Personal Data, shall limit access to Personal Data to its employees and subcontractors who perform services under the Contract, and shall promptly destroy any copies of Personal Data maintained by the Bidder upon completion of the tasks that required use of the Personal Data, evidence of which must be supplied to the University.

25

D.6.2. Confidentiality of Student Records/FERPA.

In the course of providing services under a Contract, the Bidder may be given temporary access by the University to confidential student information stored in the University’s databases. All such disclosures of student information by the University will be governed by the Federal Family Educational Rights and Privacy Act (FERPA) and University policy implementing FERPA. The Bidder will treat this student information as confidential and will not further disclose this student information except in those instances allowed by law. Any use of this student information for any purpose, other than the purpose for which the disclosure was made, is prohibited. The Bidder shall promptly destroy any copies of this student information maintained by the Bidder upon completion of the tasks that required access to the student information, evidence of which will be supplied to the University. The Bidder will defend, indemnify, and hold harmless, to the extent permitted by law, the University, its officers, employees, and agents, from and against all losses, penalties, expenses (including reasonable attorneys' fees), damages and liabilities resulting from or arising out of the Bidder’s failure to comply with its FERPA obligations under a Contract, provided that such losses, penalties, expenses, damages, and liabilities are determined to be due to the negligent or willful acts or omissions of the Bidder, its officers, employees, agents, subcontractors, or anyone employed by them, or any persons under the Bidder’s direction and control.

D.6.3. Duplication Rights for Documentation.

The University shall have the right to make electronic or printed copies of the electronic versions of the Documentation.

D.6.4. Use of English.

The Bidder must provide to the University an English-language version of all Software and Documentation; technical support and other contract services; and proposals, quotations, and other business communications.

D.7. MISCELLANEOUS TERMS

D.7.1. Appendix A.

The attached Appendix A, University of California Terms and Conditions of Purchase, shall be incorporated into to the Contract that results from this RFP. In the case of conflict between the terms and conditions of Appendix A and those of the Contract, the terms and conditions of the Contract shall take precedence.

D.7.2. Non-assignment and Subcontracting.

The Bidder shall not assign the Contract or any services there under without the prior written consent of the University. The Bidder may, with prior written permission from the University, enter into subcontracts with third parties for performance of any part of the Bidder’s duties and obligations, provided that in no event shall the existence of a subcontract operate to release or reduce the liability of the Bidder to the University for any breach in the performance of the Bidder’s duties. Acceptance by the University of the Bidder’s Proposal for performance hereunder, which identifies any proposed subcontractors and fully describes the duties and qualifications of such subcontractors, shall be considered permission from the University for the Bidder to enter into such proposed subcontracts. The Bidder agrees that all subcontractors shall be agents of the Bidder, and the Bidder agrees to hold the University harmless under the Contract for any loss or damage of any kind occasioned by the acts or omissions of the Bidder’s subcontractors, their agents, or employees.

All personnel in Key Roles shall be subject to the University’s approval.

The terms and conditions of the Contract shall be binding upon and inure to the benefit of the parties thereto and their respective heirs, successors, and assigns.

D.7.3. Termination for Convenience.

University may, by written notice stating the extent and effective date cancel and/or terminate the Contract for convenience in whole or in part, at any time. University shall pay the Bidder for satisfactory performance provided through the date of such termination. No termination made under this provision shall preclude the University from thereafter entering into an agreement with another Bidder for similar services.

26

D.7.4. Termination for Cause.

In the event that the University determines that the Bidder has materially breached the Contract, the University shall notify the Bidder in writing of the nature of the breach and shall give the Bidder thirty (30) days during which the Bidder must effect a cure. If the Bidder is unable or refuses to effect a cure within the 30-day period, or if after the 30-day period the University determines that the breach has not been cured to University’s satisfaction, whichever occurs first, the University may, by written notice, terminate the Contract. In such event, the University may purchase or otherwise secure software and services to accomplish the Scope of Work, and, except as otherwise provided in the Contract, the Bidder shall be liable to the University for any excess costs incurred by University because of the termination.

In the event that the Bidder determines that the University has materially breached the Contract, the Bidder shall provide to the University a written notice specifying the breach and shall give University at least sixty (60) days to effect a cure. If the breach is not cured to the Bidder’s satisfaction, the Bidder may propose a remedy that is proportionate to the alleged breach, and the two parties shall enter into negotiations concerning an appropriate remedy.

D.7.5. Dispute Resolution.

The parties agree that any dispute between the parties concerning the Contract that cannot be resolved by the personnel charged with implementing the Contract shall be submitted in writing to a designated senior executive of both the Bidder and the University. The two executives shall engage in direct discussions in an effort to resolve the dispute, and any decisions mutually agreed by the executives will be final and binding on the parties. In the event the executives are unable to resolve any dispute within thirty (30) days after it is submitted to them, either party may refer the dispute to a court of final jurisdiction or, if both parties agree, to arbitration.

D.7.6. Right to Know Legislation.

The University of California is subject to the Public Records Act. If prospective bidders and Bidders designate any documents submitted as part of the bid process as “confidential,” the University shall review such documents and make a written determination that the marked documents qualify as exempt to public disclosure, prior to accepting them as such. If the University believes that the marked documents do not qualify for such a designation, the Bidder or bidder shall be so informed and shall have the option to withhold those documents from their final bid or proposal. Documents identified and accepted by the University as non-exempt documents are subject to public disclosure. (See Also D.6 above, Non-Disclosure.)

D.7.7. Auditing of Contract.

Any Contract issued pursuant to this RFP shall be subject to the examination and audit of the Auditor General of the State of California for a period of three years after final payment under the Contract. The examination and audit will be confined to those matters connected with the performance of the Contract, including but not limited to, the costs of administering the Contract. Until the expiration of four years after the furnishing of services provided under a Contract, the Bidder shall (if necessary) make available to the Secretary, U.S. Department of Health and Human Services, the U.S. Controller General, and their representatives, the Contract and all books, documents, and records necessary to certify the nature and extent of the costs of those services.

D.7.8. Ethics.

The Bidder shall comply with University policies on gifts and gratuities. The Bidder shall exercise reasonable care and diligence to prevent any action or conditions that could result in a conflict with the University’s interest. During the period of the Contract, the Bidder shall not accept any employment or engage in any work that creates a conflict of interest with the University or in any way compromises the work to be performed under the Contract. The Bidder and/or its employees shall not offer substantial gifts, entertainment, payments, loans, or other consideration to the University’s employees, their families, other contractors, subcontractors, and other third parties for the purpose of influencing such persons to act contrary to the University’s interest. The Bidder shall immediately notify the University of any and all such violations of this provision upon becoming aware of such violations.

27

D.7.9. Standards of Work.

Work performed by the Bidder shall be done in accordance with the specifications and standards set forth in the Contract and, where no specific standards are set forth in the Contract, shall be of a quality equal to the highest quality provided and accepted in the software industry for similar work.

D.7.10. Loss of Equipment.

The University will not be responsible for the loss of equipment or materials left on University premises by the Bidder during the performance of work covered by the Contract.

D.7.11. No Free Parking.

No free parking space is provided by the University for vehicles used by the Bidder in fulfilling the Contract.

D.8. UCSD TERMS AND CONDITIONS - APPENDIX AUniversity of California

Terms and Conditions of Purchase

ARTICLE 1 - The materials, supplies or services covered by this order shall be furnished by Seller subject to all the terms and conditions set forth in this order including the following, which Seller, in accepting this order, agrees to be bound by and to comply with in all particulars and no other terms or conditions shall be binding upon the parties unless hereafter accepted by them in writing. Written acceptance or shipment of all or any portion of the materials or supplies, or the performance of all or any portion of the services, covered by this order shall constitute unqualified acceptance of all its terms and conditions. The terms of any proposal referred to in this order are included and made a part of the order only to the extent it specifies the materials, supplies, or services ordered, the price therefor, and the delivery thereof, and then only to the extent that such terms are consistent with the terms and conditions of this order.

ARTICLE 2 - INSPECTION. The services, materials and supplies furnished shall be exactly as specified in this order free from all defects in Seller's performance, design, workmanship and materials, and, except as otherwise provided in this order, shall be subject to inspection and test by University at all times and places. If, prior to final acceptance, any services and any materials and supplies furnished therewith are found to be incomplete, or not as specified, University may reject them, require Seller to correct them without charge, or require delivery of such materials, supplies, or services at a reduction in price which is equitable under the circumstances. If Seller is unable or refuses to correct such items within a time deemed reasonable by University, University may terminate the order in whole or in part. Seller shall bear all risks as to rejected services and, in addition to any costs for which Seller may become liable to University under other provisions of this order, shall reimburse University for all transportation costs, other related costs incurred, or payments to Seller in accordance with the terms of this order for unaccepted services and materials and supplies incidental thereto. Notwithstanding final acceptance and payment, Seller shall be liable for latent defects, fraud or such gross mistakes as amount to fraud.

ARTICLE 3 - CHANGES. University may make changes within the general scope of this order in drawings and specifications for specially manufactured supplies, place of delivery, method of shipment or packing of the order by giving notice to Seller and subsequently confirming such changes in writing. If such changes affect the cost of or the time required for performance of this order, an equitable adjustment in the price or delivery or both shall be made. No change by Seller shall be allowed without written approval of University. Any claim of Seller for an adjustment under this Article must be made in writing within thirty (30) days from the date of receipt by Seller of notification of such change unless University waives this condition in writing. Nothing in this Article shall excuse Seller from proceeding with performance of the order as changed hereunder.

ARTICLE 4 - TERMINATIONA. University may, by written notice stating the extent and effective date, cancel and/or terminate this order for convenience in whole or in part, at any time. University shall pay Seller as full compensation for performance until such termination:(1) the unit or pro rata order price for the performed and accepted portion; and(2) a reasonable amount, not otherwise recoverable from other sources by Seller as approved by University, with respect to the unperformed or unaccepted portion of this order, provided compensation hereunder shall in no event exceed the total order price.

B. University may by written notice terminate this order for Seller's default, in whole or in part, at any time, if Seller refuses or fails to comply with the provisions of this order, or so fails to make progress as to endanger performance and does not cure such failure within a reasonable period of time, or fails to perform the services within the time specified or any written extension thereof. In such event, University may purchase or otherwise secure services and, except as otherwise provided herein, Seller shall be liable to University for any excess costs occasioned University thereby. If, after notice of termination for default, University determines that the Seller was not in default or that the failure to perform this order was due to causes beyond the control and without the fault or negligence of Seller (including, but not restricted to, acts of God or of the public enemy, acts of University, acts of Government, fires, floods, epidemics, quarantine restrictions, strikes, freight embargoes, unusually severe weather, and delays of a subcontractor or supplier due to such causes and without the fault or negligence of the subcontractor or supplier), termination shall be deemed for the convenience of University, unless University shall determine that the services covered by this order were obtainable by Seller from other sources in sufficient time to meet the required performance schedule.

C. If University determines that Seller has been delayed in the work due to causes beyond the control and without the fault or negligence of Seller, University may extend the time for completion of the work called for by this order, when promptly applied for in writing by Seller; any extension granted shall be effective only if given in writing. If such delay is due to failure of University, not caused or contributed to by Seller, to perform services or deliver property in accordance with the terms of the order, the time and price of the order shall be subject to change under the Changes Article. Sole remedy of Seller in event of delay by failure of University to perform shall, however, be limited to any money actually and necessarily expended in the work during the period of delay, solely by reason of the delay. No allowance will be made for anticipated profits.

D. The rights and remedies of University provided in this Article shall not be exclusive and are in addition to any other rights and remedies provided by law or under this order.

E. As used in this Article, the word "Seller" includes Seller and its subsuppliers at any tier.

ARTICLE 5 - LIABILITY FOR UNIVERSITY - FURNISHED PROPERTY. Seller assumes complete liability for any tooling, articles or material furnished by University to Seller in connection with this order and Seller agrees to pay for all such tooling, articles or material damaged or spoiled by it or not otherwise accounted for to University's satisfaction. The furnishing to Seller of any tooling, articles, or material in connection with this order shall not, unless otherwise expressly provided, be construed to vest title thereto in Seller.

28

ARTICLE 6 - TITLE. Title to the material and supplies purchased hereunder shall pass directly from Seller to University at the f.o.b. point shown, or as otherwise specified in this order, subject to the right of University to reject upon inspection.

ARTICLE 7 - PAYMENT, EXTRA CHARGES, DRAFTS. Seller shall be paid, upon submission of acceptable invoices, for materials and supplies delivered and accepted or services rendered and accepted. University will not pay cartage, shipping, packaging or boxing expenses, unless specified in this order. Drafts will not be honored. Invoices must be accompanied by shipping documents or photocopies of such, if transportation is payable and charged as a separate item.

ARTICLE 8 - CHARACTER OF SERVICES. Seller, as an independent contractor, shall furnish all equipment, personnel and material sufficient to provide the services expeditiously and efficiently during as many hours per shift and shifts per week and at such locations as the University may so require and designate.

ARTICLE 9 - FORCED, CONVICT, AND INDENTURED LABORA. By accepting this order, Seller hereby certifies that no foreign-made equipment, materials, or supplies furnished to the University pursuant to this order will be produced in whole or in part by forced labor, convict labor, or indentured labor under penal sanction.

B. Any Seller contracting with the University who knew or should have known that the foreign-made equipment, materials, or supplies furnished to the University were produced in whole or in part by forced labor, convict labor, or indentured labor under penal sanction, when entering into a contract pursuant to the above, may have any or all of the following sanctions imposed:

(1.) The contract under which the prohibited equipment, materials, or supplies were provided may be voided at the option of the University.

(2.) Seller may be removed from consideration for University contracts for a period not to exceed 360 days.

ARTICLE 10 - INDEMNITY.A. General. Seller shall defend, indemnify, and hold harmless University, its officers, employees, and agents, from and against all losses, expenses (including attorneys' fees), damages, and liabilities of any kind resulting from or arising out of this agreement and/or Seller's performance hereunder, provided such losses, expenses, damages and liabilities are due or claimed to be due to the negligent or willful acts or omissions of Seller, its officers, employees, agents, subcontractors, or anyone directly or indirectly employed by them, or any person or persons under Seller's direction and control.

B. Proprietary Rights. Seller shall indemnify, defend, and hold harmless University, its officers, agents, and employees against all losses, damages, liabilities, costs, and expenses (including but not limited to attorneys' fees) resulting from any judgment or proceeding in which it is determined, or any settlement agreement arising out of the allegation, that Seller's furnishing or supplying University with parts, goods, components, programs, practices, or methods under this order or University's use of such parts, goods, components, programs, practices, or methods supplied by Seller under this order constitutes an infringement of any patent, copyright, trademark, trade name, trade secret, or other proprietary or contractual right of any third party. The foregoing shall not apply unless University has informed Seller as soon as practicable of the suit or action alleging such infringement. Seller shall not settle such suit or action without the consent of University. University retains the right to participate in the defense against any such suit or action.

C. Products. Seller shall fully indemnify, defend, and hold harmless University from and against any and all claim, action, and liability, for injury, death, and property damage, arising out of the dispensing or use of any of Seller's product provided under authorized University orders. In addition to the liability imposed by law on the Seller for damage or injury (including death) to persons or property by reason of the negligence, willful acts or omissions, or strict liability of the Seller or his agents, which liability is not impaired or otherwise affected hereby, the Seller hereby assumes liability for and agrees to save University harmless and indemnify it from every expense, liability or payment by reason of any damage or injury (including death) to persons or property suffered or claimed to have been suffered through any act or omission of the Seller.The University agrees to provide Seller with prompt notice of any such claims and to permit Seller to defend any claim or suit, and that it will cooperate fully in such defense.

ARTICLE 11 - DECLARED VALUATION OF SHIPMENTS. Except as otherwise provided on the face of this order, all shipments by Seller under this order for University's account shall be made at the maximum declared value applicable to the lowest transportation rate or classification and the bill of lading shall so note.

ARTICLE 12 - WARRANTY. Seller agrees that the supplies or services furnished under this order shall be covered by the most favorable commercial warranties the Seller gives to any customer for the same or substantially similar supplies or services, or such other more favorable warranties as specified in this order. The rights and remedies so provided are in addition to and do not limit any rights afforded to University by any other article of this order. Such warranties will be effective notwithstanding prior inspection and/or acceptance of the services or supplies by the University.

ARTICLE 13 - ASSIGNMENT AND SUBCONTRACTING. This order is assignable by University. Except as to any payment due hereunder, this order may not be assigned or subcontracted by Seller without written approval of University. In case such consent is given, it shall not relieve Seller from any of the obligations of this Agreement and any transferee or subcontractor shall be considered the agent of Seller and, as between the parties hereto, Seller shall be and remain liable as if no such transfer or subcontracting had been made.

ARTICLE 14 - EQUAL OPPORTUNITY AFFIRMATIVE ACTION. Seller shall not maintain or provide racially segregated facilities for employees at any establishment under its control. Seller agrees to adhere to the requirements set forth in Executive Orders 11246 and 11375, and with respect to activities occurring in the State of California, to the California Fair Employment and Housing Act (Government Code section 12900 et seq.). Expressly, Seller shall not discriminate against any employee or applicant for employment because of race, color, religion, sex, national origin, ancestry, medical condition (as defined by California Code section 12925f]), marital status, age, physical and mental handicap in regard to any position for which the employee or applicant for employment is qualified, or because he or she is a disabled veteran or veteran of the Vietnam era. Seller shall further specifically undertake affirmative action regarding the hiring, promotion and treatment of minority group persons, women, the handicapped, and disabled veterans and veterans of the Vietnam era. Seller shall communicate this policy in both English and Spanish to all persons concerned within its company, with outside recruiting services, and the minority community at large. Seller shall provide the University on request a breakdown of its labor force by groups, specifying the above characteristics within job categories, and shall discuss with the University its policies and practices relating to its affirmative action programs.

ARTICLE 15 - The clauses contained in the following paragraphs of the Federal Acquisition Regulations are incorporated by reference. The full text is available upon request:FAR 52.222-04 Contract Work Hours and Safety Standards ActFAR 52.222-26 Equal OpportunityFAR 52.223-02 Clean Air and Water (If order exceeds $100,000)

ARTICLE 16 - WORK ON UNIVERSITY OR GOVERNMENT PREMISES. If Seller's work under this order involves performance by Seller at University or United States Government owned sites or facilities, the following provisions shall apply:A. Liens. Seller agrees that at any time upon request of University he will submit a sworn statement setting forth the work performed or material furnished by subcontractors, suppliers and materialmen, and the amount due and to become due to each, and that before the final payment called for hereunder, will if requested, submit to University a complete set of vouchers showing what payments have been made for materials and labor used in connection with the work called for hereunder.Seller shall:(1) Indemnify and hold harmless University from all claims, demands, causes of action or suits, of whatever nature, arising out of the services, labor and materials furnished by Seller or its subcontractors under this order, and from all laborers', materialmen's and mechanics' liens upon the real property upon which the work is located or any other property of University;(2) Promptly notify University in writing, of any such claims, demands, causes of action, or suits brought to its attention. Seller shall forward with such notification copies of all pertinent papers received by Seller with respect to any such claims, demands, causes of action or suits and, at the request of University shall do all things and execute and deliver all appropriate documents and assignments in favor of University of all Seller's rights and claims growing out of such asserted claims as will enable University to protect its interest by litigation or otherwise. The final payment shall not be made until Seller, if required, shall deliver to University a complete release of all liens arising out of this order, or receipts in full in lieu thereof, as University may require, and if required in either case, an affidavit that as far as it has knowledge or information, the receipts include all the labor and materials for which a lien could be filed; but Seller may, if any subcontractor refuses to furnish a release or receipt in full, furnish a bond satisfactory to University to indemnify it against any claim by lien or otherwise. If any lien or claim remains unsatisfied after all payments are made, Seller shall refund to University all monies that the latter may be compelled to pay in discharging such lien or claim, including all costs and reasonable attorneys' fees.

29

B. Cleaning Up. Seller shall at all times keep University premises where the work is performed and adjoining premises free from accumulations of waste material or rubbish caused by its employees or work of any of its subcontractors, and, at the completion of the work; shall remove all rubbish from and about the building and all its and its subcontractors' tools, scaffolding, and surplus materials, and shall leave the work "broom clean" or its equivalent, unless more exactly specified. In case of dispute between Seller and the subcontractors employed on or about the structure or structures upon which the work is to be done, as herein provided, as to responsibility for the removal of the rubbish, or in case the same be not promptly removed as herein required, University may remove the rubbish and charge the cost to Seller.

C. Employees. Seller shall not employ on the work any unfit person or anyone not skilled in the work assigned to him or her, and shall devote only its best-qualified personnel to work under this order. Should University deem anyone employed on the work incompetent or unfit for his or her duties and so inform Seller, Seller shall immediately remove such person from work under this order and he or she shall not again, without written permission of University, be assigned to work under this order.It is understood that if employees of University shall perform any acts for the purpose of discharging the responsibility undertaken by the Seller in this Article 15, whether requested to perform such acts by the Seller or not, such employees of the University while performing such acts shall be considered the agents and servants of the Seller subject to the exclusive control of the Seller.D. Safety, Health and Fire Protection. Seller shall take all reasonable precautions in the performance of the work under this order to protect the health and safety of employees and members of the public and to minimize danger from all hazards to life and property, and shall comply with all health, safety, and fire protection regulations and requirements (including reporting requirements) of University. In the event that Seller fails to comply with said regulations or requirements of University, University may, without prejudice to any other legal or contractual rights of University, issue an order stopping all or any part of the work; thereafter a start order for resumption of work may be issued at the discretion of the University. Seller shall make no claim for extension of time or for compensation or damages by reason of or in connection with such work stoppage.The safety of all persons employed by Seller and its subcontractors on University premises, or any other person who enters upon University premises for reasons relating to this order, shall be the sole responsibility of Seller. Seller shall at all times maintain good order among its employees and shall not employ on the work any unfit person or anyone not skilled in the work assigned to him or her. Seller shall confine its employees and all other persons who come onto University's premises at Seller's request or for reasons relating to this order and its equipment to that portion of University's premises where the work under this order is to be performed or to roads leading to and from such work sites, and to any other area which University may permit Seller to use. Seller shall take all reasonable measures and precautions at all times to prevent injuries to or the death of any of its employees or any other person who enters upon University premises. Such measures and precautions shall include, but shall not be limited to, all safeguards and warnings necessary to protect workers and others against any conditions on Owner's premises which could be dangerous and to prevent accidents of any kind whenever work is being performed in proximity to any moving or operating machinery, equipment or facilities, whether such machinery, equipment or facilities are the property of or are being operated by, the Seller, its subcontractors, the University or other persons.To the extent compliance is required, Seller shall comply with all University safety rules and regulations when on University premises.

ARTICLE 17 - INSURANCESeller shall defend, indemnify, and hold the University, its officers, employees, and agents harmless from and against any and all liability, loss, expense (including reasonable attorneys' fees), or claims for injury or damages that are caused by or result from the negligent or intentional acts or omissions of Seller, its officers, agents, or employees.Seller, at its sole cost and expense, shall insure its activities in connection with the work under this order and obtain, keep in force, and maintain insurance as follows (unless the insurance requirements are stated otherwise in the purchase order):A. Comprehensive or Commercial Form General Liability Insurance (contractual liability included) with limits as follows:

Each Occurrence $ 1,000,000

Products/Completed OperationsAggregate $ 2,000,000

Personal and Advertising Injury $ 1,000,000

Fire Damage (any one fire) $ 100,000

Medical Expenses (any one person) $ 5,000

General Aggregate (Not applicableto the Comprehensive Form) $ 2,000,000

If the above insurance is written on a claims-made form, it shall continue for three years following termination of this Agreement. The insurance shall have a retroactive date of placement prior to or coinciding with the effective date of this Agreement.

B. Business Automobile Liability Insurance for owned, scheduled, non-owned, or hired automobiles with a combined single limit not less than one million dollars ($ 1,000,000) per occurrence. (REQUIRED ONLY IF SELLER DRIVES ON UNIVERSITY PREMISES IN THE COURSE OF PERFORMING WORK FOR UNIVERSITY.)

C. Professional Liability Insurance with a limit of Two million dollars ($2,000,000) per occurrence with an aggregate of not less than Two million dollars ($2,000,000) or as indicated on the purchase order. If this insurance is written on a claims-made form, it shall continue for three years following termination of this Agreement. The insurance shall have a retroactive date of placement prior to or coinciding with the effective date of this Agreement.

D. Workers' Compensation as required by California State law.

It is understood that the coverage and limits referred to under a., b., and c. above shall not in any way limit the liability of Seller. Seller shall furnish the University with certificates of insurance evidencing compliance with all requirements prior to commencing work under this Agreement. Such certificates shall:(1) Provide for thirty (30)-days advance written notice to the University of any modification, change, or cancellation of any of the above insurance coverage.

(2) Indicate that The Regents of the University of California has been endorsed as an additional insured for the coverage referred to under a. and b. This provision shall only apply in proportion to and to the extent of the negligent acts or omissions of Seller, its officers, agents, or employees.(3) Include a provision that the coverage will be primary and will not participate with nor be excess over any valid and collectible insurance or program of self-insurance carried or maintained by the University.

ARTICLE 18 - PERMITS. Seller agrees to procure all necessary permits or licenses and abide by all applicable laws, regulations and ordinances of the United States and of the state, territory and political subdivision in which the work under this order is performed. Seller shall be liable for all damages and shall indemnify and save University harmless from and against all damages and liability which may arise out of failure of Seller to secure and pay for any such licenses or permits or to comply fully with any and all applicable laws, ordinances and regulations.

ARTICLE 19 - COOPERATION. Seller and its subcontractors, if any, shall cooperate with University and other vendors and contractors on the premises and shall so carry on their work that other cooperating vendors and contractors shall not be hindered, delayed or interfered with in the progress of their work, and so that all of such work shall be a finished and complete job of its kind.

ARTICLE 20 - WAIVER OF DEFAULT. Any failure of University at any time, or from time to time, to enforce or require the strict keeping and performance by Seller of any of the terms or conditions of this order shall not constitute a waiver by University of a breach of any such terms or conditions and shall not affect or impair such terms or conditions in any way, or the right of University at any time to avail itself of such remedies as it may have for any such breach or breaches of such terms or conditions.

30

ARTICLE 21 - TAXES. Seller shall pay all contributions, taxes and premiums payable under federal, state and local laws measured upon the payroll of employees engaged in the performance of work under this order, and all applicable sales, use, excise, transportation, privilege, occupational and other taxes applicable to materials and supplies furnished or work performed hereunder and shall save University harmless from liability for any such contributions, premiums, and taxes.

ARTICLE 22 - OTHER APPLICABLE LAWS. Any provision required to be included in a contract of this type by any applicable and valid federal, state or local law, ordinance, rule or regulations shall be deemed to be incorporated herein.

ARTICLE 23 - GOVERNING LAW. The law of the State of California shall control this Appendix and any document to which it is appended.

31

SECTION E. INSTRUCTIONS TO BIDDERS

E.1. NEGOTIATION OF CONTRACT.

It is the University’s intention that any Contract with a Bidder issued as a result of this RFP will incorporate all requirements and provisions of the RFP. If a Bidder submits exceptions to any requirements of the RFP in the manner described in the Section on “Proposal Format and Contents,” the University will address such exceptions in developing any Contract that may be issued as a result of this RFP.

The University reserves the right to negotiate the resolution of exceptions, irregularities, or errors included in a Proposal, provided that such action will not negate fair competition and will permit proper comparative evaluation of the Proposals, as determined by the judgment of the University Buyer or designee.

E.2. CONTACTS WITH UNIVERSITY MANAGEMENT.

Bidders are not permitted to contact University personnel about this RFP or about a Contract developed as a result of this RFP except as instructed below. Correspondence by Email is preferred.

Bidders must direct all required RFP documents and inquiries to Bryan Hurley as set forth on the cover page of this RFP.

It will be appreciated if Bidders include their firm’s name, abbreviation or acronym in the subject line of email, and in the file name, and in the document title of all attachments. Any other contact with University personnel regarding the subject matter of this RFP may result in the disqualification of the Bidder.

E.3. SUBMITTAL DEADLINE.

In order to be considered, a Proposal shall be delivered to the address indicated herein above prior to the Submittal Deadline. Any Proposal received after the Submittal Deadline shall be rejected and returned. It is the Bidder’s sole responsibility to assure that its Proposal is received at the required location prior to the Submittal Deadline.

E.4. RESPONSIVE PROPOSALS.

The Proposal must be complete, be submitted by the Submittal Deadline in the required format, and satisfy all of the “shall or must” requirements in the RFP. Otherwise, the University may declare the Proposal to be non-responsive and not consider it further.

E.5. AUTHORIZED PROPOSAL.

The Proposal and all Bidder correspondence related to it shall be from a duly authorized representative of the Bidder.

E.6. OWNERSHIP AND COPYING OF PROPOSAL.

All Proposals become the property of the University. You hereby agree by your actions of submitting a Proposal to the University to have assigned all copy right in said Proposal to the University. All information and materials contained in a Proposal submitted to the University may be reproduced by the University for the purpose of providing copies to University personnel authorized to evaluate the Proposal.

E.7. PROPOSAL ACCEPTANCE PERIOD.

The University will have a period of 180 days from the deadline for Proposals to accept, reject, or negotiate the final terms of a Contract with the selected Bidder.

E.8. BIDDER'S WITHDRAWAL, MODIFICATION, AND RESUBMISSION OF PROPOSALS.

Proposals may be withdrawn and/or resubmitted at any time prior to the Deadline for Proposals. Proposals may be modified by a written (including faxed) request from the Bidder prior to the Deadline for Proposals.

32

The Bidder's contacts regarding withdrawal, modification, or resubmission of a Proposal shall be directed to the University personnel identified in this RFP, unless the University directs the Bidder in writing to contact other personnel.

E.9. UNIVERSITY’S AMENDMENTS TO RFP.

The University may revise or add to the RFP prior to the Deadline for Proposals and, at its own discretion, may extend the deadline for all potential Bidders. Such amendments will be sent by one of the following methods: Electronic Mail (Email); facsimile transmission; overnight courier; or certified mail with return receipt requested.

Amendments will be clearly marked as such. Each amendment will be numbered consecutively and will become part of this RFP.

Any Bidder who fails to receive such amendments shall not be relieved of any obligation under its Proposal as submitted.

No oral or written statements made by University personnel shall be considered an amendment to this RFP unless the statement is contained in a written document identified as a written amendment to this RFP.

E.10. REJECTION OF PROPOSALS.

The University reserves the right to reject any and all Proposals. The University may reject a Proposal from a Bidder who has been delinquent in any prior contract with the University. The University reserves the right to re-solicit Proposals. The University does not guarantee that a Contract will be signed as a result of this RFP.

E.11. INTEGRITY OF RESPONSE.

In preparing Proposals, Bidders are cautioned not to delete or alter any material that the University included in this RFP, including the University’s terms, conditions, specifications, or forms, as such changes may render a Proposal non-responsive.

E.12. COSTS OF RESPONSE TO RFP.

The University is not liable for any costs incurred by a Bidder or potential Bidder in making a Proposal. Bidders are responsible for all costs related to a Proposal, including the cost of attending meetings or making presentations.

E.13. LOW BALL SUBMITTALS.

The University shall enter into a Contract only after it has determined that prices to be paid are reasonable. The University reserves the right to have a Bidder provide additional documentation supporting the Bidder's pricing and the Bidder's ability to meet the responsibilities stated in the RFP.

E.14. BID PROTEST.

Any actual or prospective Bidder who has a complaint regarding the solicitation or award of the Contract should first attempt to resolve the grievance with the University Buyer named herein above or other University contracting officer involved in the transaction. If a controversy over the solicitation or award of the Contract cannot be resolved at this level, the complainant may file a protest or notice of other controversy with the University of California, San Diego (UCSD), Strategic Purchasing Manager. If such controversy cannot be resolved by the Strategic Purchasing Manager it shall be referred to the Director of Purchasing.

If the UCSD Director of Purchasing becomes involved in the controversy, the Director of Purchasing will appoint individuals to investigate the issues involved in the complaint, analyze the findings, consult with University General Counsel, and promptly issue a decision in writing. A copy of the decision will be mailed or otherwise furnished to the complainant and will state the reasons for the decision.

A protest or notice of other controversy must be filed promptly and in any event within two calendar weeks after such complainant knows or should have known of the facts giving arise thereto. All protests or notices of other controversies must be in writing. In the event of a timely filed protest, the University will not proceed further with the solicitation or award involved until the protest is resolved or withdrawn, unless the UCSD Director of Purchasing consults with General Counsel and makes a written and adequately supported determination that continuation of the procurement is necessary to protect substantial interests of the

33

University. Written notice of the decision to proceed will be given to the complainant and others the University deems as concerned with the transaction.

E.15. PENALTY FOR COLLUSION.

If at any time the University shall find that the Bidder to which a Contract has been awarded has, in presenting a Proposal, colluded with any other party or parties, the University reserves the right to cancel or terminate the Contract so awarded and the Bidder shall be liable to the University for all loss or damage that the University may have suffered.

E.16. MULTIPLE AWARDS.

The University reserves the right to make an award in whole or in part, or to make multiple awards as an outcome of this RFP when it is determined to be in its best interest and at its sole discretion.

SECTION F. REQUIRED SUBMITTALS – PROPOSAL FORMAT

The due date for the Proposal is given on the first page of the RFP. Prior to the due date, Bidders who intent to submit a Proposal must return to University Contact, EXHIBIT A – Notice of Intent.

PROPOSAL FORMAT:

See below for a detailed description of the required Proposal contents and format.

F.1. Notice of Intent to Respond to RFP and RESPONSE COVER PAGE (EXHIBITS A & B).

If you are intending to bid for this RFP, please return to University Contact Exhibit A, prior to February 7th, 2008.

The Proposal must be submitted with a Response Cover Page (EXHIBIT B), which must be signed by an individual who is authorized to bind the Bidder contractually. In addition to the signature of that individual, this page must show the individual's printed name and title, the date of signature, the name of the company, and the Reference Number of the RFP.

F.2. Insurance Certification Form (EXHIBIT C)

F.3. Business Information Form (EXHIBIT D).

F.4. Conflict of Interest Form (EXHIBIT E).

F.5 Bidder’s Reference Form (Exhibit F).

F.6. BIDDER’S TECHNICAL PROPOSAL, Including FUNCTIONAL AND TECHNICAL SPECIFICATIONS (EXHIBIT G)

F.7. BIDDER’S PRICE PROPOSAL Including MANDATORY PRICING FORM (EXHIBIT H).

F.8. HARDWARE RECOMMENDATION SHEET (EXHIBIT I) – NOT APPLICABLE

F.9. STANDARD BIDDER AGREEMENTS.

The Bidder should submit its proposed software license and maintenance agreements along with its Proposal. These agreements provide a useful point of reference for the University when the Contract is prepared. However, the University is not obligated to accept the terms and conditions of such agreements unless they conform substantially to the requirements of this RFP.

F.10. PRODUCT DOCUMENTATION.

The Bidder must provide one electronic copy of Product documentation in a standard file format or if Product documentation is not available in electronic format Bidder must provide one printed copy of Product documentation. One electronic and (if provided) one printed copy must accompany the written RFP response and will be retained by the University as part of the RFP record. The Electronic copy of the documentation

34

should be saved in a separate “Folder” from the Proposal. The printed copy (if provided) should be in a separate document from the proposal and not bound together with the Proposal.

F.11. PRODUCT DEMONSTRATION.

The Bidder is required, if requested by the University, to provide a live demonstration of its proposed Software. The Bidder should propose options for carrying out such a demonstration. For demos proposed at a University site, the Bidder should detail its space and equipment requirements that would need to be fulfilled by the University.

If a product demonstration is presented under this RFP, the demo shall enable the University to observe any or all end-user and system administrator functions that are proposed in the Bidder’s response to the RFP, except to the extent that a function cannot be fully demonstrated because doing so would require use of the University’s actual data or integration with University systems as described in the RFP.

F.12. PILOT TESTING.

The Bidder is required, if requested by the University, to provide the proposed Products to the University for a limited time at no cost to the University for the purpose of evaluating and testing the capabilities of a proposed system in a production context. The University and the Bidder will work together to determine an appropriate test period and software/hardware configuration. Any software, hardware, and other materials associated with the evaluation and testing will be returned to the Bidder upon completion of the evaluation and test and will remain the property of the Bidder.

35

SECTION G. BASIS OF AWARD

Any Contracts resulting from this solicitation shall be awarded to the lowest responsible responsive bidders meeting specifications. The “lowest” proposals will be determined on a “cost per quality point basis”.

G.1. COST PER QUALITY POINT SCORE:

The following formula will be used to compute a Bidder’s cost-per quality point score.

cost / quality point score = cost per quality point score

G.2. REJECTION OF PROPOSALS

The University reserves the right to reject all proposals and make no award.

The University reserves the right to make an award in the aggregate or in parts as its interests may appear. In particular the University may elect to buy hardware including but not limited to such items scanners, computers or storage equipment from other suppliers in accordance with its interests.

G.3. EVALUATION PROCESS.

Proposals will be evaluated under this RFP in four stages:

First the University will evaluate each Proposal on the basis of its conformance to the RFP instructions, completeness, clarity of content, and responsiveness to the mandatory requirements (“shall”, “must”, “will”, “should”) in the RFP. Proposals that do not conform may be rejected by the University as non-responsive and will not pass to the second stage.

During this stage, Proposals also will be evaluated to determine each Bidder’s qualifications, including financial resources, and relevant experience. Bidders who do not meet a minimum standard of said qualifications will be disqualified as non-responsive.

The second stage will be an evaluation of the merits of the Technical Proposal. Quality points will be awarded to each item being scored according to how well the Proposal satisfies the requirement. The number of points available for each item may vary depending upon the relative importance of the item. Proposals shall also be evaluated for their acceptance of University terms and conditions. A Bidder must receive a minimum of 2/3 of possible points to pass on to the third stage.

The third stage will be the cost over quality point evaluation. Proposals at this stage will be evaluated and scored on a cost-per-quality-point basis, and the costs will be calculated according to a multi-year projection. Then the cost will be divided by the quality point score awarded in the second stage. Ideally, at least two bidders receiving the lowest cost per quality point score will pass on to the fourth stage.

In the fourth stage, References will be evaluated and points awarded. The University may require at least two Bidders with the lowest cost per quality point score to demonstrate their proposed solutions, and such demonstrations will be scored (if they have not already occurred). References will be scored in this phase. Scores from the demonstrations and References will be added to the quality point scores awarded in stage three and the cost per quality point score for those Bidders will be recalculated. The University may also, or instead, require pilot testing of the proposed solution by University staff.

G.4. BIDDER DISQUALIFICATION.

A Bidder may be disqualified at any stage based on misrepresentation and/or omission of facts; lack of credibility of proposed costs, technologies, or implementation procedures; evidence of collusion among Bidders; or failure of the Bidder to perform in a satisfactory or faithful manner on any previous contract or order with the University.

G.5. CONTRACT NEGOTIATION.

The Bidder who’s Proposal receives the lowest cost per quality point score will be given the opportunity to engage in final negotiations on a Contract. If, however, the University is unable to reach agreement with a

36

Bidder, the University reserves the right to cease negotiations with that Bidder and commence negotiations with the Bidder having the next lowest cost-per-quality-point score, or to reject all Proposals.

G.6. VACATED AWARD.

If the Contract is terminated for breach within 180 days of its effective date, the University reserves the right to negotiate a Contract with the Bidder next in line according to the evaluation.

37

SECTION H. LIST OF EXHIBITS AND APPENDIX

APPENDIX A. UCSD TERMS AND CONDITIONS SET FORTH IN SECTION D.8

APPENDIX B. UCSD EXTENSION EXISTING SYSTEM DESCRIPTION

APPENDIX C. UCSD EXTENSION GLOSSARY

EXHIBIT A. Notice of Intent.

EXHIBIT B. Proposal Cover Page.

EXHIBIT C. Insurance Certification Form.

EXHIBIT D. Business Information Form.

EXHIBIT E. Conflict or Interest Form.

EXHIBIT F. Bidder’s Customer References Form.

EXHIBIT G. Bidder’s Functional and Technical Specifications

EXHIBIT H. Pricing Form

EXHIBIT I. Hardware Recommendation Sheet. – Not applicable

38

SECTION I. DEFINITION OF TERMS

1. Acceptance Period —the period commencing on the date the system is put into Production Use and continuing for thirty (30) days, as such period may be extended pursuant to the section entitled Acceptance.

2. Acceptance Date — the first business day after University accepts the Software.

3. Appendix A – Terms and conditions of Purchase.

4. Bidder — The firm, partnership, corporation or sole proprietorship submitting a Proposal in response to this RFP.

5. Campus (or San Diego Campus) — Same as “University.”

6. Contract — A binding agreement between The Regents of the University of California and the successful Bidder pursuant to this RFP.

7. Day — A calendar day unless specified otherwise. (Not a capitalized term.)

8. Department/Departmental - Police, Human Resources, Environmental Health & Safety, Business Affairs, and Administrative Computing & Telecommunications Departments’ of University

9. Developments - Include any and all ideas, inventions, designs, computer programs, modules, products and related documentation and other works of authorship, developed in connection with the Project, including, without limitation, the reports referred to in other Sections of this Agreement, the Attachments and the Exhibits hereof.

10. Director of Purchasing – Linda Collins, Central Purchasing.

11. Effective Date – the date of the last signatory to the Contract.

12. General Counsel – The legal services of the University of California.

13. Installation Date — The date the Software has been properly installed.

14. Personal Data – all information in any shape or form including but not limited to personal names, University status, login IDs and passwords, as well as age, gender, home or office addresses, telephone numbers (including fax and cell phone numbers), physical characteristics, and preferences.

15. Proposal — The written response to this RFP received from a Bidder.

16. Proprietary Information — See the “Non-Disclosure” section of the RFP.

17. Reference Number — A number (or string of letters) assigned by the University to identify this RFP and appearing on the cover page of the RFP.

18. RFP — The Request for Proposal contained in this document.

19. Scope of Work — All obligations, duties, requirements, specifications, and responsibilities needed for the successful completion of the Contract by the Bidder, including the furnishing of all Software, Documentation, Software Support, installation and consulting services, training, materials, labor, supervision, and supplies as required by the Contract.

20. Shall — When used to describe a commitment or element of performance by the Bidder or the Software, this verb means that the requirement must be fully met. (Not a capitalized term.)

21. Should — When used to describe a commitment or element of performance by the Bidder or the Software, this verb means that the University prefers that the requirement be met but does not deem the requirement to be mandatory. (Not a capitalized term.)

39

22. Strategic Purchasing Manager – Robert Neuhard, Central Purchasing.

23. Submittal Deadline — the deadline for delivery of the required Proposal as shown on the cover page of this RFP.

24. University — The Regents of the University of California on behalf of the University of California, San Diego.

25. University Buyer – Bryan Hurley, Central Purchasing.

General Technical/Project Terms:

1. Acceptance — With regard to deliverables from the Bidder under the Contract, the University’s decision that a deliverable meets the requirements of the Contract.

2. Bundled Technology — Software licensed by the Bidder from a third party supplier that is incorporated into the Bidder’s Software or co-packaged with the Bidder’s Software; or other technology that is co-packaged with the Bidder’s Software.

3. Customization — A change or addition to the Software made by the Bidder to adapt the Software’s functionality, performance, or user interface to the requirements of the University as stated in the Contract.

4. Department(s) – see Section I.

5. Development – the software coding done on behalf of the University as part of this engagement

6. Documentation — Documentation in printed and/or electronic form that explains the installation and use of Software provided by the Bidder under the Contract.

7. Enterprise basis – delivery to all of the Departments at the one time.

8. Error (or “Bug”) — A failure of the Software to conform in any material respect to the specifications defined in the Contract, including any Performance Standards. To the extent that it does not conflict with the specifications in the Contract, a failure of the Software to operate in any substantial respect as described in the Documentation is deemed to be an Error.

9. Error Correction (or “Bug Fix”) — A modification or addition to the Software that, when installed, removes a verifiable and reproducible Error in the Software.

10. Hosts – device where software is installed. Could be either a server or a desktop system.

11. Individual basis – delivery to each Department in turn.

12. Key Role — One of the Bidder personnel roles, specifically identified as a “Key Role” in the Contract, that has a major impact on the successful completion of the Bidder’s obligations under the Contract.

13. Licensed Site — The University of California, San Diego, including all locations not situated on the main campus, unless otherwise defined in the Contract.

14. On-Site — at premises owned or rented by the University of California, San Diego, including all such premises not located on the main campus.

15. Operating Platform — A specific computer type or computer model, and its operating system, together with any peripheral devices and other equipment, with which the Software is designed to be operated.

16. Performance Standard — a standard defined in the RFP or the Contract for the responsiveness, throughput, reliability, or other performance-related characteristics of the Software

17. Power User – a person who is responsible for the day-to-day operation of the Software and Bundled Technology at the University for the scanning of documents for the Department as defined at Section I.

40

18. Product — Any Software or Documentation offered in the Bidder’s Proposal or licensed by the University under the Contract.

19. Production Use — Use of the Software as the principal method for performing a type of business or academic operation at the University. Use of real data for test purposes does not constitute Production Use.

20. Software — Software applications, modules, tools, utilities, etc., that are developed or recommended by Bidder in the Proposal or licensed by University under the Contract. Software includes any updates and upgrades or patchesprovided by the Bidder as part of Software Support or otherwise. Software also includes Source Code to the extent that such is provided by the Bidder in accordance with the Contract.

21. Software Support — Maintenance and support services for the Software that are offered by the Bidder.

22. Source Code — Human-readable software code, including printed copies thereof, that must be converted into machine-readable language by the use of compilers, assemblers, and/or interpreters.

23. Technical Proposal – as defined at Section B, Exhibit B, and G.2.b to the RFP.

24. Third-Party Technology — Information technology products recommended by the Bidder that would need to be purchased from a third party or that would require a University contract with a third party.

25. Upgrade(s) — a release of the Software that incorporates substantial new or substantially improved functionality, performance, or user interfaces.

26. Update(s) — a release of a Software Product that incorporates Error Corrections and might include some improvements in functionality, performance, or user interfaces.

27. Use — (when employed as a verb or noun to describe the University’s operation of the Software) To copy (or the copying of) any portion of the Software from storage devices or media into one or more central processing units (CPUs) for processing. (Not a capitalized term.)

28. User – A staff member of the University that has the ability to read, down load and print the digitized documents once stored on the Software and/or Bundled Technology by the Power User.

29. Virus Code – Virus Code is defined as computer instructions that alter, destroy, or inhibit the Software and/or the University’s processing environment including but not limited to other programs, computer equipment, data, storage devices, and computer libraries ("Virus Code"). Virus Code includes but is not limited to programs that self-replicate without manual intervention, instructions (other than user passwords necessary for operation) that disrupt, interrupt, or interfere with the functionality of computer hardware or the Software whether such interference is destructive or not, instructions (other than user passwords necessary for operation) performing any function other than the function of the Software as represented in the technical manuals and program descriptions published by Bidder whether active from the time of the installation of the Software or programmed to activate at a predetermined time or upon a specified event, and/or programs purporting to do a meaningful function in the Software as represented in the technical manuals and program descriptions published by Bidder but designed for a different function

30. Warranty Period – a period of one year beginning with the Acceptance Date of the Contract

41

RFP EXHIBIT A

NOTICE OF INTENT TO RESPOND TO RFP

DATE:      

RE: UCSD RFP #0803 RMN

Submittal of this Notice of Intent to Respond to RFP does not commit a prospective proposer to submitting a proposal. It does insure that the Bidder will be included in any communication regarding the RFP that may be issued by UCSD.

Name      

Title      

Company (“Proposer” or “Bidder”)      

Address      

Phone      

Fax      

Email      

Signature _____________________________________

Please return this Notice of Intent to the UCSD Contact (listed on the cover page of the RFP) by email (preferred) or fax.

42

RFP EXHIBIT B

PROPOSAL COVER PAGE

RFP Number:       Date Submitted:      

Bidder Company Name:      

Address:      

Name and Title of Contact Person:      

Phone Number:       Fax Number:      

Email:      

Individual(s) with the authority to negotiate/authorize an agreement between your company and The Regents of the University of California:

Name and Title of Contact Person:      

Phone Number:       Fax Number:      

Email:      

Proposer Company Federal Taxpayer ID Number:      (While this information is optional at the proposal stage, FEIN must be provided before any contract will be issued.)

The undersigned agrees that this proposal constitutes an offer to The Regents of the University of California on behalf of the University of California, San Diego which shall be valid for a period of ninety (90) calendar days after the proposal due date or until a contract is fully executed between The Regents of the University of California on behalf of the University of California, San Diego and another, whichever is earlier. The undersigned acknowledges that he/she has examined and is fully familiar with the documents incorporated therein and that any exceptions to that document are indicated herein.

Check One: No exceptions are taken Exceptions are attached

All of the forms submitted by the Bidder with its proposal are incorporated by reference herein. The undersigned certifies to the truthfulness and

accuracy of the information contained on all such forms. The Bidder further certifies that it will perform the services as stated in this RFP and will

comply with the specifications, all relevant attachments, and the terms and conditions of this RFP, if a contract is awarded as a result of this

proposal, subject to any exceptions noted in its proposal. The Bidder warrants that the products and services specified in the proposal in

response to this RFP, including Bidder-recommended third-party products, include all items, components, quantities, services, etc., necessary to

provide UCSD with the functional and performance capability required by the RFP, unless otherwise stated in the proposal. Should additional

items be required in order to meet the performance standards included in the RFP and the proposal, the Bidder shall provide them to UCSD at no

additional cost.

Bidder Company Name:      

Signature:

Print Name:      

Title:      

Date:      

43

For UCSD use onlyDate/time Received: Technical proposals __Cost proposal ___Checked by: _____

RFP EXHIBIT C

Insurance Certification Form

Before any contract is issued in response to this RFP, the Bidder will be required to show evidence of adequate insurance coverage by furnishing UCSD with a Certificate of Insurance. The Certificate of Insurance should indicate that such insurance policy or policies will not be reduced or cancelled without 30 days’ prior written notice to UCSD. Certificates must be issued naming THE REGENTS OF THE UNIVERSITY OF CALIFORNIA as an additional insured, and as a separate endorsement to the Certificate of Insurance. Minimum limits of coverage are outlined in the University of California Terms and Conditions of Purchase, Article 17, Insurance, which is made a part of this RFP. However, the Successful Bidder will be required to comply with the additional insurance requirements and increased minimum limits set forth on http://www.ucop.edu/ucophome/policies/bfb/bus63.html, if applicable. It is the obligation of the Bidder to verify with the University Contact the minimum limits required for this RFP.

If your company is self-insured, a Certificate of Self-Insurance will be required. If you are unable to provide such a certificate, an acceptable alternative is statement signed by an officer (risk manager, treasurer, etc.) accepting self-insurance liability, provided documentation is furnished indicating that the necessary financial resources to perform are available when such liability is imposed by law. Said documentation may be in the form of audited financial statements, annual reports, or funded self-insurance.

Please check the appropriate box for each question:

1. Yes No Bidder meets the Insurance Requirements for the coverage and in the amounts specified in University of California Terms and Conditions of Purchase, Article 17, Appendix A.

2. Yes No Bidder will add The Regents as an additional Insured as a condition of award of contract.

3. Yes No Bidder is self-insured. If yes, a Certificate of Self- Insurance will be provided prior to award of contract.

44

RFP EXHIBIT DBUSINESS INFORMATION FORM. SUPPLIER OF GOODS OR SERVICES ONLY To be completed by ALL FIRMS OR INDIVIDUALS PROPOSING TO DO BUSINESS WITH THE UNIVERSITY OF CALIFORNIA (regardless of commodity, service, or product offered.)

COMPANY NAME:

     CONTACT PERSON: (Indicate Ms., Mr., etc.)     

STREET ADDRESS:

     MAILING ADDRESS (if different from street address):

     TELEPHONE NO.: (      )       TOLL FREE NO.: (       )       FAX NO.: (      )      

E-MAIL:       HOME PAGE ADDRESS:      

Are any of the owners or owners’ relatives currently employed by the University of California? YES NO If yes, please provide details on an attached sheet of paper.FEDERAL IDENTIFICATION NO. OR SOCIAL SECURITY NUMBER:

      (Optional at proposal stage, but must be provided before contract is awarded)

DUN & BRADSTREET NUMBER:     

PRIMARY TYPE OF BUSINESS: BROKER DEALER DISTRIBUTOR FABRICATOR MANUFACTURER MANUFACTURERS AGENT RETAIL SERVICE WHOLESALER OTHER      

PRINCIPAL OWNER(S) NAME: Title Sex(M or F) Ethnicity

PercentOwnership

                             %

                             %

THIS IS A PARENT COMPANY: (Name of subsidiaries)

     THIS IS A SUBSIDIARY: (Name and location of parent company)     

NUMBER OF YEARS

IN BUSINESS     

AVERAGE ANNUAL SALES

(PRIOR 3 YEARS)     

NET WORTH OF BUSINESS

     

NORMAL INVENTORY

VALUE     

APPROXIMATE SIZE OF

FACILITIES (sq.ft.)     

NUMBER OF EMPLOYEES

     DESCRIPTION OF PRODUCTS & SERVICES (attach sales literature as appropriate)

     

BANK REFERENCE NAME: ADDRESS: (Number, City, State, Zip)

           CUSTOMER REFERENCES:

Name Address Phone Number

                 

                 PERSON(S) AUTHORIZED TO COMMIT YOUR FIRM TO A CONTRACT:Name       Title       Name       Title      

Name       Title       Name       Title      INSURANCE: Is your Company Insured? YES NOTYPE OF INSURANCE: General Liability Automobile Liability Worker’s Compensation Other      Name of Insurance Provider/Producer     

Companies Affording Coverage:      GSA SF 254 A/E or related services questionnaire may be requiredOWNERSHIP OF BUSINESS: (Check One) Corporation Individual/Sole Proprietorship Joint Venture Partnership Foreign Ownership Not for Profit Other      STATE OF INCORPORATION: CORPORATE REGISTRATION NUMBER:            CORPORATE STATUS:      

45

RFP #0630 SMC

RFP EXHIBIT ECONFLICT OF INTEREST CERTIFICATION

1. The Bidder certifies that none of its officers or employees is:

a. An individual who is presently employed by the University or whose separation from the University occurred within two years of the date of the proposed transaction.

b. A spouse, child, parent, brother, sister, son-in-law, daughter-in-law, father-in-law, mother-in-law, brother-in-law, sister-in-law, or step-relative to an individual who is presently employed by the University or whose separation from the University occurred within two years of the date of the proposed transaction.

2. The Bidder agrees that if it is awarded the resultant contract under this RFP, it will not hire any officer or employee of the University to perform any service covered by this RFP. If the work is to be performed in connection with a Federal contract or grant, the Bidder will not hire any employee of the United States government to perform any service covered by the resultant contract.

3. The Bidder affirms that there exists no actual or potential conflict between the Bidder’s family, business, or financial interests and the services provided under this RFP, and in the event of change in either private interests or service under the resultant contract issued pursuant to this RFP, it will raise any question with the University regarding possible conflict of interest which may rise as a result of such change.

4. The Bidder agrees that if it is awarded the resultant contract under this RFP, it shall not be in a reporting relationship to a University employee who is a near relative, nor shall the near relative be in a decision-making position with respect to the Bidder.

Name of Bidder: ________________________________

Signed: ________________________________________

Print Name: _____________________________________

Title: __________________________________________

Date: _________________________________________

46

RFP EXHIBIT F

Bidder’s Customer Reference Form

RFP#0630SMC:      

Bidder:      

Please provide the following information for 3 of your customers whom we may contact as references for the services to be performed under this RFP:

1. Company Name:       Phone:      

Company Address:      

Contact Person name and title:      

Summarize type of job and technical specifications:      

Date and Length of Contract:      

2. Company Name:       Phone:      

Company Address:      

Contact Person name and title:      

Summarize type of job and technical specifications:      

Date and Length of Contract:      

3. Company Name:       Phone:      

Company Address:      

Contact Person name and title:      

Summarize type of job and technical specifications:      

Date and Length of Contract:      

47

EXHIBIT G: BIDDER’S FUNCTIONAL AND TECHNICAL SPECIFICATIONS

48

EXHIBIT H: MANDATORY PRICE SHEET

See attached excel worksheet.

49

Appendix B - EXISTING SYSTEM DESCRIPTION

Although the following sections are described as “modules”, this designation is for functional and documentation purposes only.

For each module, the following descriptors are noted when applicable:

Classification (subsystem, module, class, package, function, file, etc) Definition (specific purpose) Responsibilities (what does this component do?) Constraints (limitations, rules, preconditions, etc) Composition (description of use) Users/Interactions (what other components use it) Resources (possible race conditions, deadlocks, memory, processors, printers, dbs, etc) Processing (special rules, handling of exceptions, algorithms in existence, etc.) Interface/Exports

Some screens and reports are marked by simpler “Who” and “Where” descriptors.

Note the existing database structures in the Appendix along with examples of major reports.

For this section, descriptions are listed first, followed by the relevant screen shots.

1 Absences

Student attendance is a high-priority item for ELI, as immigration status and certificate eligibility can only be maintained through documented attendance. This section of the database manages student absences through instructor data entry and ELI office staff reporting. Students that do not maintain minimum attendance hours in accordance with U.S. Immigration and ELI rules are subject to expulsion and cancellation of their visa. Attendance is tracked by ELI and student status is ultimately reported to US Immigration via SEVIS, a web-based government database required by U.S. law.

The ELI application allows for Absence Entry by Class, Attendance Entry by Student, and Attendance Reporting.

Who: Instructors are responsible for entering attendance information each week directly into the application. Instructors must be proactive in recording attendance, even if no absences were recorded. ELI Staff generate exception reports to determine which students have been absent and which courses lack current attendance information. Students are issued a series of warning letters if their attendance starts to drop. Absences are also entered by staff for students who arrive late to start their program. Staff monitors instructors’ weekly absence data entry to ensure timely performance of this duty.

Where: “Enter Weekly Absence by Class” – this is a misnomer as all attendance must be entered, not just exceptions or absences.

Classification: module Definition: stores attendance information for each student / class / week. Notes hours of absence and

generates warnings for absent students Responsibilities: Instructors must enter weekly attendance for all classes

50

Constraints: stated in full hours (but not rounded in the db) Composition: used by instructors and Student Advisor Users/Interactions: interacts with several reports, letters, and student status. Used by Immigration Advisor

to report immigration status to US Immigration. Resources: used in printed reports. Processing: Student Advisors work with students to warn them when attendance is in danger of causing

eligibility problems. Interface/Exports: see screen shots

Figure 1: Instructors enter weekly attendance for each class. Absences are recorded in hours according to ELI guidelines.

Group Reports:1. Single Class Attendance Summary: used to review attendance by class

2. Non-Posted Attendance Report: alerts which courses are missing attendance information. This information is used to remind instructors to enter student hours.

3. Attendance Letters: These warning letters are sent to students in danger of losing eligibility due to excessive absences. ELI staff generates these letters in batches for distribution to students:

4. Warning 15. Warning 26. Warning 37. Termination8. Custom

Single Student Reports:

51

9. Weekly Attendance Summary: used to review attendance for a single student.10. Detailed Attendance Report – not currently used

2 AccountingThe accounting module is used by the ELI Business Manager to record student fees, agency commissions, and to reconcile with payments made to the Cashier and logged in ISIS.

Student balances and amounts due are calculated at the time of application. Once students arrive for the program, payments are normally completed during the first week of the program. Students pay by check, cash, wire, or credit card. Check payments are logged into the ELI database and brought to the Cashier for processing. Each student is entered into ISIS by the cashier and assigned a PID. Payments and balances are kept in ISIS with detail stored in the ELI database.

Credit card payments are tracked with paper receipts sent to the Cashier. When a credit card payment processes successfully, the receipt is carried back to the ELI Business Manager for entry into the ELI database.

Many ELI students are referred to UCSD through an student referral agency. Agencies receive commissions for sending students to ELI. Agency students paying ELI/UCSD directly cause a commission to be sent back to the Agency.

The ELI Business Manager uses the application database to calculate the commission amounts due to each agency and generates Invoices “from” each agency. These statements are used to generate payments to each agency through the disbursements office.

Classification: moduleDefinition: student payments, allocations, agency invoices and payments.Responsibilities: used by the ELI Business ManagerConstraints: Credit Card payments are processed by Cashier before entry into ELI. All payments go through the cashier.Resources: used in printed reports.Processing: Reconciliation is done via a paper trail between Cashier and ELI.Interface/Exports: ISIS remains the database of record for payments, with detailed information stored in the ELI application. See screen shots. Future version will likely use a third-party accounting tool to integrate into the ELI system rather than develop accounting functions from scratch.

The Accounting module uses a single ledger system to track student balances and payments. Most data is contained in a single table (ldgAR) than can be summed to provide balances.

As new and continuing students are registered and assigned to programs, balances and fees are recorded. All payments are handled by the cashier’s office. The business manager applies these payments to students in batches by agency or individually by student. It is important to note that the accounting system must be able to handle the fact that sometimes ELI receives payments from students directly, and sometimes a single agency payment will apply to several students. There are also various tuition-due amounts based on discounts, scholarships, and other adjusting factors.

52

2.1 Accounting Reports

Figure 2: Generate general accounting reports.

Figure 3: Generate general accounting reports.

53

2.2 Agency Fee Request Letter

Figure 4: Fee requests based on Agency. Used to generate commission statement for each agency to facilitate payments to agency. Post Request will log the amount into ldgAR.

2.3 Agency Fee Posting

Figure 5: Fees displayed by Student. Posted amounts will generate payments to agencies. UCSD PO numbers are recorded in the “Chk No” field. Generates commission paid entry to individual student account.

54

2.4 Create Agency Invoices

Figure 6: There is a difference between the “commission statement” and the “agency invoice”. This form is used to generate an invoice to the agency for them to make a payment to UCSD/ELI. Both net and gross invoices can be generated from this form.

2.5 Agency Payments for Students

Agencies often make payments for several students at once. The business manager uses this screen to apply these payments in a batch to students associate with a specific agency/program. The future version of ELIIMS must be designed to allow similar batch payment processing in an easy manner.

Figure 7: Showing payments in groups. Used to batch process payments from agencies.

2.6 Accounts Receivable Transactions

For single-student payments, the following screen is used. As payments are received, a transaction is logged into the A/R ledger. A/R transactions can be one of four types: payment, refund, charges, or adjustments. Each transaction will debit or credit the student’s balance.

55

For reporting purposes accounting summaries can be generated by several different date ranges, include “quarter”.

Payments leave a paper trail, where the student makes a payment by check or credit card (or other method) using a payment slip provided by ELI. Payments slips are stamped by the cashier office and returned to ELI by the student as proof of payment and for recording into the ELI database.

Figure 8: All accounts receivable for selected student.

3 Classes

The core functions of ELI’s database revolve around course setup and student placement. Unlike Extension, where a student signs up for a class or group of classes in a self-directed manner, ELI student schedules are highly organized. Students are assigned a “Core” level through testing. Each student is then required to take a complete set of courses and electives appropriate to his or her Core level. Classes and schedules are assigned to the student, reviewed with the student, and careful attention is made to ensure that each student has a complete schedule.

When a Program is first created, classes and schedules are assigned using many of the screens in the Class section.

Core levels are assigned for new students through testing. Testing is described in more detail in section 10.14. Continuing and returning students are placed in Core levels through testing and by simply graduating to the next level upon successful completion of an earlier program.

The flowchart diagram in section 5 describing course creation is repeated below due to relevance:

56

Figure 9: Course creation process

3.1 Copy Class Schedules

The application allows for the copying of a current class schedule to a future program start date in order to facilitate data entry. Since many programs and classes are repeated for new Program Group and Start Dates, this process allows for creation of new schedules based on previous ones. Once classes are scheduled student may be assigned to them. Typically classes are scheduled 2-3 months in advance of a program start date. Program Starts are initially set up under the Maintenance section of the ELI database. See section 3.2 for details about the setup process of programs, groups, and courses.

Limitations:Not intended for Program Starts. Not appropriate for irregularly scheduled programs such as closed programs.

57

Who: Academic staff chooses from a list of scheduled classes and copy the desired classes to another program group by clicking and copying from the left side of the screen to the right:

1. Select All from prior quarter2. Copy Now to new quarter

Figure 10: Copy Class Schedules.

3.2 Schedule Classes by Program Group

This form allows the scheduling of a class in a Program Group.

Who: Administrators can add or modify schedule information based on Program Group and Start Date. Classes are scheduled according to room and instructor guidelines.

Where: Drop down lists to choose Program Group and Start Date, plus a list of Scheduled Classes.

58

Figure 11: Schedule Classes

The scheduling of classes takes place in two stages following the “copy class schedules” procedure:

Stage 1: Administrators first modify the list of sections (on the left) by adding or deleting so that only the active sections remain. Double-clicking on a section brings up the details for that class on the right-hand side.

Stage 2: Administrators are able to set class date, room number, start time, end time, and length of class, as well as the assign the instructor for each class. Clicking the alternate tab, Schedule Detail (see below), allows the updating of instructor and/or room number.

This process is done at two different times:1. During week 5 or 6 of the quarter, in order to produce the Elective Selection & Description forms for

continuing students. At this time, all rooms and instructors are entered as “TBA”, and a summary is saved.2. During week 0, the room and instructor information is added after all assignments have been made and before

the student schedules are printed. At this time, the details for the class are also created (Save Summary, then Create Details).

59

Figure 12: Schedule Detail tab. The right side of the screen allows for assignment of instructors and rooms.

3.3 Rosters and Room Scheduling

Following the schedule creation, rosters are created and printed in a variety of formats. Rosters are broken down into the following groups, which correspond to tabs in the existing program (see next figure).

Examples of each roster are included in the Appendix.

1. Class Rosters & Reports2. Program Rosters3. Program Group Rosters4. Start-Date Rosters & Room Scheduling

Class Rosters & Reports

Class information is formatted into many different reports. Samples are short and are shown here instead of in the Appendix.

60

Figure 13: Difference report options for Class Rosters.

Single Class RosterThis report details the roster for the selected class, including Class Name, Instructor, Room #, Time Slot, Student Count, Start Date and Section, as well as a list of the students’ names, Student #s, Gender, Country, Program, Core Level, and Status.

Figure 14: Single Class Roster Report

Extended RosterThis report shows students’ status across the entire period.

61

Figure 15: Extended Roster Report

4wk Test RosterThis report shows the test scores of the students in the selected class.

Figure 16: Class Placement Roster

Pre-Test RosterThis report shows the scores for the students in the selected class from the Pre-Test period.

Figure 17: Pre-Test Roster

62

Post-Test RosterThis report shows the scores for the students in the selected class for post-testing.

Figure 18: Post-Test Roster

Conv Leader Class RosterThis report shows the attendance of Conversation Leaders for any given week.

Figure 19: Conversation Leaders Class Roster

Grade ReportsThis report shows the Core Class, Instructor Name, and Time Slot of class. Cover page is shown below, please see

Appendix for complete report example with actual grades and instructor comments.

63

Figure 20: Grade Report

Single Class LabelsThis report generates labels for each student in the selected Class.

Figure 21: Single Class Labels

Attendance SummaryThis report documents the attendance of all students in the selected Class.

64

Figure 22: Class Attendance Summary

Program Rosters

The application generates several program-based rosters sorted by a variety of criteria (Student, Score, etc.). Reports are generated based on sorting criteria after a Program is chosen from drop down list. See the Appendix for examples.

a. Program Roster

Report includes Student #, Student name, Status, Core level, Country, Gender, and Agency Name (if applicable). These rosters should also include names of students admitted conditionally, with a flag indicating this status so we know who they are.

b. Pre-Test Roster

Report includes Start Date and Student Count. Listed then are: Name, Status, Sex, Program, Country, Last Quarter Score, Pre-Test information (L, S, W, Total, O, G, Core, and CALC), and Test Comments. c. Post-Test Roster

Report includes Name, Pre-Test results, Pot Test Auth. Post-Test results including the Next Core, and Post-Test Comments.

d. ID Cards (note that students must be paid in full to receive ID cards).

The db should flag a student’s name somehow in all screens when there are payment problems.

ID Card is generated singly and in batches to be printed on existing stock.

e. 4wk Class List Roster

65

Report includes Teach, Room #, Class, Section, and a list of all applicable students including Name, Gender, and Country.

f. 4wk / Closed Test Roster

Report consists of a Program Placement Roster with Start Date and a list of students including Name, Country, Gender, L, V, S, O, W, and Total.

Figure 23: Class Roster Reports screen.

Program Group Rosters

This tab provides reports for many statistics surrounding Program Group Rosters. First select Program Group, Start Date, and End Date. Choose one of the following reports:

a. Program Group Roster

Report includes Student Count, and listed are all applicable students including their Student #, Student Name, Status, Program, Country, Gender, and Agency Name (if applicable).

b. Class Rosters

Report includes Room #, Class Name, Time Slot, Instructor, Start Date, Section, and then a list of students including Student #, Name, Days of the Week, Gender, Country, Program, Core Level, and Status.

c. Faculty Advisor Roster

Report includes Faculty Advisor name, Student Count, Quarter Start, and all students including Student #, Name, Status Program, Country, Gender, Core Class, Room #, and Instructor.

Note that Faculty Advisors is not needed in the new version.

d. All Certificate Name Rosters – this roster should only be in grades/certificates section of the application.

66

Report includes Class Name, Room #, Instructor, Time Slot, Start Date, Section, Student Count, and all students to receive a certificate listed including Student #, Name, and Name as it should appear on Certificate.

e. No Show List

Report includes all “no shows” including missing student count, then listed by Class: Student #, Name, Status, Country, Gender, and Agency Name (if applicable).

f. Pending Applications

Report includes all pending applications for the Program Group selected between the dates selected. Included is student count, and then listed by Student #, Name, Status, Program, Country, Gender, and Agency Name (if applicable).

g. Conversation Leader Class Rosters

Report includes all Conv Leaders for the Program Group and Date range selected. Listed is Class Name, Room #, Time Slot, Instructor, Start Date, Section, and student information including Name, Dates, Phone #, and Email.

h. ID Cards

ID Cards are generated to be printed for all students within the chosen Program Group and Dates. ID Blanks can also be printed (these include no Student Name).

i. 10wk Program Group Pre-Test Roster by Level

This report shows rosters prior to completion of testing by assigned level.

j. 4wk / Closed Program Group Pre-Test Roster

This report is used in short term program groups to display rosters prior to testing.

k. Pre-test Roster – ALPHA

This is a report currently in development and can be disregarded.

l. Class Pre-Test Rostersm. Grade Reports – should only be in grades/certificates section of the application.n. Program Group Post-Test Roster

67

Figure 24: Program Group Roster Reports.

Start-Date Rosters & Room Scheduling

This form creates reports used for room scheduling.

a. Class Sizeb. 10w Students Without Required Courses (ELI is currently only using the Scheduling Exceptions report.)c. Core Level Rosterd. No Faculty Advisor (not needed in new version)

Room Availabilitye. Available Rooms Based on ELI classes and Eventsf. Room Schedule Based on ELI classes and Events

. Comment:

68

Figure 25: Room Availability reports. Note that Event Scheduling screens and reports have changed slightly compared to this screen shot – the developer should look at the recent changes list.

3.4 Book OrderingThis screen facilitates book orders with the UCSD Bookstore. Data is exported or printed for submission to the bookstore. Book orders are based on “PGS”, for “Program Group Start”. See an example of the resulting Book Order export in the Appendix.

Who: The administrator can select a group and find a book within that group, or add a new book to be ordered.

Where: There is a drop down list of Program Groups and then of Books within.

Figure 26: Book orders.

69

4 Conversation Leaders

Conversation Leaders are paid assistants, often UCSD undergrads, who assist an ELI Instructor by providing general English conversation sessions during a scheduled class. Conversation Leader attendance, course assignment, payment, and evaluations are tracked in the ELI database. Payments are considered to be stipends.

Conversation Leader payments are tracked in the application. These payments and balances, however, have nothing to do with student payments or the accounting module.

4.1 Conversation Leader Attendance EntryThis form measures Conversation Leader Attendance by Program Group, Start Date, CL Class, and Week Number.

Who: Instructors are responsible for entering attendance information each week directly into the application. Teachers must be proactive in recording attendance, even if all classes were attended regularly. A report exists to show failure to enter CL attendance by teachers.

Where: “Hours Attended” – A pull-down in increments of 0.5 from 0.0 to 4.0 hours.

Figure 27: Instructors enter weekly attendance for Conversation Leaders by Program Group and Start Date. Attendance is recorded in increments of thirty minutes.

Reports:

70

Figure 28: Leader Roster shows overall attendance for all Conversation Leaders in any specific CL Class. Report includes Class Name, Instructor, Room Number, Time Slot, and Section Letter.

71

Figure 29: Class Attendance shows overall attendance of Conversation Leaders by day. Report is sorted by Conversion Leader (per page) and displays total ‘hits’ for each week.

4.2 Conversation Leader Evaluation EntryThe ELI application measures Conversation Leader Evaluation by Program Group, Start Date, and CL Class.

Who: Instructors are responsible for entering evaluation information directly into the application. Evaluation is only needed once, at the end of the course.

Where: A series of checkboxes and comment fields where the instructor can “grade” the Conversation Leader.

72

Figure 30: The Instructor Grades each Conversation Leader in satisfaction. There is room for both comments intended for the Leader as well as private comments.

4.3 Conversation Leaders ClassesThis form displays all classes within a Program Group with a common Start Date.

Who: Administrators can add or delete CL Classes from the aforementioned Program Groups, as well as change Total CL Hours.

Where: A pull down to choose Program Group and Start Date, with additional options to differentiate between Assigned Classes and Unassigned Classes.

73

Figure 31: Conversation Leaders Classes classified by Program Group and Start Date. Add/Delete options in pull downs on the right-hand side.

4.4 CL Class Assignments By ClassThis form generates all relevant Conversation Leaders based on Program Group, Start Date, and CL Class.

Who: The CL Coordinator can view all Conversation Leaders alphabetically and either assign them to a specific class or delete them from the class.

Where: A pull down to choose Program Group, Start Date, and CL Class. All Conversation Leaders will be shown alphabetically with checkmarks in the Assigned category if applicable.

74

Figure 32:CL Class is selected based on Program Group and Start Date. Conversation Leaders are assigned to the selected Class by adding a checkmark.

4.5 CL Class Assignments By Conversation LeaderThis form displays classes sorted by Conversation Leader, Program Group, and Start Date. There is the ability to sort further by listing Classes as either Assigned or Unassigned.

Who: Instructors view all Conversation Leaders alphabetically and then choose Program Group and Start Date.

Where: A pull down to choose Conversation Leader and then select Program Group and Start Date in which to search. Resulting Classes are displayed in rows.

75

Figure 33: Only classes assigned to the selected Conversation Leader, in the selected Program Group and Start Date are displayed.

4.6 CL Task Assignments By Conversation LeaderThis screen retrieves all tasks associated with the selected Conversation Leader. Task Name, Start Date, End Date, and Notes are given in the results. Tasks count for hours toward the CL stipend, but are tracked as unique “events” instead of a regular class assignment.

Who: Instructors choose a Conversation Leader from an alphabetical drop down. Ability to sort by Date is also available.

Where: A pull down to choose Conversation Leader.

76

Figure 34: Instructors are able to see the entire history of any Conversation Leader.

4.7 Conversation Leader Reports

Conversation Leader Reports are used to summarize CL activity and to provide CL rosters, evaluations, and stipend payment information. Reports are grouped into the following categories represented by tabs in the current program.

1. Lists2. Attendance / Email3. Evaluations4. Accounting

Lists

This form generates reports including address lists, leader labels, stipend reports, assignments by class, and assignments by leader.

Who: Instructors can choose a variety of reports.

Where: A series or pull down menus and buttons, depending on what report is desired. The required fields are Program Group and Start Date. More options can be utilized to narrow the results of the report.

77

Figure 35: Lists Tab. Reports are generated by clicking the gray buttons.

Attendance / Email

This screen generates reports for Non-Posted Attendance, Attendance by Leader or Attendance by Class.

Who: Instructors can view Attendance by choosing a Program Group and a Start Date.

Where: There is a drop down menu for Program Group and Start Date, and buttons to generate the reports.

Figure 36: Attendance/Email Tab. Reports for Attendance are available in several formats, including by Leader and by Class

78

4.8 Evaluations

This screen generates reports based on Program Group, Start Date, Class, and Conversation Leader. Reports can be based off a single class and its Conversation Leader or be a summary of all evaluations of any one Conversation Leader, regardless of class.

Who: Instructors can view Evaluations by choosing a Program Group, a Start Date, and a Conversation Leader.

Where: There is a drop down menu for Program Group and Start Date, and buttons to generate the reports.

Reports:

1. Summary Evaluation Report2. Comments Evaluation Report3. Non-Posted Evaluations4. Single Evaluation5. Individual Summary of All Evaluations

Figure 37: Evaluations. Instructors can view evaluations for any Conversation Leader and have the option to narrow the results (to a single evaluation) by class.

Accounting

This form retrieves conversation leader payment and stipend data based on Start Date and End Date. The report is generated by Leader Name and shows the accounting balance for each leader.

Who: Accounting department can track which Leaders have been paid and which have outstanding balances.

Where: There is a drop down menu for Start Date and End Date.

79

Note that “index number” refers to a specific accounting dictated by campus and used for campus accounting purposes.

Figure 38: Accounting. Report shows Leaders, Assignments, Amount to Pay, and Pay Status.

5. Evaluations

Evaluations consist of two types: Program Evaluation and Instructor Evaluations. Both evaluations are submitted by students using Scantron forms. Results are weighted according to the rules detailed below.

5.1 Program Evaluations

Program Evaluations are submitted by students in order to give feedback on the ELI program as a whole. The Scrantron forms are scanned and a CSV file is created. The ELI application is used to upload evaluation files for review and report creation.

See the sample Scantron Program Evaluation form in the Appendix. Note that the 8 digit program evaluation code in the upper right portion of the Scantron form is generated in advance by the ELI program.

Figure 39: Input an evaluation. Clicking the button opens a stadard File dialog box for selecting the Scantron CSV file to import for Program Evaluations.

80

5.2 Generate Evaluation Reports (Instructors)

This form starts the Instructor Evaluation process. The user first selects from list of Classes. Select classes by clicking the appropriate checkbox to Create Evaluation Records. Evaluation Records must be created in advance so that the proper Scantron ID numbers are generated in advance. Note the following process:

10. ID numbers are generated by the ELI application. These numbers are used in the upper right corner of the Scrantron file to identify the Instructor Evaluation record in the database.

11. Labels are printed with the ID numbers and Instructor information. The labels are placed on envelopes with the blank Scantron forms for distribution to students.

12. The process is then continued after the evaluation forms have been filled out by students. (See next section.)

Who: Administrators can create evaluation records of any class from a specific Program Group, Start, and End Date.

Where: Drop down menus of Program Groups and Start and End Dates generate a list of applicable classes. Checkboxes can be selected to generate the Evaluation Records.

Click “Create Evaluation Records” to create record and ID number.

Figure 40: Select classes with checkboxes to create evaluation records.

5.3 Process Instructor Evaluation Scranton File

Once the Scantron forms have been scanned and turned into a CSV report, the scored are uploaded and saved to the database. The following process is used:

Evaluations are scanned and CSV file is createdClick Process Scranton File to open a dialog box to locate the file.

81

Figure 41: Process Instructor Evaluations

The results are displayed on screen.Save records by clicking “Save New Scores”Check the box “Erase previously saved scores for this batch” to replace any existing data. If this box is not checked then data is appended.

5.4 Instructor Evaluation Reports

Display reports of instructor evaluations by choosing the Program Group and Dates; By Class or by Instructor. See the Appendix for samples of the Evaluation labels and reports.

Figure 42: Retrieve classes by Class or Instructor to generate evaluation ids and labels.

82

Instructor evaluations are weighted according to number of hours taught for each class.

Note that the question about the Textbook is not included in the instructor evaluation and is reported separately in its own report.

6. Grades and Certificates

Grades are both letter and comments, and, for some classes, include a description of student performance based on pre-defined criteria and checkboxes. Upon successful completion of a certificate program, provided the student has not exceeded allowed absences and has passing grades, a certificate is issued.Enter

6.1. Detailed Grades by Class (Core)

The first step of the grading and certificate-issuing process is the entering of grades by Instructors. This form shows student assessment, including grades and positive and negative comments, for core classes.

The program should not allow this or any similar type of screen to be printed. Instructors should only be allowed to enter grades and only authorized admin staff can print such data.

Who: Administrators can view all available classes and the details for each including the positives and negatives of each student in the class.

Where: Double-click on the list of classes and a second list will appear containing students in the class selected. Double-click on the student and see their assessment.

Figure 43: Grade details on core classes consist of both letter grades and the positive/negative flags indicated here.

83

6.2. Enter Grades by Class (not Core)

Non-core classes consist of letter grades only. This screen shows student performance in non-core classes.

Limitations:Form should not be printable.

Who: Administrators can view and edit student assessment for non-core classes.

Where: Double-clicking a class in the list of non-core classes will bring up the list of students in that class with text fields to enter grades or comments.

Figure 44: Non-core class student assessments.

6.3. Enter Grades By Student

This form provides for the modification and creation of student “non-detailed” grades and remarks for every class attended. Note that the remarks can be entered from a pre-defined list accessible by double-clicking the notes area on the screen. The pre-defined remarks come from a simple lookup table.

Who: Instructors can search by name and review the history of a student’s assessment as well as modify their assessments.

Where: Clicking on Select Student button produces a search. Double-clicking the student’s name will pop open a comments form to add more comments from a pre-defined list.

The predefined list should be user-modifiable.

84

Figure 45: Student assessment for all classes taken thus far. The transferred out checkbox indicated that a student is no longer with the program and does not need a grade. A spell checker is desired.

6.4. Grade Reports & Certificates (Office Use Only)

At the end of a Program, students are given an envelope containing either their certificate and grade reports or a letter explaining why they did not receive a certificate. Grade reports are sent separately from letters and certificates. The process of generating these envelopes, certificates, and grade reports is accomplished in this section of the program.

The buttons to the left of the Grade Reports screen are used on Wednesday of Week 10 to show which Instructors need to enter grades. The CSC section at the bottom left is for a “Prestige Program” with a specially formatted certificate.

Prior to printing grades, administrators check to make sure there are: No unentered progress grades No unentered final grades No unentered student absences (see Attendance Reporting screens)

The program should allow for multiple certificate formats in a single UI.

85

Figure 46: Create certificates, custom certificates, or grade reports.

These screens allow a list of students to be generated into temp tables. The students are then selected for the creation of grade, label, or certificate reports. A certificate is not printed due to an F grade or too many unexcused absences. Instead, a letter of explanation is printed. A report of students who will not receive certificates is also printed by administrators.

86

Figure 47: Customization of certificates.

87

Figure 488: Sample certificate. Note that the program name in this screen shot is not correct and “10WACA Program” is a just a place-holder name – a ficticious program name.

7. Instructors

The Instructors section of the program allows for report generation of instructor schedules, student change notifications, and address and communication lists.

7.1. Instructor Reports

These reports generate lists of instructors in various formats. See the Appendix for samples.

1. Schedules2. Address Lists

Schedules

Generate instructor schedules by selecting Program Group and Start Date. Data from the “ALL Class Change Notifications” button is printed frequently by the administrative staff to show which students have changed classes. Students may change elective classes during the “Class change period,” early in the program term.

88

Class Change Notifications are printed daily during the class change period so instructors are aware of which students are leaving or entering their classes.

Figure 49: Reports by schedule. ALL Class Change Notification button printed daily.

Address Lists

Generate Instructor contact reports based on Program Group including:

A. Active Instructor Address ListThis is a list of all active instructors’ addresses.

B. Active Instructor Address LabelsThis generates a list of all active instructors and their addresses to be printed in label form.

C. Substitute ListThis is a list of all substitutes and contact information.

D. All Instructors Address ListThis shows all Instructors and their Addresses, regardless if they are active.

E. Tutoring ListThis is a list of all tutors and contact information

89

Figure 490: Instructor Address Reports.

7.2. Instructor Attendance Entry

This module is designed to monitor compliance with absence policies; these policies differ for by-agreement (part-time) and full-time instructors.

Figure 501: View and edit attendance for specified instructor.

7.3. Instructor Attendance Report

Generate a report of Instructor hours based on quarter or year.

90

Figure 512: Output all instructor hours per selected quarter.

8. Maintenance

The Maintenance section of the current application is used for a variety of configuration tasks. The set up of catalogs, courses, programs, dates, users, and various lookup tables comprise the majority of maintenance functions.

The next version of the application should distinguish between configuration tasks and ongoing setup tasks for program-related activities. System maintenance functions, for example, should be separate from course and program maintenance procedures.

8.1. Restore the Cursor

This feature is unique to the current Access application and is not relevant to the new application.

8.2. Add Users and Groups, Assign Permissions

Users must login and authenticate in order to access the application. The current system allows for a fine level of control, down to the button or field level.

1. Users

Assign Security Information for any given User.

91

Figure 523: Edit password, campus, and groups for selected User.

2. Groups

Groups are used for role-based security. Generate reports of who is in any selected Group. Manage groups by adding/deleting.

Figure 534: Permissions are granted for each use for each form.

3. Logs

This report shows access activity by time and user.

92

Figure 545: Log file.

8.3. Utilities: Student numbers and deletions

This highly restricted form allows for the deletion of any student, as well as changing student numbers and status. This screen is restricted due to its power; one wrong click and a student’s complete records could be erased, or the student could even be erased from the database completely.

The most common use for this form is the “Change Student Status” button. For example, sometimes a Student Number is already being used on campus and must be changed.

Figure 556: Student database access and editing. Highly restricted access since crucial data can be deleted.

93

8.4. Master Maintenance

This application is an administrative ‘master’ tool that allows for the editing of maintenance data and lookup tables in the database.

Figure 567: Master Editor for all lookup and setup data. From this area, the db administrators enter data that is used throughout the application. The maintenance forms listed have user-defined rights. Shown here is the agency screen.

Agencies Books Catalogs Before 2004 Catalogs Beg. In 2004 Citizenship Conv. Leaders Conv. Leaders Pay Rates Countries Courses Edit Menus Holidays Instructors Languages Leads Media File Orientation Rooms Payment Methods

94

Program Group Start Dates

Figure 578: Program group start-dates.

Program Groups

95

Figure 59: Program groups and related fields. This information must be updated every quarter with current dates (for the 10-week program).

Program Start Dates

96

Figure 580: Modified ~once a year when prices and brochures are finalized.

Program Tests

97

Figure 591: Summary of program tests.

Programs

98

Figure 602: Program, course, and catalog information is managed here.

Publishers Quarters Rooms Setup Message Tests Time Slot Print Groups Time Slots

9. MarketingThe ELI Marketing Department carries out a wide variety of tasks. The current application is used in a limited fashion to generate some key reports; however many other marketing tasks are completed entirely offline.

9.1. Marketing ReportsThese reports are hard-coded into the current system.. Report groups include:

Agent Reports ELI Reports CPI Reports

Agent Reports

Agent Productivity Report

99

This report shows the rankings of agents. It is ranked based on the number of student weeks, with the most weeks being the most highly ranked.

Agent Productivity Ranking By CountryThis report shows the rankings of agents based on the number of students from any given country, with the most students from any one country being the most highly ranked.

Agent Contact Info by CountryThis report lists all agents and their contact info by country.

List of Students by AgentThis report lists students, grouped by agent.

Activity ReportThis report shows all activity from a start date to an end date sorted by country.

ELI Reports

ELI Enrollments by Country / ProductivityThis report shows enrollments by country and program group from a start date to an end date. It shows how many students (by country) were enrolled during that time, as well as a percentage of students (by country) in the program to attend.

ELI Enrollments by Country / RegionThis report shows enrollments by country and program group, sorted by continent and country. It also shows what percentage of students comes from each region.

TEFLThis report shows enrollments by country and program group.

TEFL by RegionThis report shows enrollments by country and program group, sorted by continent and country.

10-Week EnrollmentsThis report shows enrollments by country and program group for the 10-Week Enrollment programs. It is listed by continent and country.

4-Week EnrollmentsThis report shows enrollments by country and program group for the 4-Week Enrollment programs. It is listed by continent and country.

CPI Reports

CPI Reports are used to track data for professional certificate programs.

Bus. Enroll by Country / ProductivityThis report shows enrollments by country and program group in relation to business sectors such as Finance, MBA, or CM.

Bus. Enroll by Country / RegionThis report shows enrollment by country and program group in relation to business, sorted by continent and then country.

100

Summary Reports

1. Student Weeks by NationalityThis report lists how many weeks students attend from each country. This can include full or part-time students.

2. Students by NationalityThis report lists countries and simply states how many students from those countries are in attendance. This can include full or part-time students.

Incentive Program

This section manages programs to encourage agent productivity: Cash bonuses and scholarships (reduced-fee or tuition-free enrollments) are awarded based on the number of students coming through the agency. Agent productivity is measure through a calculation of “student weeks.”

Figure 613: Marketing Reports categorized by Agent, ELI or CPI, plus Summary Reports.

10. Media File

ELI maintains a set of books, videos, and other media materials available for check-out by instructors. The system works similar to a library, with checkouts, due dates, and related tracking information. While there are several

101

screens and reports involved in Media File tracking, the system is straightforward and allows for easy management and review of ELI’s Media Library. Some media is assigned specifically to certain courses or course types.

10.1. File: For Instructors

1. Media Items2. Media Checkouts3. Media Classes4. Checkout Request Form

10.1.1. Media Items

This application shows the available media. It can be sorted by Type (CD, Book, etc.) and Content (Business, Computers, etc.).

Who: Instructors can view how many copies are available of any particular media.

Where: Choose from drop down lists to choose the Library, Media Type and Content.

Figure 624: Media is listed in rows.

10.1.2. Media Checkouts

This application shows what media is checked out by which Instructor, or which items are checked out in general.

Who: Instructors can view what items are checked out.

102

Where: Drop down choices of Instructors or Media Items depending on the kind of search.

Figure 635: Search for media by Instructor or by Item.

10.1.3. Media Classes

This application allows searches for media based on class name.

Who: Instructors can look up what classes use what media.

Where: There is a drop down list of class names.

103

Figure 646: Choose Class to show applicable media (if any).

10.1.4. Checkout Request Form

This application shows all copies of media available, with checkboxes.

Who: Instructors can check off the media they want to check out, and print the form to bring to Program Support.

Where: There are checkboxes down the right side at which to click to check out.

104

Figure 657: List of all media available for check out.

10.2. Media File Management: For Office Use Only

1. Checkout2. Classes3. Reports4. Item Queries5. Checkout Queries6. Checkout Receipts

1. Checkout

This application allows the administrator to see the status of any media including number of copies available, due date, and who has it checked out. Administrator can also add new checkouts.

105

Figure 668: Media Item details.

2. Classes

This form allows the administrator to see what classes use which media.

Who: Administrators can select media from a drop down list and assign or view classes using that media.

Where: A drop down list of media items for a particular course or class.

Figure 69: Classes using the selected media.

3. ReportsMedia Checkouts by TitleA report is generated with all of the media titles currently checked out.

Media Checkout List by InstructorA report is generated with all of the Instructors who currently have media checked out, as well as the media they have checked out.

106

Media Checkouts for InstructorsThis report lists all of the items checked out for an Instructor.

Media Checkout RemindersThis report details reminders for all media checkouts from a start date to an end date.

Media Past Due by InstructorThis report lists every past due media item, organized by Instructor.

Media Past Due for InstructorsThis report lists the past due media items for an Instructor.

Media by ClassThis report shows the ID, Title, and Media Type sorted by class name.

Inventory ReportThis report details all of the media available, how many copies, and if it is in stock.

Figure 670: Media Checkout Reports.

1. Item Queries

This form shows details for all of the media.

107

Figure 681: Media Details.

2. Checkout Queries

This form allows the administrator to search Checkouts by Instructor or by Item.

108

Figure 692: Checkout items sorted by Instructor or Item Name.

3. Checkout Receipts

This application shows all receipts for past checkouts. Administrators can sort by date or by Instructor.

Figure 703: Receipts for checkouts by Date or Instructor.11. Registration

This section details the registration process from obtaining leads to student scheduling.

11.1. Enter/Edit Inquiries

109

The leads/inquiries section of the application is seldom used due to understaffing, but is still very desirable.

This screen allows users to add or edit a lead. Information on referral and number of brochures sent, as well as complete contact information.

Figure 714: Lead contact information. Rarely used, but still desirable.

11.2. Student Registration and Enrollment

This section outlines student data including scheduling and personal information. This screen is highly used and the status of a student’s registration can be quickly reviewed and changed from here. Note that student status is progressive, with enrollment history kept. See the student registration flow chart for additional process information.

110

Figure 725: Details of a specific student enrollment. This screen is highly used. Double-click a registration entry to see the program registration screen (next Figure).

Figure 736: Register for a Program. This screen is highly used for processing new registrations.

11.3. Enrollment Reports (including Leads)

111

This section contains reports for a variety of enrollment data. Tabs include:

1. By Start date2. Between Dates3. Registration Dates4. Program Group5. Program6. Leads

1. By Start date

Generate several reports including Incomplete Applications, Arrival Report, Class Size, Insurance Coverage Report, Transfer Students, and Missing Field Trip Form. See the Appendix for sample output.

Figure 747: Reports by Start date. See Appendix for sample output.

2. Between Dates

Reports are available for Housing, Withdrawal, and Enrollment between session dates. This information is reviewed frequently during a quarter.

Figure 758: Reports between sessions. Used by admin staff to review weekly enrollment numbers.

3. Registration Dates

112

These reports are to outline students enrolled for a selected term. There is also the option of viewing acceptance letters, file covers, and labels.

This screen is highly used by ELI to process new students. Acceptance Letter, File Covers, and File labels are all generated by this screen.

Figure 79: Registration during a specified period of time.

4. Program Group

113

This application generates reports based on Program Group. Available reports include SEVIS Students. SEVIS, or “Student and Exchange Visitor Information System”, is a government data-entry web site used by ELI as part of the Homeland Security requirements), Country Breakdown, Registration NOT Completed, Students With Passport, OPT Students, and Insurance Coverage Reports. See Appendix for sample output.

Figure 760: Enrollment Reports by Program Group.

5. Program

This section offers reports based on Program.

Figure 771: Reports based on Program enrollment. See Appendix for sample output.

12. Single Student DataThis section of the application allows for detailed student management. It is most often used after the initial bulk registration process and in instances when student records are individually managed, as during the class change period.

114

12.1. Single Student Reports

Search by student name to generate a page with Grade Report, Student Schedule, and Elective Selection Worksheet. This screen is rarely used since the same data is available from other screens.

Figure 782: List of reports available for each student. This screen is rarely used as the same data is available from other screens. It is not needed in the application.

12.2. Student Academics

1. Testing and Placement2. Scheduling/Grades3. Attendance

1. Testing and Placement

Search by student name to generate a page with Test information such as test type, test name, raw score and date taken.

Who: Administrators can assign tests for any student.

Where: Searching by name in a text field produces a list of students sharing the name. The desired student is double-clicked and the resulting page appears with a choice of different actions.

Assign Core Level Assign Secondary tests Assign Classes Assign a Test

115

Figure 793: Details of student test taking with the option to change results. Used as an alternative to the batch assignment process. Note that the Total Weighted Placement Score is a cumulative score for new students that have taken ALL tests, and is artificially low (and ignored) for continuing or returning students that have only taken some tests.

2. Scheduling/Grades

This report shows the student’s schedule and grades for each class.

Who: Administrators can view or modify students’ schedules and view students’ grades. Note that grades cannot (and should not) be changed from this screen.

Where: There is a table of the student’s schedule with Class Name, Grade, Time Slot, Instructor, and Date.

The history of add/drop action and dates must be preserved, as shown on the following screen (fig 90).

116

Figure 84: A table shows the schedule and grades for each class. This form is used to process student adds/drops on an individual basis. Note that add/drop history must be maintained.

Reports:

1. Student Change Notification – duplicate of the student schedule – used when a student needs to prove to the Bookstore that they’ve dropped a course in order to obtain a refund.

2. Instructor Notification Pop Up – can be printed here, but is normally printed as a daily batch3. Grade Report – rarely used here since grades are processed elsewhere. It is used when a grade must be

printed for an individual student.4. Student Schedule – report that is given to the student showing their new class schedule.

3. Attendance

This report shows the student’s current and former classes for a given program start date.

117

Figure 805: Student's Current and Former Classes. The area on the left is never used. The area on the right is used by administrators to indicate total program absence hours when a student arrived late to the program.

13. Student SchedulingThese screens are used during the first week of a program to manage the initial registration of students.

Note that the term “Assigned” indicated that a student has been marked as requiring a course or is assigned to a Core level. The term “Scheduled” means that an assigned student has been placed into an actual course section with a time slot.

The following screens are used to assign students to their Core levels and their required courses in a step-by-step fashion:

Core Levels are assigned Students requiring additional testing are moved to Hold until their tests are scored and final Core Levels are

assigned. Core Courses are Assigned Required Courses are Assigned Students are placed/scheduled into sections for their elective courses.

13.1. Schedule Reports

Programs are displayed after selecting a Program Group. Reports are then generated based on desired information. Many reports are used to track the progress of the registration process. These screens are also used throughout the program to generate reports of significant student changes.

The schedules and master schedule reports are of particular importance. See examples in the Appendix.

Who: Administrators can generate many reports for each Program.

118

Where: Numerous buttons generate different reports.

Reports:

1. Full Schedule Report2. Full Schedule Report with Size3. Orientation Room4. Student Scheduling Exceptions5. Core Levels Roster6. Empty Classes7. Withdrawn/Dismissed8. Course Offerings by Program9. Student Schedules10. Student-Master Schedules

Figure 816: Many types of reports can be generated.

Student Schedules that ELI prints to distribute to students are the Student-Master Schedules (#10 above). These are printed in four batches:

1. New lower-level students2. New upper-level students3. Continuing lower-level students4. Continuing upper-level students

13.2. Assign Core Levels

Select a Program and its Core Levels will be displayed.

Who: Administrators can view or modify Core Levels and Assign 2nd Day Tests or the Next Core Level.

Where: There is a drop down list of Programs which generate a list of Processed Students.

119

Figure 827: A list of processed students and their Core Levels.

13.3. Change Core Level to HOLD

This feature temporarily changes the core level to a placeholder status for intermediate students pending additional oral and grammar testing for final core placement.

Who: Administrators can regulate the intermediate students based on scoring.

Where: There is a drop down list of Programs, labeled as Program Group.

Figure 88: Move a Program Group to Hold.

13.4. Assign Core / Required Courses

After Core Levels are assigned, required courses are assigned in a batch process.

120

Core Levels are assigned based on Test results. Instructors use this screen to Select Program and Sort by Alpha Only or Test Score / Alpha and choose Core Level. Assign and Schedule Core & Required Classes and a list of Processed Students will be displayed. Assignment steps are as follows:

1. Assign Core Level (previous screen)2. Assign Course Level (this screen)

Who: Administrators can view and modify core assignment.

Where: There is a drop down list of Programs, a radio button choice of Sort Options, and a text area listing Core Level.

Figure 89: Processed students assigned to selected core.

13.5. Assign Class Sections

This application allows Administrators to assign students to Class Sections or view all students within a certain Class.

Who: Administrators can view students in specific classes and modify section assignment. Clicking the Retrieve Student Records button generates a list of all applicable students.

Where: There is a drop down list of Programs, a choice of Core, Required, or Elective, and a drop down list of all of the classes.

The startdate/section drop downs of “A” and “B” sections are done manually by the Instructor or Administrator in order to distribute students into different sections of the same course at the beginning of the program.

121

Figure 830: List of all students within the designated class. Assignments are performed by an Instructor with a batch of students.

13.6. Process Continuing Students

This feature is used after the end of the previous quarter. There are four steps in this process:

1. Get Post Test2. Assign Core Level3. Assign Core Courses4. Assign Required Courses

Who: Administrators will select Program Group and NEXT Quarter Start Date. Then the buttons for the four steps will be clicked in sequential order.

Where: There is a drop down list of Programs and Start Dates. There are four buttons for each of the four steps.

122

Figure 841: At the end of the quarter, administrators can assign continuing students' future required courses. Elective courses are entered in the individual Student Academics screen.

13.7. Single Student Scheduling (Non-graphical)

Please see section 7.4.

13.8. Single Student Scheduling (Graphical) – PLACEMENT WK ONLY

The graphical schedule screen is used by instructors to ensure that students have a complete and proper schedule. The pop-up form shows a color-coded version of the various student schedule statuses. The color coding system is useful when first assigning a student’s schedule in order to make sure the proper time slots are filled and to ensure that the student will meet program requirements in order to successfully complete the program and obtain a certificate.

Limitations: It is not possible to add a class or assign a core class in this application. This form is not recommended for splitting sections.

Who: Instructors can see if any courses or time slots are missing or unassigned based on color.

Figure 852: Color Legend

Where: There is a table of the student’s schedule with the option to add a date to the existing classes.

123

Figure 863: Color-coded version of schedule. Used by Instructors to ensure that each student has a full schedule without conflicts.

13.9. Elective Selection Reports

Elective selection is done mid-quarter for the following quarter during an Instructor-led “advising process” with each student. The following screen is used for the elective preparation process. Student elective sheets and descriptions are pre-printed using different paper colors for electives for each level.

Students select electives by meeting with an Instructor and reviewing pre-printed program-specific elective selection forms.

Who: Administrators can view electives based on Program Group, Program, and Start Date.

Where: There is a drop down list of Program Groups, Programs, and Start Dates. Clicking Generate Data will show all relevant elective classes.

The Additional Courses reports are printed for both Lower Levels and Upper Levels and are used to show students in the Communication & Culture program the additional courses for their level that are available to be purchased at an additional cost.

124

Figure 874: Elective selection data generation application and additional courses-for-purchase reports.

14. TestingThe testing process is used for placement of students into classes. Test score entry is done in bulk during Week 0 for new students and during weeks 9 and 10 for continuing students.

14.1. Enter Placement Test Scores

This application allows for test score entries sorted by Program or Group, and by Test. Each student who took the test will be displayed with an area to view or edit scores. Scantron results are typed into the system by Instructors or Administrators.

Who: Instructors and Administrators can update test scores for students, organized by class.

Where: A drop down of Program Groups and then Test name and Start Date will produce a list of applicable students.

Figure 885: Student list based on test taken.

125

Reports:

Report of Ungraded Test Scores is available.

14.2. Post Test Authorization

Post Tests are given to continuing students interested in enrolling in another Program. While most students continue on to the next Core level, in some cases a student may “double jump” by taking the appropriate post tests and scoring high enough.

ELI limits the number of students allowed to double jump by requiring an Instructor recommendation for students interested in double-jumping. Post tests must be scored and require a significant amount of time and overhead, so students must be authorized to take all post-tests. Instructors record comments with the post test authorizations.

Continuing students take the listening tests only, and have to get special permission to take other tests. Students going into some levels (105-108) will take grammar and/or oral tests.

This application allows for the authorization of students for Post Testing by Administrators. Instructors recommend students for post-testing using a paper form. Students that test intermediate are placed in a “hold group” for more testing. Only continuing students take post tests at the end of the program.

Who: Instructors can recommend authorization for students by clicking the checkbox in front of their name and assign them to take the test.

Where: A drop down list for Program Group and Start Date generates a list of students in rows.

Figure 896: Checkboxes indicate which students are authorized to take post tests. A check means the student is authorized for additional tests and may possibly double-jump a Core level.

Reports:

A Post Test Authorization List is available for continuing students. A letter is sent to tell them the test details (date, time, etc.). (If they are authorized, it means that they are able to take the test.)

126

14.3. Enter Post Test Scores / Comments by Core Class

This application allows entry of student test scores, as well as comments on expectations of future placement by the Core teacher.

Who: Administrators can access or input student test scores and Instructors can enter comments by choosing the class they want to update.

Where: A list of classes, able to be sorted by Program Group, Test, and Test Date.

Instructors do not enter post-test scores. This is done by Administrators only. The only test scores Instructors assist with entering are the placement scores at the beginning of the quarter.

Figure 907: Students’ test scores and comments are displayed based on class and test selected.

14.4. Enter Post Test Scores by Alpha

This application allows for the input of test scores sorted alphabetically by student name.

Who: Administrators perform the data entry and can access or add student test scores by viewing all students alphabetically.

Where: A list of all students and test scores and dates is generated after Program Group, Start Date, and Test name are selected.

127

Figure 98: Alphabetical list of students and test results. Used for data entry, assignment, and review.

14.5. Administrative Test Reports (Office Only)

This section consists of several report options, including the ability to run a test report for any class and batch the test score report by class, sorted by program group and class time.

These reports are used with the authorizations that define when and where

1. 0 or Non-Scored Pre-Test

Clicking this button will generate a list of all students who were scored a 0 or were not scored in the Pre-Test.

2. 0 or Non-Scored Post-Test

Clicking this button will generate a list of all students who were scored a 0 or were not scored in the Post-Test.

3. Test Scores By Program Group

Clicking this button generates a Program Group Post-Test Roster.

4. Post Test Authorization List

Clicking this button generates a list of students who are authorized to take a post test.

5. Post Test Authorization Letters

Select students with checkboxes to generate the report:

128

Figure 99: Four report options on the left. On the right, students are added with checkmarks to receive a letter stating they have been assigned to a test. Administrators must update the post-test dates, times, and locations prior to the tests first before these letters can be printed.

14.6. Late Test Scoring

This screen is rarely used and was designed to process a smaller batch of students “outside” of the normal batch processes. These smaller batches exist for various reasons (late arrival, etc.), however the students are usually processed individually.

Figure 910: Late Test Scoring. ELI does not use this screen for 10-week programs, but always the individual student’s screen.

129

15. VendorsTracking of ELI Vendors is seldom used. This feature is a low-priority item and may be eliminated. Current screens are documented below with minimal comment.

15.1. Vendors

This application allows the input for adding a new vendor.

Figure 921: Add a new vendor.

15.2. Vendor Events

This application shows the details for past Vendor Events. Vendor usage is sometimes limited to a short timeframe marked by a specific event.

Who: Administrators can view vendors or add new vendors.

Where: Several fields to display information about thank you notes, invitations, etc.

130

Figure 932: Details for Vendor Event.

15.3. Vendor Sponsorship Entry

This application allows the addition of vendors to an event based on sponsorship opportunity and price.

Who: Administrators can add new vendors to an event and choose what sponsorship opportunity they want (1/2 page ad, business cards, etc.).

Where: Drop down list of Sponsorship Opportunities.

Figure 943: Add a vendor and sponsorship opportunity.

15.4. Vendor Reports

Vendor tracking is not actively used in the current application, however vendor tracking should still be considered as a low-priority item in the new application.

131

Figure 954: Vendor Reports.

16. Student Folders

ELI students all have a manila folder created and maintained in the ELI office. The student folder contains a copy of their registration, immigration information, and current payment information, grade reports, advisor information, probation letters, etc. A summary checklist form on the front of the folder provided an easy-to-see view of the student’s current status. Most importantly, payment receipts are kept in the folder, as ultimately a paper trail from cashier to ELI is used to document payments.

132

Appendix C: Glossary

Catalog: A description of courses (not classes!) for a period or quarter or program. Catalogs can be printed or available online.

Certificate: A type of diploma a student received upon successful completion of a program.

Class: Course and Class are often used interchangeably or incorrectly. Strictly speaking, a Class is “description” or instance of a course.

Contract Programs: Refers to a program offered through Extension via a contract with a specific company or group.

Conversation Leader (CL): A person similar to a TA or Guest Speaker. CLs are paid a “stipend”, not a salary. Can be assigned to courses or events but is not an instructor.

Course: Course and Class are often used interchangeably or incorrectly. Strictly speaking, a Course is an instance of a class

Core: ELI places students into different levels based on tested fluency in English. Each Core level has required classes and test scores.

Enrollment: The status or process that students undergo to attend a course or program.

Instructor: Teachers courses.

Program: ELI Program, Program Groups, Program Starts, and Program Group Start Dates are defined in section 4.1.1

Student: Enrolls in a program or course.

Upper and Lower Schools: An ELI concept of splitting students into a sort of upper and lower division set of classes and courses, based on level.

133