ESBD_365998_1721660206373_05 Attachment D Service Legal Requirements.pdf

RFO No. 608-24-91551A Page 1 of 18 Maintenance, Support, and Hosting of the Texas Permitting and Routing Optimization System (TxPROSSM)

Attachment D

Service Level Requirements

1. TxPROS℠ Web-Based Software System Hosting

The Contractor must provide the following services for hosting the TxPROS℠ web-based software system:

1.1. Data Center Facilities. The Contractor must provide both primary and backup data center facilities that meet the following requirements:

1.1.1. Primary Data Center. Provide a “Primary Data Center,” as defined in this Subsection

1.1.1, includes the following:

a) Computer hardware and infrastructure, at a minimum, to ensure that service levels are continually satisfied throughout the life of the Contract.

b) Industry standard uninterruptible power supply system (“UPS”) with sufficient backup generator power to ensure continued operation through extended commercial electrical outages. The system will monitor power input and automatically switch to generator power in sufficient time to ensure continuous operation of TxPROS℠.

c) Physical security sufficient to ensure that access to the Primary Data Center is controlled and restricted to authorized personnel.

d) On-site support staff physically available to provide immediate attention to the

Primary Data Center hardware/environmental issues on a 24-hours-a-day, 7-days-a-week (7x24), 365-days-a-year basis with the exceptions of scheduled downtime as approved by TxDMV in writing for upgrades or routine

TxPROS℠ maintenance. Crisis and event management procedures must be in place to ensure quick determination of issue impact and appropriate escalation in accordance with the requirements identified in Subsection 1.17 titled

“Business Interruption/Disaster Recovery.”

e) Operations to ensure that all TxPROS℠ production data is backed up via real-time data streaming (within 15 minutes of production commit) from the production site to the backup site in preparation for immediate use by the

“Backup Data Center,” as defined in Subsection 1.1.2, during disaster recovery operations.

f) During disaster operations at the Backup Data Center, efforts must be initiated to make the Primary Data Center sufficiently operational to accept real-time data streaming from the backup site.

g) Operations to test and verify, on an annual basis, that the procedure for cutover to the Backup Data Center for production operations is successful.

h) Accessibility for periodic TxDMV on-site audits to ensure that the Primary Data

Center requirements are met. Any deficiencies identified during such audits must be documented and appropriate action taken to resolve, to TxDMV’s satisfaction, all discrepancies within 30 days of notice, in writing, of audit findings.

RFO No. 608-24-91551A Page 2 of 18

1.1.2. Backup Data Center. The Contractor shall provide a Backup Data Center that includes the following:

a) Computer hardware and infrastructure, at a minimum, to ensure that service levels are continually satisfied throughout the life of the Contract.

b) Industry standard UPS with sufficient backup generator power to ensure continued operation through extended commercial electrical outages. The system will monitor power input and automatically switch to generator power in sufficient time to ensure continuous operation of TxPROS℠.

c) Physical security sufficient to ensure that access to the Backup Data Center is controlled and restricted to authorized personnel.

d) Process for disaster declaration in accordance with crisis and event management procedures to cause the Backup Data Center to be placed in production operation satisfying disaster recovery service levels, as defined in Subsection

1.17 titled “Business Interruption/Disaster Recovery,” within 24 hours of the formal declaration being approved or issued. The Backup Data Center’s resources shall be brought up to the level required for production service levels within 7 days of the formal declaration of the disaster.

e) Connectivity is excepted from these requirements as re-establishing connection service depends on response time of the communications provider. However, all available means shall be used to expedite connection service through the associated communications provider. Once a formal disaster declaration has been made and the Backup Data Center activated as the production environment for TxPROS℠ (being the new Primary Data Center) the following requirements apply:

i) On-site support staff physically available to provide immediate attention to new Primary Data Center hardware/environmental issues on a 24-hours-a-day, 7-days-a-week (7x24), 365-days-a-year basis with the exceptions of scheduled downtime as approved by TxDMV in writing for upgrades or routine TxPROS℠ maintenance. Crisis and event management procedures must be in place to ensure quick determination of issue impact and appropriate escalation in accordance with the requirements identified in Subsection 1.17 titled “Business

Interruption/Disaster Recovery.”

ii) Operations to ensure that all TxPROS℠ data is backed up by an agreed method at agreed intervals as defined in the requirements listed in

Subsection 1.1.1 titled “Primary Data Center”.

i) Accessibility for periodic TxDMV on-site audits of capabilities/readiness and, in the event of a declared disaster, operations, to ensure that all Backup Data Center requirements are met. Any deficiencies identified during such audits must be documented and appropriate action taken to resolve, to TxDMV’s satisfaction, all discrepancies within 30 days of notice, in writing, of audit findings.

j) Data streamed to the backup site in preparation for immediate use shall be backed up to removable media no less than daily and secured at an off-site location.

