NOTICE

This opportunity is being released to ODJFS – Professional Technical Services pre-qualifiedcontractors as a result of Open Market RFP #0A1183. The terms and conditions of the #0A1183 contract apply to this task order solicitation.

ONLY Contractors pre-qualified in the 1.0 ERICEcosystem Technology Category are eligible to submit proposal responses AND to submit inquiries. The State does not intend to respond to inquiries or to accept proposals submitted by organizations not pre-qualified in this Technology Category.

An alphabetical listing of Contractors pre-qualified to participate in this opportunity follows:

CGI Technology Inc.
CMA Consulting
Conduent State & Local Solutions
SogetiUsa
Strategic Systems Inc.

0A1183 Task Order – Employer Resource Information Center

DATEISSUED:September 1, 2017

TheOhioDepartmentofJob and Family Servicesisrequesting proposalsfor work leveraging Contract 0A1183Professional Technical Services: System Operations and Maintenance for Employment Services Systems:

Projects:1. ERIC Solvency

2. Mandatory Electronic Filing

POST DATE: September 1, 2017

INQUIRY PERIOD BEGINS:September 1, 2017
INQUIRY PERIOD ENDSSeptember 8, 2017

PROPOSAL DUE DATE:September 28, 2017 at 1:00 p.m. (Columbus, Ohio time)

OPENINGLOCATION:DepartmentofJob and Family Services

Office of Contracts and Acquisitions

30 East Broad Street, 31st Floor

Columbus, Ohio 43215

Purpose.The purpose of this Task Ordersolicitation is to provide The Ohio Department of Job and Family Services with a prequalified Contractor, herein after referred to as the “Contractor”, to provideservices from theERIC Ecosystem Technology Categoryin the Professional Technical Services Contract. The Contractor shall furnish the necessary personnel, equipment, material and/or services and otherwise do all things necessary for or incidental to the performance of work set forth in Part1, Scope of Work.

Organization.ThisTask Ordersolicitation consists of five (5) parts, three(3) attachments and three (3) supplements listedbelow. Please verify that you have a complete copy.

Parts:

Part 1Scope of Work

Part 1.1Non-Functional Requirements and Standards

Part 1.2Product Development

Part 2Staffing Requirements

Part 3Task Order Evaluation Criteria

Part 4Requirements for Proposals

Part 5Personnel Profile Summary Forms

Attachments:

Attachment AApplication Development Standards

Attachment BSystem Test Standards

Attachment CCost Summary Form

Supplements:

SupplementOneRequirements ERIC UI Solvency (Project 1)

Supplement TwoRequirements Solvency PUP (Project 1)

Supplement ThreeRequirements ERIC Mandatory Online Filing (Project 2)

Part1: Scope of Work

The scope of work to be completed under this Task Order includes work on the Employee Resource Information Center(ERIC) Solvency Legislation Project and the ERIC Mandatory Filing Project. The approach to the completion of work will be to develop final requirements and implement new and revised software using agile processes to meet the business objectives for each project. The project’s current written requirements, as shown in various supplements, provide more details on the overall scope of work within the Task Order.

These two features represent the two business enhancements expected for Fiscal Year 2018 on the ERIC project that are due into production no later than February 2018 with a preference for an earlier date if possible.

The Interim Trust Fund Solvency Project (Project 1)addresses legislation that was passed in December 2016 that changed thetaxable wage base from current taxable wage base to legislatively mandated wage base. This change must allow the State to collect additional tax contributions to help restore the Unemployment Insurance(UI) Trust Fund to solvency.

The Mandatory Electronic Filing Project (Project 2)is a current engineering issue where the currently deployed functionality for processing incoming files from employers sometime locks the system up. This feature must address a more robust solution that flags file for offline processing as well as fixes to the software to remove the probability for a system lock up due to file processing.

Part 1.1: Non-Functional Requirements and Standards

Thedesire is that all the work in this Task Order will be accomplished using an agile development process. Sprints may not exceed four (4) weeks in duration and must deliver potentially deployable code at the end of each sprint. The Methodology must include multi-sprint planning for feature sets when a complete feature set spans more than one (1) sprint. During the life of the Task Order, the standards as shown in the following sections are expected to be followed.

Any formal documents that result from sprint activities that need to be reviewed/approved by ODJFS will require five (5) business days for review and/or approval. No more than two (2) documents can be under review at the same time without prior approval from ODJFS.

ERIC Current Architecture

Application development changes must be implemented using the current software architecture in progress. Changes or additions to this list must be pre-approved by ODJFS. The current software includes but is not limited to the following:

ERIC Architecture

  • WebSphere Application Server 8.5.5.9
  • Java 1.7
  • DB2 V11 – Database & SQL Stored Procedures on IBM z/OS Mainframe
  • JSF 2
  • EJB 2/3.0
  • Prime faces components
  • Adobe Forms Server 7.0
  • IBM Business Process Manager
  • WSRR
  • ESB

