Common use of Iteration Conversion Overview Clause in Contracts

Iteration Conversion Overview. The Vendor’s approach combines Vendor’s extensive modernization expertise with automated tools. Low-Risk, Well-Paced Implementation. Vendor will have two integrated and self-contained development teams that have code converters, data converters, and testers. Based on the original RFP requirements and the current property tax system, Vendor will use two-month increments for Vendor’s iterations. Vendor will work with the County to refine this plan as needed. Vendor will use a key artifact called the functional criticality matrix. This matrix, jointly developed with the County during the Assessment phase, defines the importance and order in which Vendor transforms the ATS functionalities and capabilities. Table 2 provides a suggested order for conversion based on the RFP. Table 2. Conversion Order ITERATION SUGGESTED CONVERSION AREA Iteration 0  Complete POC conversion and Assessment Phase Iteration 1  IDEAL – Secured System (TX2) Iteration 2  IDEAL – Unsecured System (UN2) IDEAL – Auditor-Controller System (AC2) Iteration 3  IDEAL – Clerk of the Board System (COB) IDEAL -Assessor Interface System (ACT) Iteration 4  IDEAL – ATS Front-End Security (FAST) IDEAL Panels (CICS Map) Iteration 5  IDEAL Reports Iteration 6  Refactor Items At the end of every iteration, the working conversion code is tested and compared to the legacy ATS functionality. For items that do not work as they do in the Legacy system, Vendor will make note and schedule those items for Iteration 6 which will address Refactor Items. Vendor has found that sometimes the legacy system itself does not produce the anticipated results. In these cases, Vendor advises the client to correct the legacy code before conversion. Very old legacy mainframe systems handle calculations differently – related to order of the calculation’s components, memory management constraints of the past, and other situations. Vendor anticipates that these situations may happen within the legacy ATS. Regardless, Vendor will work with the County to make sure to account for these different reconciliation items. In every iteration, Vendor will complete the required deliverables for the defined unit of functionality. Deliverables include but are not limited to:  Data migration scripts (from DB2)  Source code conversion (from IDEAL PDL including online, batch, interfaces, and reports)  Automated proof cases (utilizing MS Visual Studio and MS Test Manager software)  Functional scenario demonstrations in the stand-alone target environment  Iteration report providing status, lessons learned, issues, risks, and resolutions. Vendor uses continuous deployment and automation in the delivery of its solution. Vendor will continuously deploy updates in an automated manner to its code conversion, data conversion, and testing scripts in the development environment. On a bimonthly basis, at the end of each iteration, the iteration functionality will be deployed to a stand-alone environment to allow for additional testing with the County for User Acceptance Testing. Functionality that does not match legacy discovered by the County will be noted and scheduled for fixing in iteration 6. Iteration 6 is designed for addressing any issues discovered through Vendor’s iteration demonstrations and is expected to be smaller than the other iterations.

Iteration Conversion Overview. The Vendor’s approach combines Vendor’s extensive modernization expertise with automated tools. Low-Risk, Well-Paced Implementation. Vendor will have two integrated and self-contained development teams that have code converters, data converters, and testers. Based on the original RFP requirements and the current property tax system, Vendor will use two-month increments for Vendor’s iterations. Vendor will work with the County to refine this plan as needed. Vendor will use a key artifact called the functional criticality matrix. This matrix, jointly developed with the County during the Assessment phase, defines the importance and order in which Vendor transforms the ATS functionalities and capabilities. Table 2 provides a suggested order for conversion based on the RFP. Table 2. Conversion Order ITERATION SUGGESTED CONVERSION AREA Iteration 0  • Complete POC conversion and Assessment Phase Iteration 1  • IDEAL – Secured System (TX2) Iteration 2  • IDEAL – Unsecured System (UN2) IDEAL – Auditor-Controller System (AC2) Iteration 3  • IDEAL – Clerk of the Board System (COB) IDEAL -Assessor Interface System (ACT) Iteration 4  • IDEAL – ATS Front-End Security (FAST) IDEAL Panels (CICS Map) Iteration 5  • IDEAL Reports Iteration 6  • Refactor Items At the end of every iteration, the working conversion code is tested and compared to the legacy ATS functionality. For items that do not work as they do in the Legacy system, Vendor will make note and schedule those items for Iteration 6 which will address Refactor Items. Vendor has found that sometimes the legacy system itself does not produce the anticipated results. In these cases, Vendor advises the client to correct the legacy code before conversion. Very old legacy mainframe systems handle calculations differently – related to order of the calculation’s components, memory management constraints of the past, and other situations. Vendor anticipates that these situations may happen within the legacy ATS. Regardless, Vendor will work with the County to make sure to account for these different reconciliation items. In every iteration, Vendor will complete the required deliverables for the defined unit of functionality. Deliverables include but are not limited to:  • Data migration scripts (from DB2)  • Source code conversion (from IDEAL PDL including online, batch, interfaces, and reports)  • Automated proof cases (utilizing MS Visual Studio and MS Test Manager software)  • Functional scenario demonstrations in the stand-alone target environment  • Iteration report providing status, lessons learned, issues, risks, and resolutions. Vendor uses continuous deployment and automation in the delivery of its solution. Vendor will continuously deploy updates in an automated manner to its code conversion, data conversion, and testing scripts in the development environment. On a bimonthly basis, at the end of each iteration, the iteration functionality will be deployed to a stand-alone environment to allow for additional testing with the County for User Acceptance Testing. Functionality that does not match legacy discovered by the County will be noted and scheduled for fixing in iteration 6. Iteration 6 is designed for addressing any issues discovered through Vendor’s iteration demonstrations and is expected to be smaller than the other iterations.