k) During disaster operations at the Backup Data Center, the Contractor will provide

RFO No. 608-24-91551A Page 3 of 18 data streaming from the backup site to a database server at the Primary Data

Center, as soon as that site is sufficiently operational to accept it.

1.2. Data Center Operations. The TxPROS℠ web-based software system production environment hosted at the Primary Data Center will be comprised of the following:

1.2.1. Production Environment:

1.2.1.1. Web Servers – TxPROS℠ front-end web servers containing:

a) User Interface with (i) administrative controls, (ii) mapping interface controls, (iii) permit application processing and permit generation, and (iv) report(s) generation;

b) Routing Engine component for routing (i) all routed permits, (ii) bid routes (capability to estimate a route for bidding purposes); and (iii)

Time Permits (external user responsible for providing route); and

c) Tile Server used to generate and serve up Geographic Information

Systems (GIS) mapping tiles for routing map displays.

1.2.1.2. Database Servers – Provide software access to:

a) GIS Data;

b) Restrictions Management Data;

c) Permits Rules and Data;

d) TxDMV/External User Information;

e) Application Administrative Data/Controls; and

f) Historical Permit Data.

1.2.1.3. Load Balancer – Distribute demand to servers for optimal service provision and response time:

a) Equally and optimally load each active server with TxDMV and external users;

b) Dynamically re-assign TxDMV and external user after logging off and logging in to TxPROS℠; and

c) Actively monitor servers and disable those not running optimally from accepting new connections.

1.2.1.4. E-mail Functionality – Delivery of electronic documents (processed permits, alerts, notifications, etc.) via e-mail to external users accomplished using TxDMV email SMTP solution.

1.2.1.5. Facsimile Functionality – Delivery of electronic documents (processed permits, alerts, notifications, etc.) via facsimile to external users provided as a service which incorporates:

a) Monthly line fees;

b) Per minute fees; and

RFO No. 608-24-91551A Page 4 of 18

c) Facsimile service fees.

1.2.1.6. Real-Time Backup Services – Streaming all data necessary for production operations to the backup database located at the Backup Data Center.

Production data must be replicated at the remote site within 15 minutes of commit to the production database.

1.3. ArcGIS Geodatabase Environment. Provide ArcGIS geodatabase environment to allow

TxDMV to access and edit the geodatabase containing all routing map data. This includes:

a) All software licensing and management; and

b) Geodatabase creation and maintenance.

1.4. Data Repository Environment. An FTP site(s) must be maintained for the purposes of data provision, acquisition and as a data repository for:

a) Posting revenue log files generated by the TxPROS℠ web-based software system;

b) Posting permit and route data for external user consumption; and

c) Receiving data from other State agencies.

1.5. Testing and Training Environments. Environments must be maintained to facilitate the testing and training activities related to the ongoing management of the TxPROS℠ production environment and related tools.

1.5.1. Testing Server – At least one test server must be maintained for:

a) Validation of newly coded modules prior to production implementation;

b) Validation of new GIS data prior to data migration with and without imposed restrictions;

c) Access to test database instance(s) as needed; and

d) Validation of dual database operation for data migrations.

1.5.2. Environment – Setup according to test requirements usually:

a) With latest software release under development; and

b) Configured for access to appropriate test databases for software testing or data migration.

1.5.3. Training Server – One training server must be maintained for:

a) Demonstrations, presentations and training for TxDMV and external users;

b) Validation of new GIS data prior to data migration; and

c) Access to test database instance(s) as needed.

1.5.4. Environment – Setup according to test requirements:

a) With latest software release in production; and

RFO No. 608-24-91551A Page 5 of 18

b) Configured for access to appropriate test databases for training or data migration.

1.6. Test Database Data. Test databases must be maintained to facilitate testing activities related to ongoing management of the TxPROS℠ production environment and related tools. These include, but are not limited to:

a) Restrictions (ORCL1, ORCL2);

b) Bridges;

c) GIS data (current and new versions); and

d) Permit data.

1.7. System Monitoring. Monitor TxPROS℠ web-based software system production environment to assess availability and performance on a continuous basis. This includes proactively monitoring all services and infrastructure to immediately correct a significant fault or error before it affects production operations and, if the detected fault or error cannot be immediately corrected, sending automated alerts to appropriate personnel to warn of an unplanned interruption to production processing. Satisfactory TxPROS℠ availability and performance for a reporting period must adhere to requirements defined in Section 6 titled

“Hosting Performance Measures.”

1.8. Management of Subcontractors. The Contractor is responsible for the provision of services including the management of services secured through subcontractors. This responsibility includes managing the performance of third parties and employing appropriate due diligence and contingency plans to ensure subcontracted resources meet the same reliability, integrity, and performance standards as that required of the Contractor.

1.9. Data Security. Provide operations, procedures, hardware and software security measures sufficient to safeguard TxPROS℠ data that are deemed ‘sensitive,’ ‘confidential, or ‘secret’.