ERIC User Interface Standards Overview

  • The system works best with:
  • Screen Resolution of 1366 x 768
  • Microsoft Internet Explorer 11.0 for windows
  • Safari 5.1 for Mac OS X.
  • Adobe Acrobat Reader DC
  • Cookies Enabled, preferably at “medium” setting
  • Using the browser “Back” button will cause error.
  • Must be Americans with Disabilities Act (ADA) compliant.
  • Will not open new windows or “pop-ups” unless specified.
  • Avoids vertical scrolling wherever possible.
  • Has no horizontal scrolling present at a resolution of 1366 x 768 (or the next higher option on the user’s PC).
  • Error messages are displayed above the Screen Name header. The messages are not in any kind of order.
  • A time out warning has been implemented system wide. Internal and externalusers receive a countdown notification after 20 minutes of inactivity. The notificationadvises the user that the system will time out after ten minutes. If no action is taken infive minutes, the countdown timer enlarges and changes to red. If no action is takenafter another 5 minutes, the system automatically logs the user out and any unsaveddata is lost.
  • Has approximately fifteen hundred (1500) business rules.
  • Has approximately seventeen hundred (1700) error/warning/informational messages.
  • Column header wrapping is ok if words are not broken.
  • Table sorting must leave the user on the same page that was selected before sorting instead of going to page 1.
  • When a table is empty, a No Records Found message is shown.
  • Response time represents the maximum response time on the lowest bandwidth
  • Good response time: < 1 seconds
  • Average response time: 1-3 seconds
  • “Not Desirable” response time: > 3 seconds

Note: There are two ERIC screens that have approved exceptions for this criterion. They are:

  • Generate Correspondence 48 due to adobe processing speeds
  • Case Search Screen
  • The page level button cluster including the forward moving button must always be on the lower right of the form.
  • Button placement must follow a Web-navigational flow: left for “back” and right for “forward/next.” Buttons that proceed through steps must appear to the right of buttons that cancel or revert.
  • Hyperlinks are used to navigate between windows, whereas buttons are used to perform a function on a window or initiate some processing.
  • All links must be underlined.
  • Uses rollovers, mouse overs, and hovers only to convey confirmation when the mouse pointer is over the link/button.
  • The mouse pointer must turn into a hand icon when the user hovers over a hyperlink.
  • When aform is loaded, the System places the focus on the first field to enable the user to begin entering data immediately.
  • Where text or background color is used, text and background are highly contrasted, not just shifted in hue (for example, error messages are red, background is white).
  • ODJFS will provide to the Contractorteam, all needed approvals, system and building access (form 7078 and for ERIC access form 20148 - within ODJFS limitations).
  • Contractor to specify any needed hardware, tools and software including database and development tool sets on or before the mutually agreed to date.
  • ODJFSStaff will be available only during core working hours of 9 A.M to 4 P.M on week days.
  • Program area staff work from 7:00 AM – 6:00 PM. They are available to the Contractor during these hours with pre-arranged meetings. The system must be available during these hours.
  • Contractor team is expected to be available during ODJFS core working hours.
  • The system generally does not receive new builds or maintenance during the filing months of January, April, July or October. If these months are needed for deployments or maintenance, the Contractor must confirm approval with the OIS and program areas.

Standards

During the life of the Task Order, in addition to the standards defined in DAS RFP 0A1183, the standards as shown in the attachments are expected to be followed. During the project,Contractor may propose alternative approaches to completion of work. Any proposed changes to these standards must be documented and approved by ODJFS before the changes are allowed.

Part 1.2: Product Development

Project Deliverables

Each Projectmust include:

  1. The offeror must provide training on the selected agile process for this work both documentation and class sessions to the State Subject Matter Experts (SMEs) and Product Owners, to be completed in Sprint 0
  2. Code complete, unit tested, system tested, and user acceptance testedsoftware components
  3. Detailed design and technical design documents
  4. Screen mockups/wireframes/customer demos
  5. Design & code walkthroughs for the development team
  6. Schedule modification requests for batch jobs
  7. Project requirements must be stored in the designated ODJFStool test plan
  8. Manual and automated test scripts
  9. System test knowledge transfer walkthrough with presentation slides

Project Management Expectations

The Contractormust create a documented high level prioritized product back log based on requirements documents provided with this document and additional contractor-facilitated planning sessions. The Contractormust provide training to ODJFS agile team members and other key ODJFS project stakeholders on the agile processes to be used. Training should include information on the process including roles and responsibilities.

The Contractormust develop and provide an overall Project Management Plan for the project. The Contractormust provide a certification letter that all prerequisites of Sprint 0 are complete. Prerequisites are:

  1. Development and testing environments must be prepared and ready for use;
  2. All system and tool access must be available to sprint team members; and
  3. Contractor and ODJFS agile team members must be available to start work.

Application Development Expectations

To fulfill these requirements, the Contractor must analyze the existing code base (interfaces/COTS) to determine how the system currently works and how it needs to be changed to ensurethat the requirements for system changes identified in the Statement of Work (SOW) are met. The Contractor is responsible for development of test plans, execution of testing and correction of defects identified to ensure the system continues to work as the baseline system works. Any new shell scripts or changes to shell scripts made by the Contractorthat are part of the existing batch framework must be approved and submitted by State staff. Software at integration test level and above must be checked in/checked out of Serena Dimensions version control software. The Contractormust provide any changes to JVM arguments, configurations, and property files for implementing the software changes. Impact of software upgrades and interface changes during the task order need to be addressed by the Contractor. The Contractor is responsible for making sure the production ready software works with upgrades and/or interface changes