This includes measures to prevent breach, loss, misuse, unauthorized modification, or access to data of a sensitive, confidential, or secret nature. Examples of TxPROS℠ sensitive, confidential, or secret data includes financial records, external user account information, TxDOT bridge data, and any other data that TxDMV may deem sensitive, confidential, or secret.

1.10. Payment Card Industry Data Security Standard (“PCI DSS”) Compliance. TxPROS℠ web-based software system processes payment for permits via Texas.gov common checkout. This involves the processing of major branded credit cards like Visa®, Mastercard®, and

American Express®. As part of TxDMV’s agreement with the Texas.gov processing site, on an annual basis, the Contractor must complete and provide PCI DSS documentation showing attestation of compliance for merchants (Self-Assessment Questionnaire D for Merchants) to TxDMV. Additionally, quarterly scans of the TxPROS℠ environment must be conducted and results provided with each annual certification to TxDMV. For quarterly scans, any failures must be addressed immediately and appropriate actions taken and documented with a follow-up scan showing the failure was addressed.

1.11. Performance Tuning. Tuning to establish the highest level of performance between the

TxPROS℠ web application, database(s), and hardware/infrastructure must be performed

RFO No. 608-24-91551A Page 6 of 18 annually, and on as-needed basis, given the overall health and daily performance of

TxPROS℠. Where possible, all tuning must be performed first on test components that mirror the production environment, before proceeding with production tuning. The

Contractor will provide a report to keep TxDMV appraised of the status and success of annual tuning efforts. All tuning to the production environment must be approved by TxDMV before it occurs.

1.12. Third-Party Software Licensing. Licensing for all non-TxPROS℠ specific software (i.e., applications, operating systems, database systems, system utilities, etc.) must be procured, established, and kept current by the Contractor. Licensing must be appropriately maintained and subject to periodic TxDMV audit.

1.13. Third-Party Software Release Levels. All operating and system support software (i.e., database software, utilities, backup software tools, etc.) must be maintained at version levels that are never more than two versions behind the most current release by software manufacturers unless TxDMV gives written approval to use an older version. The target status is to be one major release behind the current release level with a migration plan, approved by TxDMV, to transition to the current release. This migration plan must be developed by the Contractor and submitted for TxDMV’s review and written approval within

6 months of the date any new major software release becomes available. The migration plan may, with the concurrence of TxDMV, delay actual migration for some period of time to allow for industry feedback on the new release. Unless specifically approved by TxDMV, the Contractor shall not allow operating and system software to become “unsupported” by the manufacturer due to its release level.

1.14. Hardware Refresh Intervals. All hardware (i.e. production/backup/testing/training servers, database servers, load balancers, FTP sites, etc.) must be maintained consistently at levels that ensure performance and efficiency that meets business operations demand. The target is to upgrade or replace hardware at a rate that prevents any noticeable performance issues and any time that additional hardware is warranted due to software enhancements or security concerns.

1.15. Data Backup Procedures. Ensure that all TxPROS℠ data backup and restore procedures, including techniques and software tools are fully documented and meet TxDMV’s requirements. Documentation must be updated annually, of not sooner, to incorporate any/all changes to both the TxPROS℠ web-based software system and operating environment.

1.16. Controlled Data Changes. Complete controlled data changes as follows:

a) For permits awaiting issue – within 4 hours following TxDMV request; and

b) For other data updates – within 24 hours following TxDMV request.

1.17. Business Interruption/Disaster Recovery. A ‘hot site’ disaster recovery location shall be maintained as identified in Subsection 1.1.2 titled “Backup Data Center.” Crisis and event management procedures, which identify the process by which a determination is made to activate the disaster recovery site and how the switch over is made from Primary to Backup

Data Centers, must be developed and maintained by the Contractor, agreed and approved by

TxDMV, and kept readily available at both data centers. When a TxPROS℠ outage occurs, RFO No. 608-24-91551A Page 7 of 18 the original assessment of the outage and estimated time to return to operation will dictate the disaster recovery action to be taken by the Contractor, namely:

a) Outages initially estimated at < 4 hours to return to operation will not require any specific action;

b) Outages estimated at more than 4 hours but less than 24 hours to return to operation require alert notification to the backup data center site personnel for initial preparation for possible switch over;

c) For any estimate initially greater than 24 hours to return to operation or that, during the ongoing evaluation process, reaches a cumulative estimate of more than 24 hours, TxDMV may make the determination to declare a disaster and initiate the switch-over process to the backup site. At its discretion, TxDMV may decide to delay that decision pending further assessments; and

d) When a disaster has been declared by TxDMV, the Contractor shall have a maximum of 24 hours from the declaration to have the backup site fully operational, all data restored and ready for processing, and capable of meeting the backup site permit issuing service levels of no less than 33% of the throughput level of the Primary Data

Center. If the disaster requires an extended operation of the Backup Data Center, the

Contractor shall have sufficient hardware/software resources operational at the backup center within 7 days of the disaster declaration to meet the processing service levels for the Primary Data Center defined in this document.

2. TxPROS℠ Software Maintenance and Support

The Contractor must provide software maintenance and support for all TxPROS℠ web-based software system and related software/tools developed and implemented for TxDMV per the following requirements:

2.1. Corrective Maintenance. Ensure quick determination of software issue impact and appropriate escalation to achieve a remedy in accordance with service level requirements.

The activities associated with these corrective procedures will include bug-fix isolation and resolution as well as root-cause analysis and may include both short-term and long-term fixes. These are further defined as:

2.1.1. Bug Fixes – The emergency repair of any system operation that does not comply with the current approved TxPROS℠ specification. This includes system errors, ‘hung’ or halted screens/processes, or unexpected results within TxPROS℠ that render it unusable for the purpose for which it was designed. Temporary fixes or work-arounds may be employed to minimize interruption to business operations while a permanent solution, based on the result identified by root-cause analysis, is developed.

2.1.2. Root-cause Analysis – A complete and thorough analysis of the underlying or root cause(s) of a problem. Problems will be reviewed to determine their root cause(s) and appropriate measures must be taken to correct the source(s) of the problems resulting in a permanent resolution that brings TxPROS℠ operation back to approved specifications. An online ticket system will be used to document the problem (trouble ticket) as well as the intermediate and final status of the resolution. Status must be prepared and reviewed at weekly status meetings with TxDMV.

RFO No. 608-24-91551A Page 8 of 18

2.2. Software Maintenance, Enhancements, and Licensing Agreement. Per the original contract, TxDMV granted ProMiles a non-exclusive and non-transferable license for use of the

TxPROS℠ web-based software system and its user documentation to use, modify, upgrade, improve, and sell to third parties in exchange that any enhancements developed by ProMiles for other states’ OS/OW permit systems must be offered and provided to TxDMV at no additional cost. This same type of license is also granted hereunder to the Contractor and

TxDMV under the same terms and conditions. The Contractor shall implement any new enhancements developed and accepted by TxDMV into the TxPROS℠ web-based software system. TxPROS℠ enhancements already implemented therein or moved to production servers become part of the base web-based software system with the Contractor granting a non-exclusive and transferable license to TxDMV, which must be supported as such. For the avoidance of doubt, the license granted by the Contractor authorizes TxDMV through its employees or other vendors to use, transfer, keep, modify, upgrade, or improve any enhancements in the TxPROS℠ production environment for TxDMV’s statutorily authorized functions. TxDMV reserves all other rights relating to the intellectual property of

TxPROS℠ and its documentation that is not expressly granted under previous contracts or this Contract. The terms of this Subsection survive the termination of the Contract.

2.3. Transition from Test to Production. TxPROS℠ changes, whether due to corrective maintenance or enhancements, must be thoroughly tested and receive TxDMV’s written approval prior to promotion from the test to the production environment. Production implementation will occur after normal TxDMV Oversize/Overweight Permits business hours at the direction of TxDMV, unless TxDMV deems it appropriate to proceed during business hours.

2.4. Database Tuning. Includes at least annual services, and emergency services when necessitated by TxPROS℠ performance issues, for the review of TxPROS℠ web-based software system and database interactions, provision of recommendations and subsequent modifications to improve or ensure performance. All work must be approved by TxDMV in writing prior to initiation and scheduled to occur after normal TxDMV business hours unless otherwise agreed.

2.5. TxPROS℠ Software Backup. All production level software components of the TxPROS℠ web-based software system must be duplicated at the disaster recovery site and capable of immediate operation according to requirements listed in the Subsection 1.17 titled “Business

Interruption/Disaster Recovery.” The Contractor shall maintain a separate copy of the complete TxPROS℠ software on removable media at a secure location off-site from the production operating site, to be used in the event of a disaster at either the Primary or Backup

Data Centers that results in only one of the centers being functional.

2.6. TxPROS℠ Software Escrow. The most current versions (new or updated components) of all software developed for TxDMV must be provided as escrow to TxDMV within 10 business days of acceptance/promotion to the TxPROS℠ web-based software system production environment that includes, but is not limited to, the following:

a) Provision for TxDMV to have escrow account access to, and receive the source code and data for, all products which comprise the TxPROS℠ web-based software system.

RFO No. 608-24-91551A Page 9 of 18

b) Delivery of all custom and reuse software, if used, as machine readable source files, linkable or executable modules, and printed source listings, in addition to installed and operating copies of the programs (baseline software or hardware configuration shall not be created such that only the Contractor could change).

c) Identification of the tools required for the modification and compilation of the software programs.

d) Delivery of source codes for all custom and reuse software programs developed under the Contract with all support resources needed to edit, compile, and install these programs on servers including but not limited to: Computer-aided software engineering (“CASE”) tools, compilers, editors, and function libraries used in the development of the programs.