The Contractor must demonstrate successful completion of unit test upon request.The Contractor must set up scripts and test data for unit testing.If the task order requires any utilities or data conversions, these must be provided as part of Unit Test review

The Contractormust be responsible for creating all project documentation, deliverable and non-deliverable supporting documentation and upload to an ODJFS-provided shared server.

Builds and Deployments Expectations

The production build/deployment schedule will be published by the State team. The Contractormust use this schedule to integrate code changes and follow the cycle to production. Prior to System Test, a production plan is required. This must include deployment artifacts, any migration of data, database scripts, Java Virtual Machine (JVM) arguments, property files and directive to change batch production control and scheduling, if applicable. The Contractor is responsible for coordinating and merging code. The Contractormust retrieve updates made to the code base monthly and update the projects prior to testing.

The Contractor must fix all the issues identified in the enhanced system which were not existing before the enhancement. The Contractor is responsible for troubleshooting, fixing and deploying the corrections to the issues.

Software builds must use the existing build software, including the following:

  • Version control: Serena Dimensions CM 12.2. All application software changes must be made using the existing version control software and maintain the ERIC life cycle.
  • Build Scripts: Must use existing Maven scripts to build application jar files and ear files for ERIC.

Testing Expectations

The Contractor must provide traceability between Serena Dimensions Configuration Managementand HP Application Lifecycle Management (ALM) by linking ALM defects to Dimensions Customer Service Requests (CSRs) used to promote defects into software builds. Projects created in ALM will follow ODJFS testing standards. Conduct a full system test knowledge transfer walkthrough with presentation slides (example provided). User Acceptance Testing (UAT)must identify system defects, any contention that an issue is not a defect must be proven by the Contractor. It is not the responsibility of the Ohio Unemployment Insurance Operation (OUIO) to prove a defect exists. There can be no lost functionality. If the system/function/feature works before the arrival of the Contractor, the system/function/feature must work after any changes are made.

Full requirements and product backlog must be developed in the project, currently written requirements as shown in supplements 1 and 2 must be an input into that process. The summary of requirements shown below may not capture the full system requirements. For detailed requirements, refer to the referenced supplements.

ERIC Solvency Project

Objective

ERIC requires a change to the taxable wage base. Although this is currently a system parameter, a history of the taxable wage base needs to be maintained for any given date. ERIC needs to move from a single parameter to a date-driven parameter. This must allow algorithms to use the correct taxable wage base depending on the reporting period.

Portable Office of UC Audit Program (PUP) must store the taxable wage base by year, calculate the taxable wages by employee based on reporting year and corresponding taxable wage base, and on download with ERIC, annually update the taxable wage base for the upcoming calendar year.

ERIC Application:

Currently, ERIC has more than forty(40) different calls to the taxable wage base for calculation of the taxable wages. How the taxable wage base is called is inconsistent within the application and may be hard coded numerous places. The taxable wage base is the maximum amount of an employee’s wages on which an employer pays unemployment insurance taxes.

1.Update, View, Store Taxable Wage Base

The Contractor must provide one screen to enter the taxable wage base annually and view the taxable wage base history. Taxable wage base history is to be stored from 2010 forward.

2.Taxable Wage Base Reference

The Contractor must prominently display for all ERIC users six (6) years of taxable wage base history in a table within the ERIC system.

3.Taxable Wage Base

The Contractor must set the taxable wage base as a date-based parameter in ERIC. The taxable wage base is currently called in forty (40) different places in code. Currently, the amount is a static reference set at $9000.00.

4.Taxable Wage Calculation

The Contractor must ensure accurate calculation and summation of taxable wages throughout ERIC. The calculation and summation of taxable wages occurs in more than fifteen (15) complex business scenarios. All calculations must call the taxable wage base date parameter.

5.ERIC Reporting

The Contractor must update and verify calculations of reports and the underlying data tables that reference the taxable wage base, calculate taxable wages, or sum the taxable wages. There are over 100 reports in ERIC; however, approximately twelve (12) reports sum taxable wages.

For detailed requirements, refer to supplement 1 “Requirements ERIC UI Solvency”.

PUP Application:

The Portable Office of UC Audit Program, an offline audit tool referred to as PUP, calculates taxable wages by employee based on a hard-coded taxable wage base of $9000.00. Currently, the determination of the taxable wage base does not consider a change in the taxable wage base between reporting years. The taxable wage base has not changed since 1995 and the PUP system went live in 2010.

There are two (2) modules within PUP: Audit and Update Wages. If a screen exists in both modules, a code change mustaffect both modules.

Assumption: Both Audit and Update Wages modules must be updated where each exist within PUP.

1.Synchronization Background

An application update (new version) will not be required to update the taxable wage base as this will occur each time a PUP user downloads to ERIC. The upload and download process is often referred to as synchronization.