e) Delivery of all documentation concerning protocol for all custom and reuse software, source code, commented listings, descriptions of software structure, database utilization and instructions necessary to convert the source code into an operational system.

f) Delivery of all custom and reuse software in a standard design and format that can be use and modified by other vendors or developers.

g) Using only reuse software that is in the public domain.

h) Refraining from placing a legend on the custom or reuse software which restricts

TxDMV rights in such software unless the restrictions are set forth in a license agreement approved and executed by TxDMV.

i) Transferring to or purchasing for TxDMV all licenses to software acquired in conjunction with the Deliverables (as defined in the Solicitation), including all original media, documentation, warranties, licenses, applications software, and developmental software used in developing custom applications.

2.7. Documentation Updates. All TxPROS℠ technical and user documentation must be updated for each production upgrade to reflect changes in technical configuration and environment and the way the software or tool functions. Updated documentation must be delivered to

TxDMV along with the current version of all updated software code (within 10 days of acceptance/promotion to production) for each production release.

2.8. System Use Assistance. Provide advice about, education, and/or informal training on how to use TxPROS℠ and related software/tools, including completing transactions, creating users within or for an application, and supporting external users who may be using unsupported or nonstandard hardware or software resulting in unexpected behavior of an otherwise reliable system.

2.9. Online Ticket System. Create, maintain, and monitor an online ticket system for use by

TxDMV to submit requests for TxPROS℠ web-based software system support and maintenance/updates. Ticket system must:

a) Be continuously available;

b) Allow TxDMV to submit ticket outlining issue or need and indicate a priority level;

c) Display the issue details, status and attempts at resolution for each request;

d) Alert TxDMV users and the Contractor via email of new requests or updates to existing requests;

e) Allow updates to request content;

RFO No. 608-24-91551A Page 10 of 18

f) Provide reports regarding open (or uncompleted) requests;

g) Record date and time stamps for auditable events, such as ticket submittal and resolution;

h) Provide statistics and metrics regarding response to and completion of requests (for reporting performance regarding service level requirements); and

i) Provide ability to review history of all requests and resolutions.

2.10. Helpdesk. Provide a help desk phone number, email address(es), and other contact means to support TxDMV users experiencing problems. Helpdesk must:

a) Operate during TxDMV Oversize/Overweight Permits business hours as published on

TxDMV’s Website (www.txdmv.gov)

b) Provide assistance in response to TxDMV inquiries regarding software functions; and

c) Provide system software troubleshooting assistance to TxDMV staff.

d) Provide information about TxPROS℠ web-based software system modifications made as a result of inquiries and troubleshooting.

e) Provide 24/7 365 on call support for reporting of TxPROS℠outages or issues which prevent TxPROS℠ from performing as intended.

2.11. Data Queries and Data Provision. The Contractor will provide services to support data acquisition and distribution as follows:

a) Create and post the following data to published FTP site/s: (i) daily revenue log files generated by the TxPROS℠ web-based software system; and (ii) anonymized monthly permit and route data, in format agreed by TxDMV, for external user consumption;

b) Retrieve from FTP site, and process data for daily bridge files (provided from TxDOT bridge software solutions); and

c) Perform data queries for: (i) information to satisfy open records requests - delivered on average within 2 business days following TxDMV request; (ii) answering legislative questions – delivered within 24 hours following TxDMV request during

Texas’ legislative sessions; (iii) GIS data related to issued permit/s – delivered within

4 business days or less following TxDMV request; and (iv) permit data not available through TxPROS℠’ reporting interface – delivered within 4 business days following

TxDMV request.

3. TxPROS℠ Mapping Data Maintenance

The Contractor must provide data maintenance services for TxPROS℠ mapping data that meet the following requirements:

3.1. Biannual GIS Data Updates. A system-related service which requires:

a) Procuring licensed quarterly updates of GIS data for all roads within the State of Texas from a third-party GIS provider to include the complete state-of-Texas road network

(off-system, as well as, on-system roads).

b) Updating the data to include, but not be limited to: (i) add new road segments not currently in the TxPROS℠ GIS data; (ii) deactivate, but don’t delete, road segments in the TxPROS℠ GIS data that have been deactivated in the licensed update of GIS http://www.txdmv.gov/

RFO No. 608-24-91551A Page 11 of 18 data; (iii) update all GIS attributes per the licensed update for all active road segments in the TxPROS℠ GIS data; (iv) reconcile all differences between the TxPROS℠ GIS data and the licensed update; (v) add all road segments as directed by TxDMV for roads not included or not correctly implemented in the update; (vi) eliminate stacked and missing segments in the road linework; (vii) insure all shared nodes on road segments are connected for routing continuity; (viii) insure all applicable data and attribute changes made for the previous data migration base data are incorporated into the new data; and (ix) migrate perfected Arterial Classification Code schema to each new data migration data set.

c) Conflating (matching and selectively blending multiple sources of GIS data) attribute data from the most up-to-date state agency data sources to all road segments of the licensed update. Where such conflation is not feasible TxDMV will determine which attributes will be used. Mark the following state agency attribution to all new road segments within the TxPROS℠ mapping data: (i) on-system; (ii) primary roadbed name; (iii) roadbed type; (iv) frontage road direction; and (v) loop direction.

d) Providing updated TxPROS℠ mapping data to TxDMV for Quality Assurance (“OA”) and Quality Control (“QC”). Data must meet the following accuracy on initial delivery: (i) 4 of 5 random samples of 500 elements (road segments) has < 11 errors;

and (ii) at least 95% accuracy for the data set.

e) TxDMV will validate or identify discrepancies in the updated mapping data and submit requests to resolve discrepancies. The Contractor shall resolve discrepancies until

TxDMV validates the mapping data at 98% accuracy level.

f) Building runtime data files as necessary for routing.

g) Building a list of restrictions to be migrated from road segments in the current production mapping data to road segments in the new migration mapping data and provide to TxDMV for review and written approval.

h) Manually migrating and reviewing all restrictions for accuracy and assist TxDMV in reviewing the migrated restrictions.

i) Migrating carried bridges as necessary.

j) Promptly updating all runtime data files for routing during the lock-down period.

k) Prior to each upcoming data migration start date, providing TxDMV with a preview of the latest licensed GIS data update via provider-approved means.

l) Performing data migration activities based on a scheduled timeline jointly developed and agreed with TxDMV. The activities must be completed within +/- 5 work days of agreed time line. Based on TxDMV’s business needs and schedule requirements, a migration may be delayed and combined with the subsequent migration into one effort.

It is understood that each TxPROS℠ data migration can be completed only after the licensed GIS data is incorporated.

m) Following a production data migration, providing the complete mapping data in

ArcGIS file format to TxDMV for data history and version control purposes.

n) Conflating bridge LIDAR data and images to mapping data displayed within

TxPROS℠ web-based software system at least biannually to include (i) displaying

LIDAR data date stamp within the software; and (ii) converting PDF images to JPG images for display within the software.

4. TxDMV Staff Authorized to Approve the Contractor’s Work

In addition to the TxDMV Contract Representative as set forth within the Contract signature

RFO No. 608-24-91551A Page 12 of 18 document, the following individuals (which list may be modified in writing by the TxDMV

Contract Representative) are authorized to review and approve the Contractor’s work:

DuWayne Murdock

Bryan Elliott

Sarah Storm

James Bunner

John Arkinson

5. Performance Measures and Associated Remedies

TxDMV will monitor the performance of the Contract issued under this Solicitation. All

Deliverables under the Contract must be provided at an acceptable level of quality and in a manner consistent with acceptable industry standards, custom, and practice. Liquidated damages, as set out below, are not intended to be punitive and will be enforceable. Assessment of liquidated damages does not preclude TxDMV from pursuing other remedies it may have under the Contract.

6. Hosting Performance Measures

Performance for the specific requirements identified in the Section 8 titled “Hosting Service Level

Requirements” will be measured and reported on a monthly basis. The Contractor will produce and deliver reports to TxDMV by the 10th calendar day of the month following the measured month. If performance for a month does not meet the goal for any service level, liquidated damages will be assessed and deducted from the monthly hosting payment. During a calendar quarter, as the report for the last month of the quarter is produced, the average for the calendar quarter for each service level will also be computed and compared to required service levels. If the calendar quarter average meets or exceeds the goal for the required service level, the monthly hosting payment for the third month of the quarter will include reimbursement for any liquidated damages deducted from the monthly hosting payments for the two previous months of the quarter.

Liquidated damages will be assessed using the formula below.

(Base Amount) X (Performance Category Weight) X (Service Level Factor)

= Assessed damages, where:

A. Base Amount is the base contracted amount for hosting services performed (e.g., $20,000.00 monthly for Host Processing).

B. Performance Category Weight is the percentage (as defined in “Service Level

Requirements”) of the total service category that is applied to this service level goal (e.g., 50% for availability).

C. Performance Factor is the range of performance below the target performance level goals

(as defined in “Service Level Requirements”) that is reflected in a decimal to be applied in the formula.

7. Liquidated Damages

7.1. Application of Liquidated Damages. If performance for a particular service level category does not exceed a Performance Factor level of ‘non-performance’, no payment will be made for that service level category for the month. Liquidated damages for a billing period will not

RFO No. 608-24-91551A Page 13 of 18 exceed the total billing amount for that period. Exercise of any liquidated damages provisions does not prohibit TxDMV from pursuing any other remedies at law.

7.2. Example of Liquated Damages. If the Hosting monthly payment total is $20,000 and the

‘System Availability Service Level’ goal represents 50% of the total Performance Category

Weight, and the performance was five percent short of goal so the Performance Factor is

0.05 (5%), the calculation for not meeting that service level goal would be: 20,000*0.50*0.05 or $500.00 in liquidated damages deducted from the monthly payment.

8. Hosting Service Level Requirements

All service levels are subject to monthly liquidated damages for non-attainment.

8.1. Service Level Categories

8.1.1. System Availability. The system availability metric is used to measure the availability of the ‘Total Integrated External User Solution’ that allows the user to complete any/all transaction types on a 24-hours-per-day, 7-days-a- week, 365-days-a-year basis. It requires that the Web Server and components (including Permitting

Interface, Routing Engine, Map Control, Tile Server) and the Database Server are functioning along with e-mail and fax distribution services. As long as all transaction types, including, but not limited to the ability to validate and run a route, can be processed by both TxDMV and external users TxPROS℠ is considered “available.”

This metric is expressed as a percentage of the actual availability (in time) compared to the scheduled availability (total available hours in month – scheduled downtime) in which total hours in the month equals 24 hours times the number of calendar days in the month and scheduled downtime is mutually agreed upon time, in hours, when

TxPROS℠ is scheduled for maintenance, upgrades, migrations, etc.

Results from both the Contractor’s and TxDMV’s system monitoring will be used to identify potential outages and to alert the appropriate personnel. If an outage is validated, a problem ticket will be initiated via the help desk to track the downtime.

The Contractor’s initial response to the help ticket must include an assessment of the cause of the outage and an estimate of the time required to return TxPROS℠ to available status. This response must be provided within 15 minutes of the submission of the help desk ticket.

The help desk ticket will be used to track TxPROS℠ downtime. Any downtime less than 15 minutes will be rounded up and recorded as 15 minutes of down time.

Downtime 15 minutes or greater will be recorded as the exact number of minutes

TxPROS℠ was down. Help desk ticket documentation will serve to identify the total unscheduled downtime for the month. Every TxPROS℠ downtime event is to be recorded in the online ticket system. Outages due to force majeure will not be charged as unplanned downtime for this performance metric but used to reduce the total available hours for the month. The calculation of TxPROS℠ availability is then calculated using:

(Scheduled Availability – Total Downtime) /

RFO No. 608-24-91551A Page 14 of 18

Scheduled Availability = System Availability

Example: In a 30-day month TxPROS℠ had four, two-hour scheduled outages for routine maintenance. During the month TxPROS℠ experienced one, three-hour unscheduled outage for a disk crash and one outage of one-hour for an I/O processor failure. The calculation for this hypothetical month would be (((30*24)-8)-

4)/((30*24)-8) or (((calendar days*24 hours per day)- scheduled downtime)-unscheduled downtime)/ (((calendar days*24 hours per day)-scheduled downtime) =

.99438 or 99.4%

The Performance Category Weight for this metric is 0.50 (50%) and the service level goal is 99.4%.

The Service Level Factors for this metric are:

Table 1 - System Availability Service Level

System Availability is: Performance Factor is:

< 70.0% ‘non-performance’

70.0% - 79.9% 1.00

80.0% - 89.9% 0.90

90.0% - 94.9% 0.75

95.0% - 96.4% 0.50

96.5% - 97.4% 0.25

97.5% - 98.4% 0.10

98.5% - 98.9% 0.05

99.0% - 99.3% 0.02

8.1.2. Transaction Response Time: The transaction response time metric represents the amount of time (in seconds) that it takes to return a route, complete with driving directions. All route requests will receive a time stamp when initiated and when the route and driving directions are returned. Transaction response time is the delta between these two time stamps. Transaction response time for all route requests (bid route, time permit route, route inspection route and single-trip permit route) will be used in computing the response time metric. The metric will be reported on a monthly basis and will reflect overall average response time and the percentage of transactions whose response time falls into the goal areas. The transaction audit data used by the

Contractor to report the response time metric will be maintained for at least three months following the reported month and is subject to review by TxDMV for validation purposes.

Given the variation in the complexity of route requests (total distance, vehicle envelope, restrictions involved, etc.), this service level category has two distinct service level goals.

Transaction Response Time I is the percentage of routes computed and returned in

12 seconds or less. These would theoretically represent the shorter, less complicated, routes.

RFO No. 608-24-91551A Page 15 of 18

The Performance Category Weight for this metric is 0.15 (15%) and the service level goal is 95% of all routes.

Table 2 - Transaction Response Time I Service Level

% of routes in < 12.01 seconds is: Performance Factor is:

< 50.0% ‘non-performance’

50.0% - 74.9% 1.00

75.0% - 84.9% 0.90

85.0% - 89.9% 0.75

90.0% - 90.9% 0.50

91.0% - 91.9% 0.25

92.0% - 93.4% 0.10

93.5% - 93.9% 0.05

94.0% - 94.4% 0.03

94.5% - 94.9% 0.01

Transaction Response Time (continued): Transaction Response Time II is the percentage of routes computed and returned in 30 seconds or less. These would represent the composite of both the shorter, less complicated, routes and the significantly longer, more complex, routes.

The Performance Category Weight for this metric is 0.25 (25%) and the service level goal is 99.8% of all routes.

Table 2 - Transaction Response Time I Service Level

% of routes in < 30.01 seconds is: Performance Factor is:

< 70.0% non-performance

70.0% - 74.9% 1.00

75.0% - 79.9% 0.90

80.0% - 83.9% 0.80

84.0% - 86.9% 0.70

87.0% - 89.9% 0.60

90.0% - 91.9% 0.50

92.0% - 93.9% 0.30

94.0% - 96.4% 0.20

96.5% - 97.9% 0.10

98.0% - 98.9% 0.05

99.0% - 99.4% 0.03

99.5% - 99.7% 0.01

8.1.3. Help Desk Initial Response Time. The help desk initial response time metric represents the amount of time, on average, required to receive a response from the

RFO No. 608-24-91551A Page 16 of 18

Contractor for a reported issue. The initial response must include an assessment of the cause of the issue and an estimate of the time required for resolution. A problem ticket will be submitted for each issue that requires formal resolution. The details of this ticket will serve to identify the help desk initial response time. The delta from the ticket’s submit time stamp to the time stamp related to the Contractor’s response that includes assessment and estimate will be considered the help desk initial response time. The average of these for the month will constitute this metric. In the event that issues do not occur during a particular month, this metric will not be measured.

The Performance Category Weight for this metric is 0.1 (10%) and the service level goal is 120 minutes.

Table 3 - Help Desk Initial Response Time Service Level

Average time to initial help desk response in minutes is:

Performance Factor is:

> 240 1.00

221 to 240 0.90

201 to 220 0.75

181 to 200 0.50

161 to 180 0.25

141 to 160 0.10

121 to 140 0.05

120 0.02

8.1.4. Software Maintenance Performance Measures. Performance for the specific requirements identified in the section titled “Software Service Level Requirements” will be measured and reported on a monthly basis. The Contractor will produce and deliver reports to TxDMV by the 10th calendar day of the month following the measured month.

8.1.5. Application of Liquidated Damages. Failure to meet the Software Service Level

Requirements will cause TxDMV to sustain actual damages in the form of business operations interruption or delay of services in an amount that is difficult to quantify.

TxDMV may require the Contractor to pay liquidated damages for failure to comply with the requirements set out below. Liquidated damages will not be assessed if the failure to meet service level requirements is due to TxDMV error or oversight.

Monetary values for liquidated damages will be based on the severity of the issue/s introduced. Liquidated damages will be assessed on a quarterly basis, based on compiled monthly Work Summary Reports submitted by the Contractor, for the current software maintenance and support year, and deducted from the yearly amount paid for software maintenance and support for the upcoming year at invoice time. In the case where the Contract ends prior to the upcoming yearly software maintenance and support amount being paid, liquidated damages will be re-paid to TxDMV by the

Contractor.

RFO No. 608-24-91551A Page 17 of 18

9. Software Service Level Requirements

All service levels may be subject to liquidated damages for non-attainment.

9.1. Service Level Categories

9.1.1. Software Quality. Apply solid coding standards to TxPROS℠ and related software/tools to ensure uniformity and harmony within the software. Routinely conduct thorough software code reviews to identify defects in the code before delivery to TxDMV for user acceptance and regression testing. Ensure new software releases containing maintenance fixes when promoted to the production environment are flawless.

This service level category has two distinct service level goals.

Software Quality I requires providing high quality software code with a minimum number of issues that are discovered in User Acceptance Test (“UAT”) environment.

The service level goal is < 20% of code has issues discovered in UAT. At each

Error Level, liquidated damages may be assessed according to the impact to

UAT and release timeline.

Table 4 - Software Quality I Service Level

Error Level Can UAT Continue?:

1 Cannot continue

2 Cannot continue for more than 50% of the fixes

3 Cannot continue for more than 80% the fixes

Software Quality (continued). Software Quality II requires promoting high quality software code without significant errors to the production environment.

A maintenance software release is considered high quality when a release is promoted without introducing significant new errors, removing/eliminating previously implemented fixes, or introducing new features without TxDMV’s written approval.

Significant errors are considered those that impact the TxDMV’s ability to conduct business by issuing permits either through interruption or delay of services.

The service level goal is 0 significant errors implemented in the production environment.

Table 5 - Software Quality II Service Level

RFO No. 608-24-91551A Page 18 of 18

# Significant Errors/Release Liquidated Damages Assessed

3 or More $1,000.00 Per Error

2 $500.00 Per Error

1 $250.00 Per Error

(Remainder of Page Intentionally Left Blank)