COMPETITIVE SOLICITATION #1623-610 REQUEST FOR …€¦ · Project Title: Eligibility Service and...

Competitive Solicitation #1623-610 of 91

COMPETITIVE SOLICITATION #1623-610

REQUEST FOR PROPOSALS

Project Title: Eligibility Service and ACES Remediation (ESAR) Mainframe Rehosting Project

Estimated Contract

Performance Period: January 2018 through June 2019

Response Due Date: All Responses must be received in their entirety by 3:00 p.m. Pacific Time on August 21, 2017, unless an Amendment is issued modifying the Solicitation Schedule set forth in Section C.1 of this Solicitation Document.

Submit Response To: Responses must be submitted to: James O’Brien, Solicitation Coordinator

Department of Social and Health Services Operations Support and Services Division Central Contracts and Legal Services Email: [email protected]

Solicitation and Amendments Will Be Posted on: DSHS Procurement Website: https://www.dshs.wa.gov/fsa/central-contract-

services/procurements-and-contracting WEBS Website: https://fortress.wa.gov/ga/webs/ Applicable WEBS Commodity Codes: 0112, 9270, 7670


TABLE OF CONTENTS

Section A – Proposal Submission, Services, Deliverables and Contract Requirements ... 3 1. Background .............................................................................................................. 3

2. Purpose .................................................................................................................... 5

3. Project Scope ........................................................................................................... 5

4. Current System Information and Metrics (Appendices A-N) ..................................... 6

5. Statement of Work ................................................................................................... 6

6. Bidder Minimum Qualifications ............................................................................. 277

7. Period of Contract Performance ............................................................................. 30 8. Funding .................................................................................................................. 30 9. Payment and Holdback…………………………………………………………………...30 Section B – Definitions …………………………………………………………………………32 Section C – Explanation of Solicitation Process …………………………………………….34 Section D – Instructions for Content, Format, Submission of Written Responses ………39 Section E – Evaluation of Responses ………………………………………………………45 Section F – Bidder Debriefing and Protest Procedure ……………………………………..52 Section G – Contracting Procedures …………………………………………………………54 Appendices Appendix A – Number of Objects in Legacy Applications .............................................. 55 Appendix B – Application Software ................................................................................ 59 Appendix C – ACES Modes of Operation ...................................................................... 66 Appendix D – ACES Reference Architecture Diagram ................................................... 67 Appendix E – ACES Software Reference Architecture Diagram .................................... 69 Appendix F – ACES Hardware Schema ........................................................................ 71 Appendix G – ACES Applications .................................................................................. 73 Appendix H – ACES Complex Architecture ................................................................... 75 Appendix I – System Context Diagram .......................................................................... 76 Appendix J – ACES Hardware/Software Matrix ............................................................. 77 Appendix K – Open Source Software ............................................................................ 79 Appendix L – DSHS Data Security Requirements ......................................................... 86 Attachments Attachment A: Sample Contract Attachment B: Sample Bid Submission Letter Attachment C: Bidder Certifications and Assurances Attachment D: Bidder Response Form Attachment E: Contractor Intake Form Attachment F: Bidder Customer Reference Form Attachment G: Cost Proposal Form


SECTION A PROPOSAL SUBMISSION, SERVICES AND DELIVERABLES

AND CONTRACT REQUIREMENTS

1. Background

DSHS delivers health and human services (HHS) benefits to clients across the state of Washington using the Automated Client Eligibility System (ACES) complex of applications. ACES is the eligibility determination and case maintenance system for public assistance programs that support state and federal programs for the State of Washington such as Temporary Assistance for Needy Family (TANF), medical, and Basic Food.. ACES is a large, complex, and comprehensive system, supporting approximately 3,000 users in over 90 locations throughout the state and distributing over $2 billion in annual client benefits.

The ACES ‘complex’ is comprised of ACES (both mainframe and web environments), Eligibility Service (ES), Washington Connection (WaConn), Enterprise Data Warehouse, and other sub-systems as defined in the Appendices of this RFP. The Eligibility Service was developed to support the Affordable Care Act and Washington’s Health Benefit Exchange (HBE). Washington Connection is a public facing web application supporting online applications for public assistance benefits, eligibility reviews, and reporting changes in circumstances. WaConn is used by the public as well as Community Based Organizations, and includes a Client Benefit Account to provide personalized benefit information.

The ACES Complex of applications support a variety of statewide functions and payment processes including: • Client intake and screening, including face-to-face and telephone

• Application processing, including “online” applications

• Scheduling for eligibility determination and review

• Multi-program eligibility determination

• Automated benefit calculation and benefit issuance [Electronic Benefit Transfer (EBT) and Electronic Funds Transfer (EFT)]

• Client notifications including eligibility and benefit changes

• Eligibility screening for the Health Benefit Exchange

• Over 70 state and federal interfaces

• Reports and inquiries needed for routine operation, as well as those required for primary research functions, forecasting, and budgeting

The online environment is supported by both mainframe Customer Information Control System (CICS) and JAVA/.Net. In addition to the online environment, ACES also has a large daily and nightly batch component which supports the day-to-day operational environment.

ACES was implemented in 1996 and originally developed as a mainframe system using Common Business Operating Language (COBOL) and Information Management System


Database (IMS DB). Over the years, some portions of the system have moved to a web platform and DB2 database, but the majority of the system still resides in COBOL/IMS non-relational DB programs. ACES also maintains a data warehouse component that exists in both Windows and Linux environments. Both the Eligibility Service and Washington Connection were developed using the Java Spring Framework, DB/2 and Operational Decision Manager (ODM) for business rules development.

IMS DB is the primary database used by ACES to manage and store its application data and is the State of Washington’s eligibility system of record. The data is replicated to DB2 in near real time for use by other sub-systems within the ACES complex. The DB2 data store is available for the modern applications. The goal of this project is to migrate the ACES components to a more modern and open platform that is available to all of the systems and sub-systems within the ACES complex without replication. The re-platformed ACES database will be the new eligibility system of record.

DSHS envisions the Rehosting project will occur in phases as follows:

Assessment – This includes the Initiation Phase and the Analysis and Detailed Systems Review and Inventory Phase. The Bidder will review and analyze the systems and sub-systems contained within the ACES complex including any interfacing ancillary systems that may be affected by rehosting. The goals and objectives of these phases are to:

• Finalize the scope of impacted applications

• Identify application dependencies

• Identify existing architecture to include inventory, analysis and measurement of all software and database components, and target platform architecture views

• Develop a plan for the rehosting

• Identify rehosting issues and risks

• Identify essential software and hardware

Implementation – This includes the Platform Design Phase, Platform and Application Migration Phase and Deployment Phase. The Bidder will provide and install all software and hardware for all required environments and rehost the ACES complex systems and sub-systems to the new platform according to the plan developed and agreed to by DSHS and the Bidder. The goals and objectives of these phases are to:

• Reduce total operational expenses

• Eliminate data replication

• Allow for greater flexibility in the size and support model for the technical environment

• Maintain compliance with data security and protection of ACES data, including transit, storage, backup and recovery

• Optimize overall operational performance


• Work with DSHS to revise the Disaster Recovery strategy for ACES under the new platform

• Provide maintenance and operations services for the rehosted environment not including the application development.

• Meet/exceed Service Level Agreements (SLA) as specified in section D9 of Bidder response form.

• Modernize existing legacy architecture

Continuing Modernization Recommendations – DSHS envisions there will be a need to determine next steps to fully modernize the legacy system after rehosting is completed. The Bidder shall provide a Continuing Modernization Recommendations Report which shall include an assessment of risks and issues related to the legacy system and recommendations for modernization covering the following areas:

• Database modeling and redesign

• Infrastructure/systems reengineering

• Utilization of a modern rules engine

• Security monitoring/compliance/enhancements

• Batch processing

• Resources, skills and experience - current and future needs

2. Purpose

This competitive solicitation for a fixed fee deliverables-based contract is issued in order to assist the Economic Services Administration (ESA), Information Technology Solutions (ITS) Division of the Washington State Department of Social and Health Services (DSHS) in seeking qualified contractor(s) to rehost all Automated Client Eligibility System (ACES) mainframe applications residing on the IBM mainframe to an open platform that can deliver a mainframe-class scale and asynchronous, high throughput and high performance computing system. The goal of this effort is to implement a successful rehosting solution that will provide a relatively low-cost and low-risk way to reduce mainframe operating costs. The proposed solution must minimize the amount of change in original legacy applications, while maintaining the business value they provide. DSHS must be able to continue to leverage its existing coding languages and skill sets. The successful rehosting solution will seamlessly replace or migrate all existing ACES functionality, security and interfaces. The proposed solution will minimize the amount of change that must occur when migrating systems to a distributed platform. The proposed solution must emulate Customer Information Control System (CICS) and Information Management System (IMS) APIs so that transactional programs do not have to be re-engineered; such as job control language (JCL) batches and basic mainframe file types and Virtual Storage Access Method (VSAM).

3. Project Scope


The Bidder must provide the following services and activities as appropriate to meet the goals and objectives listed above. These services, not in any specific order, include but are not limited to:

• Project Management for Bidder activities under this contract

• Technical Architecture and Infrastructure Design

• System Analysis

• Hardware and Software Installation and Configuration

• Migration of all components related to ACES (i.e., COBOL programs, copybooks, subroutines and databases)

• Customization where approved

• Data Migration/Conversion

• Testing (unit, system, stress, performance, UAT)

• Training, including Manuals and Materials

• Knowledge Transfer

• Documentation

• Change Management

• Deployment (Go Live) Support

• Post Implementation Support

• Continuing Modernization Recommendations

4. Current System Information and Metrics (Appendices A-N)

DSHS has provided detailed ACES complex information and metrics in Appendices A through N. These appendices are an integral part of this RFP and should be reviewed in detail relative to the project services and deliverables listed in Section 5 – Statement of Work.

A diagram of the exiting DSHS ACES complex hardware schema is provided in Appendix F.

5. Statement of Work

DSHS has proposed a set of services and deliverables that it believes to be essential for successful project management and implementation of the proposed solution. This Section has been organized to relate the required services to the phases and deliverables necessary to measure progress toward a successful implementation. Unless specifically identified as a task to be led or “owned” by DSHS, the Bidder shall assume that its staff will lead the delivery of that service (and completion of related


deliverables) with the assigned DSHS personnel participating in a supporting and/or subject matter expert role.

All Phases in the Statement of Work must be documented in the Project Work Plan. Initial work products or changes to work products within Section 5 Statement of Work, must be approved by DSHS prior to commencing work.

5.1. Initiation Phase

The Bidder shall provide the following deliverables and associated services to ensure proper project planning, execution, and monitoring and controlling of project work.

5.1.1 Project Work Plan

The Project Work Plan must include tasks to be performed by both DSHS and Bidder Personnel for all Phases of the project. The following elements must be included in the Work Plan:

5.1.1.1 Tasks, activities and description for the entire project

5.1.1.2 Dependencies, critical paths, and resources (both Contractor and State staff) assigned to each task

5.1.1.3 Project deliverables

5.1.1.4 Estimated work efforts

5.1.1.5 Milestones and events

5.1.1.6 Review and approval points

5.1.1.7 Constraints, risks, and assumptions

5.1.2 Status Reports

The Bidder’s Project Manager shall be responsible for providing written weekly status reports, in an agreed upon format, and shall participate in weekly status meetings with DSHS. The Bidder’s Project Manager in conjunction with DSHS will use the status reports to monitor activity and to detect potential problems or delays.

The Bidder’s Status Reports shall include, but not be limited to:

5.1.2.1 Significant variations from the Project Work Plan with explanations of causes, effects on other areas, and strategies to achieve realignment


5.1.2.2 Tasks completed since the last report

5.1.2.3 Delayed tasks and reasons for delay, with expected revised completion date

5.1.2.4 Planned tasks and activities for the next scheduled reporting period

5.1.2.5 Key decisions made

5.1.2.6 Major concerns or issues encountered, proposed resolutions, and actual resolutions

5.1.2.7 Any other topics and risk items that require attention

In addition to the weekly status reports, the Bidder shall provide a monthly executive summary report that includes risks and issues, their mitigations and resolutions and any matters requiring management’s attention or assistance. In addition, the monthly executive summary report must reflect the status of all work items scheduled to be completed during that reporting period, according to the project schedule. Each item scheduled to be completed must be designated either as incomplete or certified by the vendor to be complete.

5.1.3 Risk/Issue Management

In collaboration with DSHS, the Bidder shall be responsible for identifying and assessing potential risks and issues of the project, as well as identifying and managing actions to avoid, transfer, mitigate, or manage those risks and issues throughout the life of the project.

5.1.4 Configuration Management Plan

The Bidder shall be responsible for configuring all software to meet the requirements of the State. State personnel must be included in the configuration process to facilitate effective knowledge transfer. Additionally, the Bidder must demonstrate the configured software to validate the configuration against DSHS’ documented requirements and agreed-upon business processes or practices.

To facilitate this activity, the Bidder shall be responsible for developing and maintaining a configuration management plan to ensure the integrity of change control of all project documents, software, and technical environments commonly provided in a project life cycle process.

The Configuration Management Plan shall include, but is not limited to:

5.1.4.1 Methods used to manage the configuration process


5.1.4.2 Sources of information

5.1.4.3 The progression of configuration values from initial prototyping through testing to production

5.1.4.4 Configuring required third-party applications acquired by DSHS; and

5.1.4.5 Applying all upgrades and patches released by the software providers

5.1.4.6 Managing changes to configuration throughout the project lifecycle

5.1.4.7 Ensuring project deliverables, documents, and other documentation subject to change throughout the engineering lifecycle are updated to reflect configuration changes

5.1.4.8 Ensuring that work is not performed on out-of-scope features, functions, or tasks until DSHS grants authorization in writing

5.1.4.9 Software change control procedures with procedures and/or automated tools that will be employed to ensure the integrity of programs and configuration settings developed to support the systems

5.1.4.10 How the application being migrated will be updated to match the production version of the code, including all implemented change requests (CRs) and problem reports (PRs)

5.1.5 System Security Plan

The Bidder, in collaboration with DSHS, shall develop a comprehensive System Security Plan for meeting security standards and following procedures at the hardware, application, database, network and user levels in accordance with the State’s Enterprise Security Policy (Appendix L), IRS (IRS Publication 1075, Exhibit 7) and any Federal security policies that may apply.

5.1.6 Change Management Plan

The Bidder shall provide change management leadership throughout all phases of the project. The change management approach shall be documented in a comprehensive Change Management Plan to be developed by both Parties in compliance with DSHS’ Change Order Process (see Attachment A Sample Contract, Special Terms and Conditions Item 11). The Change Management Plan must document the approach and methodology for planning and performing change


management activities, including change control processes with standards and procedures for handling and processing Change Requests (CRs) and Problem Reports (PRs) that may occur during the course of the implementation project.

5.1.7 Requirements Management Plan

The Bidder shall develop a comprehensive plan for managing all project requirements (functional and non-functional) in a Requirements Traceability Matrix (RTM) that is maintained and accessible to the project team at all times. The RTM must include complete traceability through requirements analysis, design, development, testing, integration, training, and implementation. This Requirements Management Plan must include the process and procedures that will be followed for any requirements that are added, modified or removed from scope. Additionally, the Requirements Management Plan must describe the escalation process that will be followed during go/no-go decisions for each phase of the project should there be differences of opinion in the interpretation and completion of each requirement.

5.2 Analysis and Detailed Systems Review/Inventory Phase

The Bidder shall conduct a thorough analysis of the existing ACES components and applications, identifying and assessing other potentially impacted applications, evaluating impacts and benefits associated with findings, evaluating quality and suitability of current and new data sources, and any recommendations for improvement.

The Bidder shall perform an analysis and inventory of existing ACES components and applications, including but not limited to, ACES, ACES Online, Washington Connection, Eligibility Service and Data Warehouse.

5.2.1 Systems Inventory

The Bidder shall provide a detailed Systems Inventory of all systems required to be migrated as well as third party services used by the applications that must be tested on the new platform. This inventory will include all application components inclusive of programs, Job Control Language (JCL), documents, reports, and third party interfaces to be migrated including middleware connectivity components to the existing document management system.

This inventory will delineate all costs associated with applications, hardware and software to be included in the new environment. The Bidder shall provide installation and configuration for all products identified in the systems inventory that are to be installed or migrated during the Rehosting Phase.


5.2.2 Interfaces Replication Plan

The Bidder shall be responsible for validating current interfaces to all mainframe applications in the scope of the project. The Contractor shall replicate all existing interface functionality.

5.2.3 Technical Environment Assessment Report

The Bidder shall recommend a hardware sizing and architecture based on the ACES applications to be migrated and to accommodate anticipated future growth. In this report, the Contractor shall:

5.2.3.1 Provide a list of required software, hardware and support for each option, including the associated costs

5.2.3.2 Perform capacity planning with an overall assessment of the sizing of production; infrastructure hardware, systems software, and data storage to support the various environments

5.2.3.3 Provide recommendations to DSHS on the technical architecture and infrastructure design

5.2.3.4 Identify a standard technical infrastructure configuration for the various environments

5.2.3.5 Recommend the software installation to support the Contractor’s environments for design, configuration, and testing using the certified software installed

5.2.3.6 Provide complete hardware sizing and architecture to address environments for release updates, training, development, testing, and production with the test and production environments being equivalent or practically equivalent for testing purposes

5.2.3.7 Document how the proposed technical architecture design fits within the current network security architecture, composed of unique logical areas separating development/test environments from production environments

As part of the Technical Environment Assessment Report the Bidder shall describe the following requirements:

5.2.3.8 Hardware for configuration, design, and development

5.2.3.9 Hardware for testing in a production equivalent environment


5.2.3.10 Structure and maintenance of planned database instances/environments

5.2.3.11 Tools necessary for managing and monitoring the hardware/software environments

5.2.3.12 Methodology and potential toolset for encryption of data at rest and transit

5.2.3.13 Methodology and potential toolset for log management

5.2.3.14 Disaster recovery recommendations

5.2.3.15 Backup and recovery/business continuity

5.2.3.16 Set-up and administration of environments that may be required for:

5.2.3.16.1 RELS: Development and unit testing environment

5.2.3.16.2 DEVL: Integration testing environment, also the environment where static code analysis and secure code analysis will be conducted

5.2.3.16.3 SYTST: System test environment used by DSHS Testers for both manual and automated testing

5.2.3.16.4 UACPT: User Acceptance Test environment

5.2.3.16.5 HBE-U: User Acceptance environment exclusively for coordinated testing of MAGI, Eligibility Service and the Healthplanfinder

5.2.3.16.6 TRAIN: Training environment

5.2.3.16.7 PROD: Production environment

5.2.3.16.8 DW: Data Warehouse/Reporting

5.2.4 Assessment Presentation

Upon completion of the Initiation and Analysis and Detailed Systems Review/Inventory Phases, the Bidder shall present a summary of their findings including identification and assessment of potential


risks and issues of the project and recommended actions to avoid, transfer, mitigate, or manage those risks and issues throughout the life of the project.

5.2.5 Preliminary Disentanglement and Exit Plans

The Bidder shall document its disentanglement and exit planning approach including identification of transition responsibilities, descriptions and schedule for required tasks to ensure an efficient and effective transition from the Bidder with minimal disruption to operations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plan. During execution of the approved Disentanglement and Exit Plan, the Exit Team (comprised of State staff, the Bidder, and other affected service providers) shall meet regularly to review and update the Disentanglement and Exit Plans to reflect revisions to schedules, resource requirements, dependencies, priorities and all other obligations under Sample Contract Exhibit D – Disentanglement and Exit Plan.

Without limiting the Bidder’s obligations under its Agreement with DSHS, the Bidder will meet its obligations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plans including, but not limited to:

5.2.5.1 Cooperate with DSHS, its Affiliates and/or the Replacement Contractor by promptly taking all steps required to assist DSHS in completing the Disentanglement related to the Services it had previously performed.

5.2.5.2 Provide DSHS, its Affiliates and/or the Replacement Contractor with all nonproprietary information regarding the Services that these parties will need to perform the Disentanglement. This information includes, without limitation, data conversions, interface specifications and data about related professional services.

5.2.5.3 Promptly and orderly conclude all work that DSHS may direct the Bidder to do. This may include the documentation of work in progress and other measures to provide an orderly transition to DSHS, its Affiliates and/or the Replacement Contractor.

5.2.5.4 Accomplish the other specific obligations described in Sample Contract Exhibit D – Disentanglement and Exit Plans.

The Bidder shall maintain updated Disentanglement and Exit Plans throughout the project with formal presentation and approval occurring at the end of the Analysis and Detailed Systems Review/Inventory Phase in the form of Preliminary Disentanglement and Exit Plans; at the end of the Deployment Phase in the form of Mid-term Disentanglement and Exit Plans and at the end of the


Close-Out/ Maintenance and Operations Phase in the form of Final Disentanglement and Exit Plans pursuant to the Cost Proposal outline in Sample Contract Exhibit C – Fees and Payment Terms.

5.3 Platform Design Phase

The Bidder shall obtain written acceptance of all Initiation Phase and Analysis and Detailed Systems Review/Inventory Phase Deliverables, written agreement on the chosen architecture platform, and confirmation that DSHS is ready to proceed with the Design Phase before proceeding with any of the deliverables and activities listed below.

During the design phase, the Bidder shall work closely with DSHS’ Project Team and review design specifications in order to meet all of DSHS’ requirements. These design specifications shall encompass all components of work to be performed and include software configuration, customizations, interfaces, data warehouse design, queries and reports, workflow, security, and data conversion as stipulated below.

5.3.1 Security Design Document

The Bidder shall complete a security design that includes definition of application security roles, profiles and permissions.

5.3.2 Identity Management Document

The Bidder shall document its plan for integrating its solution with the current identity management methodology. The Bidder shall outline for each layer (network, servers, applications, etc.) of access what software, methodologies, and procedures will be used to provide identity management.

5.3.3 Interfaces Design Document

The Bidder shall design, document and deploy a set of standard inbound and outbound interfaces for processing transactions that will be replaced by the new system. There shall be no changes made to existing external interfaces to/from the legacy systems. The Contractor shall be responsible for documenting existing and potential interfaces required between the system and other agency-specific legacy administrative systems that will remain in production use as well as interfaces to other external entity systems. The Contractor shall also describe the necessary integration points for third-party software with the system.

5.3.4 Data Conversion/Migration Design Document

The Contractor shall produce a comprehensive data conversion design that details all aspects of creating the conversion routines and database environments necessary to take the system ‘live’. The Contractor shall clearly identify any data tasks for which DSHS is


responsible. The Contractor’s Data Conversion/Migration Design Document shall include, but not be limited to:

5.3.4.1 All data to be converted, migrated, loaded, or entered in the new system

5.3.4.2 Data sources

5.3.4.3 Expected data volumes

5.3.4.4 Conversions where automated programming can be used to significantly reduce data conversion labor

5.3.4.5 Roles, responsibilities and timing requirements for the conversion effort

5.3.4.6 Extract, transformation and load methods to be used

5.3.4.7 Detailed specifications required to develop the data conversion programs for converting data from the legacy system to the new system

5.3.4.8 Any required data conversion procedures for entering manually converted data into the new system

5.3.4.9 Data cleansing edits and quality assurance validation steps that need to be performed before and/or during the conversion process

5.4 Platform and Application Migration Phase

During the platform and application migration, the Contractor shall be responsible for configuring, customizing and enhancing all application software as needed in accordance with approved design specifications.

During this phase of work, the Contractor shall be responsible for the unit, integration, regression and performance testing of all application software, acceptance test planning, and disaster recovery planning and provide the following deliverables and associated services.

5.4.1 Test Plan

The Contractor shall develop a comprehensive Test Plan deliverable inclusive of test scripts and data for each activity of testing. All proposed test plans shall be reviewed and approved by DSHS prior to the initiation of that testing activity.


The Contractor’s Test Plan shall include testing for, but not be limited to:

5.4.1.1 Systems/Integration

5.4.1.2 Data Conversion

5.4.1.3 User Acceptance

5.4.1.4 Performance (load/stress)

5.4.1.5 Regression/Parallel Testing

5.4.1.6 Interfaces

5.4.1.7 The Contractor shall be responsible for the testing and activities to be undertaken, and the tools and techniques to be used. The Contractor shall document all required environments, platforms, and procedures necessary for establishing the testing environment for all activities of testing including deadlines and identifying associated responsibilities of DSHS.

5.4.1.8 The Test Plan shall include training to DSHS on the testing tools used to facilitate the testing process.

5.4.1.9 The Contractor shall be responsible for all aspects of verifying and documenting interfaces, real-time and batch.

5.4.1.10 DSHS and its Independent Verification and Validation (IV&V) vendor will be responsible for conducting the acceptance testing with the assistance of the Contractor. The Contractor shall provide, based on their experience, what resources from DSHS will be needed to complement the Contractor’s testing. As part of this effort, the Contractor shall build any crosswalk file structures required in developing test scenarios and conducting acceptance testing, and collaborate with DSHS staff to populate the crosswalk tables.

5.4.1.11 The Contractor shall provide a letter certifying that the programs utilized for conversion have been properly tested and are fit for the task of performing the conversion into the System.


5.4.2 Knowledge Transfer and Training Plan

5.4.2.1 The Contractor shall develop a comprehensive Knowledge Transfer Plan that delineates knowledge transfer goals and objectives for State and contracted personnel at all levels. The knowledge transfer plan shall be based on a comprehensive needs assessment conducted by the Contractor and shall describe the types of training to be provided to meet the identified needs.

The Contractor shall plan and execute a comprehensive training program for DSHS encompassing a diverse array of training options during this phase of work. While formal training will form part of the overall mix of training services required to train State and contracted personnel, a more complete knowledge transfer approach that supplements training with carefully selected hands-on experience during the Deployment is also required. The Contractor shall provide a knowledge transfer approach that will ensure DSHS and contracted resources have a “critical mass” of knowledgeable personnel (user experts, system administrators, programmers and other technical personnel) sufficient to operate and maintain the system independently of the Contractor. A key requirement for success in this area will be the acquisition of skills via DSHS’ participation in producing key functional and technical deliverables, including software modifications and configuration changes, under the supervision and instruction of experienced Contractor Personnel.

5.4.2.2 The Contractor shall ensure that, as a part of the knowledge transfer strategy, an effective mentoring program is developed for key State personnel. The Contractor’s knowledge transfer strategy shall actively involve the mentoring of State personnel throughout the project life cycle to ensure that DSHS’ personnel are prepared to operate and maintain the system at go-live.

5.4.3 Disaster Recovery Plan

The Contractor shall develop and document Disaster Recovery Plan options, including estimated costs, for the production environment.

5.4.4 Configuration Management Document

The Contractor shall configure and document the software configurations, as described in the Configuration Management Plan, by performing all activities necessary to meet DSHS’ requirements and documenting post-implementation configuration.

5.4.5 Security Configuration Document

The Contractor shall be responsible for configuring, documenting, and maintaining the application security roles, profiles, and


permissions. The Contractor shall document all post-implementation security configuration.

5.4.6 Interfaces Document

The Contractor shall complete all work outlined in the Interfaces Design Document and document all post-implementation interfaces.

The Contractor shall migrate all on-line and batch interfaces to the new platform and document all post-implementation on-line and batch interfaces and related processes.

5.4.7 Data Conversion

Based on DSHS’ approved Data Conversion Plan, the Contractor shall create, test, and document automated conversion programs to support the commencement of live operations. The Contractor shall provide quality assurance during the conversion and archiving processes to ensure data quality and preserve performance optimization.

The Contractor shall run the conversion programs and assisting DSHS with the verification of the converted data in the required environments including the Enterprise Data Warehouse (eDW). DSHS shall assist with loading data that is not converted or loaded automatically and for certifying the production database as being accurate. The Contractor shall adapt and re-run conversion programs as necessary to properly convert and load the data and to maintain a conversion log to track the accuracy of all conversion efforts.

Data conversion activities shall be determined by using the approach that is provided by the Contractor as approved by DSHS.

DSHS shall be responsible for performing all manual conversion processes, with the guidance of the Contractor. Manual conversions will be utilized when the Contractor and State agree that the volume is too low to justify the cost of developing an automated conversion program.

5.4.8 Readiness Assessment Report

The Contractor shall track activities, issues, and status to ensure that User Acceptance Testing can begin. This readiness assessment shall include, but not be limited to, the migration and control of all software components, completion of prerequisite training, completion of test scripts and data validation, documentation of roles and responsibilities, validation of the appropriate version of the applications, and identification of acceptance testing criteria.

DSHS expects to be a primary participant in the acceptance testing process with assistance from IV&V and the Contractor. Prior to State approval of the software for production use, both user and system acceptance tests shall be successfully completed. State


representatives shall function as system users during system testing and shall evaluate all test outcomes.

5.5 Deployment Phase

DSHS requires an extensive and carefully structured approach to the deployment (“go-live”) of the ACES complex applications. This includes the planning, organization and execution of cutover activities necessary to transition operations to the new platform.

Testing is a critical component of the Deployment activities. All required testing shall be conducted in accordance with DSHS’ accepted and IV&V approved unit, integration, regression and performance test plans developed by the Contractor. The Contractor shall document all test results, analyze exceptions and correct any software defects. All system components will be subjected to testing performed by a Test Team composed of both the Contractor and DSHS staff.

The Contractor shall provide on-site support throughout the entire Deployment period.

5.5.1 Deployment Plan

The Contractor shall document and update the Deployment Plan to reflect all project tasks, activities, roles, responsibilities, dependencies, and milestone events for completing the testing and deployment process that enables DSHS to begin effective use and maintenance of the applications.

The Deployment Plan must include, but not be limited to:

5.5.1.1 The detailed technical preparation activities for each region with the timelines

5.5.1.2 The detailed system changeover activities for each region with the timelines

5.5.1.3 Development of a migration activities check list, including updating of the code conversion for all changes made since the most recent release

5.5.1.4 Staffing requirements, by role and responsibilities, for both the Contractor and DSHS personnel for all migration activities

5.5.1.5 The detailed migration schedule with all migration activities

5.5.1.6 Activities required to effectively operate and maintain the applications and all hardware and software


5.5.1.7 Assumptions for any code freeze and the expected duration and timing of the freeze

5.5.1.8 A critical component of the Deployment Plan is the inclusion of a Contingency Plan component for mitigating and resolving risks that are identified as potentially impacting deployment. The Contingency Plan component will address the strategies for business and system continuity planning as a result of migration issues. For each risk identified, the Contingency Plan shall include one or more alternate solutions that are acceptable to DSHS. The Contractor shall be responsible for executing the Contingency Plan as issues arise during migration, upon approval of DSHS.

5.5.2 Implementation Support Plan

The Contractor shall develop and document an Implementation Support Plan describing plans, processes, forums, activities, and procedures for providing user support from the outset of the deployment activities through the end of the post-implementation period.

5.5.3 Technical Documentation

The Contractor shall provide comprehensive technical documentation that describes, but is not limited to, the application software, middleware, any third-party application software and its architecture (e.g., implementation view of the application architecture). This documentation will include but not be limited to a guide to all software source code, programs, and executables, as well as a comprehensive data model. Where customizations have been made, the technical documentation must include, but not be limited to, a detailed data dictionary, entity-relationship diagrams, and a tool for keeping the data dictionary current. The Contractor shall maintain this documentation to reflect changes made throughout the project.

Technical documentation shall also include, but not be limited to all customization/configuration parameters used at DSHS as well as the full range of alternative values possible (and the effect of each value). The documentation shall reference all parameters and note and explain where dependencies occur and where environmental conditions dictate specific usage and settings.

5.5.4 Operations Documentation

The Contractor, in collaboration with DSHS’ Production Control Team, shall provide operations documentation that includes, but is not limited to, overviews of the application, system structure, major processing, required interfaces, performance monitoring, processes to support as-needed load and stress testing, report documentation, maintenance tasks, correspondence documentation and Process and Procedures Manual. The operations documentation shall also describe the overall batch or background process schedule, including


dependencies, sequencing, and timing. If there are any workstation-based components to any of the proposed software products and solutions, the Contractor shall provide the State with a set of documented procedures and automated deployment/installation scripts for use with DSHS’ software distribution tools. These scripts and procedures will enable DSHS staff to independently install and connect additional workstations.

5.5.5 Knowledge Transfer, Training Schedule, Curriculum and Materials

The Contractor shall develop, disseminate, and maintain on-going training schedules, curriculum, and materials post-implementation for State employees and contracted resources.

5.5.6 Data Conversion Report

The Contractor shall document that all data conversion activities have been successfully completed and all migrated data conforms to the original source data.

5.5.7 Knowledge Transfer and Training Report

The Contractor shall document the verification of successful knowledge transfer and training outcomes.

5.5.8 User and System Acceptance Test Report

The Contractor shall describe the results of the User and System Acceptance Testing activity to validate that all deficiencies have been corrected and the testing is successful.

5.5.9 System Performance and Tuning Report

The Contractor shall document all system performance changes made to the system by all means, including but not limited to tuning databases, application servers, web servers, and other software and devices deployed as part of the solution. The Contractor shall validate that the migrated application maintains or improves upon pre-migration transaction response times.

5.5.10 Production Deployment Readiness Certification

The Contractor shall provide a Certification letter to confirm:


5.5.10.1 All applicable DSHS personnel have completed training

5.5.10.2 All data has been converted, cleaned and accepted by DSHS

5.5.10.3 All site preparation requirements have been met

5.5.10.4 All user support is established

5.5.10.5 All user and system supports are in place

Once DSHS has provided written approval for the system’s production deployment readiness, the Contractor shall work with DSHS to establish a production cutover procedure.

5.5.11 Production Cut-Over Procedure

This procedure requires that the Contractor move all system components in a systematic fashion into the production environment. The Contractor shall ensure that the source code, compiled modules (where required), job streams, other components of the production environment, and all documentation are ready and organized for the production cutover. The Contractor shall ensure that all compiled extension programs have corresponding source code and ensure that all programs are present.

DSHS shall ensure that all components and modules of the production environment can be operated on-line to completion as appropriate, and that all modules, job streams (or scripts) are documented in detail according to the agreed upon standards.

5.5.12 Mid-Term Disentanglement and Exit Plans

The Contractor shall document its disentanglement and exit planning approach including identification of transition responsibilities, descriptions and schedule for required tasks to ensure an efficient and effective transition from the Contractor with minimal disruption to operations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plan. During execution of the approved Disentanglement and Exit Plan, the Exit Team (comprised of State staff, the Contractor, and other affected service providers) shall meet regularly to review and update the Disentanglement and Exit Plans to reflect revisions to schedules, resource requirements, dependencies, priorities and all other obligations under Sample Contract Exhibit D – Disentanglement and Exit Plan.

Without limiting the Contractor’s obligations under its Agreement with DSHS, the Contractor will meet its obligations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plans including, but not limited to:


5.5.12.1 Cooperate with DSHS, its Affiliates and/or the Replacement Contractor by promptly taking all steps required to assist DSHS in completing the Disentanglement related to the Services it had previously performed.


5.5.12.3 Promptly and orderly conclude all work that DSHS may direct the Contractor to do. This may include the documentation of work in progress and other measures to provide an orderly transition to DSHS, its Affiliates and/or the Replacement Contractor.

5.5.12.4 Accomplish all other specific obligations described in Sample Contract Exhibit D – Disentanglement and Exit Plans.

The Contractor shall maintain updated Disentanglement and Exit Plans throughout the project with formal presentation and approval occurring at the end of the Analysis and Detailed Systems Review/Inventory Phase in the form of Preliminary Disentanglement and Exit Plans; at the end of the Deployment Phase in the form of Mid-term Disentanglement and Exit Plans and at the end of the Close-Out/ Maintenance and Operations Phase in the form of Final Disentanglement and Exit Plans pursuant to the Cost Proposal outline in Sample Contract Exhibit C – Fees and Payment Terms.

5.6 Continuing Modernization Recommendations

Upon completion of the Rehosting Phase, the Contractor shall provide recommendations for the continued modernization of the legacy system.

5.6.1 Continuing Modernization Recommendations Report

The Contractor shall perform an assessment of the risks and issues related to the legacy system and document recommendations for modernization covering, but not limited to, the following areas:

5.6.1.1 Database modeling and redesign, providing DSHS with suggested standards, staff skills, roles and responsibilities,


tools, software, repositories, processes, best practices and governance

5.6.1.2 Infrastructure/systems reengineering, providing recommendations to DSHS on the future infrastructure/systems reengineering needs

5.6.1.3 Utilization of a modern rules engine, providing recommendation to DSHS on the modern rules engine that will support state and federal rules which can be used on any platform

5.6.1.4 Security monitoring/compliance/enhancements, providing recommendation to DSHS on the tools, software that are required to meet federal and state security policies

5.6.1.5 Batch processing, providing recommendations to DSHS for developing a more robust batch processing approach Resources, skills and experience – current and future needs

5.7 Close-Out Phase

The Contractor shall provide on-site post-implementation support for a period of six (6) months following Steady State with one (1), (2) two-year optional extension. In its Post-Implementation Maintenance and Support Plan, the Contractor shall specify the number of full time equivalent (FTEs) Contractor staff that will need to be dedicated to the maintenance and support activities. The on-site presence is needed to maintain a stable production environment and to provide for a smooth turnover of system responsibility to DSHS. The post-implementation support shall consist of technical, end-user, and operational support. Post-implementation support shall be provided by Contractor Personnel who have the requisite qualifications to provide the necessary support and have experience with the project throughout the course of the implementation effort. DSHS personnel shall assist during this period in providing ongoing user support to address operational problems and answer questions (e.g., system access, security profiles, program bugs, instruction in the use of the system).

5.7.1 Post-Implementation Maintenance and Support Plan

The Contractor shall provide a plan that documents the process, procedures, and governance organization to identify, evaluate, prioritize, and document recommended system defect fixes, software maintenance patches, minor enhancements, and table changes.

The Post-Implementation Maintenance and Support Plan shall include, but not be limited to:


5.7.1.1 Providing user support during the post-implementation maintenance and support period

5.7.1.2 Staffing and organization: Establish a methodology and structure to manage and support the system environments with the appropriately skilled people, tools and procedures

5.7.1.3 Staff training: Establish training procedures for on-going system maintenance and operations

5.7.1.4 incident process: Create a process to report, track, assess and prioritize rehosted system incidents utilizing the DSHS provided tools

5.7.1.5 Incident resolution: Establish a process to evaluate, escalate, and respond to the reported incidents. Execute the process for all incidents including on-call escalation services for critical incidents during and after regular working hours

5.7.1.6 Problem tracking and resolution: Establish a procedure to document, track, prioritize, resolve, and report on problems

5.7.1.7 Assumption of partial user support responsibility by DSHS personnel by the end of the post-implementation maintenance and support period

5.7.2 Disentanglement and Exit Plans - Final

The Contractor shall document its disentanglement and exit planning approach including identification of transition responsibilities, descriptions and schedule for required tasks to ensure an efficient and effective transition from the Contractor with minimal disruption to operations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plan. During execution of the approved Disentanglement and Exit Plan, the Exit Team (comprised of State staff, the Contractor, and other affected service providers) shall meet regularly to review and update the Disentanglement and Exit Plans to reflect revisions to schedules, resource requirements, dependencies, priorities and all other obligations under Sample Contract Exhibit D – Disentanglement and Exit Plan.

Without limiting the Contractor’s obligations under its Agreement with DSHS, the Contractor will meet its obligations pursuant to Sample Contract Exhibit D – Disentanglement and Exit Plans including, but not limited to:

5.7.2.1 Cooperate with DSHS, its Affiliates and/or the Replacement Contractor by promptly taking all steps required to assist


DSHS in completing the Disentanglement related to the Services it had previously performed.


5.7.2.3 Promptly and orderly conclude all work that DSHS may direct the Contractor to do. This may include the documentation of work in progress and other measures to provide an orderly transition to DSHS, its Affiliates and/or the Replacement Contractor.

5.7.2.4 Accomplish the other specific obligations described in Sample Contract Exhibit D – Disentanglement and Exit Plans.

The Contractor shall maintain updated Disentanglement and Exit Plans throughout the project with formal presentation and approval occurring and the end of the Analysis and Detailed Systems Review/Inventory Phase in the form of Preliminary Disentanglement and Exit Plans; at the end of the Deployment Phase in the form of Mid-term Disentanglement and Exit Plans and at the end of the Close-Out/ Maintenance and Operations Phase in the form of Final Disentanglement and Exit Plans pursuant to the Cost Proposal outline in Sample Contract Exhibit C – Fees and Payment Term

5.7.3 Process and Procedures Manual

The Contractor shall develop and continuously update a detailed, DSHS-specific Process and Procedures Manual. The Process and Procedures Manual shall include, but not be limited to, operations manuals, user guides, quick reference, specifications, and end-user support information that provide the details of such activities so that a similarly skilled resource can repeatedly and reliably produce the same result. The Process and Procedures Manual shall also describe the activities necessary to comply with all applicable laws and regulations including, without limitation, those relating to the privacy and security of DSHS Data, including Sarbanes-Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLB) and any other laws and regulations applicable to DSHS Data and/or identified by DSHS. The Process and Procedures Manual shall describe how the Services will be performed and act as a guide to End-Users seeking assistance with respect to the Services offered hereunder. The Process and Procedures Manual shall in no event be interpreted as relieving the Contractor of any of its performance obligations under the Services to be performed.


The Contractor shall deliver the first draft of the Process and Procedures Manual to DSHS for its review, comments and approval within the time frame set forth in the Exit Plan and shall, with respect to each draft of the Process and Procedures Manual, incorporate all of DSHS’ comments and suggestions. Not later than thirty (30) calendar days following completion of all activities under the Exit Plan, the Contractor shall deliver an updated draft of the Process and Procedures Manual to DSHS for its review, comments and approval and thereafter shall periodically update the Process and Procedures Manual to reflect changes in the operations or procedures described therein. All such updates to the Process and Procedures Manual shall be provided to DSHS for its prior review, comments and approval.

5.7.4 Exit Plan Progress Report

The Exit Team shall summarize the progress on the Exit Plan to date. The Contractor shall be required to work cooperatively and expeditiously to transfer the existing responsibilities to DSHS or another service provider. The Exit Plan Progress Report shall document the conditions existing at the date of formal hand-off between Contractor and DSHS personnel, including any identified issues that may require contingent follow-up by the Contractor.

5.7.5 Project Lessons Learned and Final Report

The Contractor shall identify and document lessons learned from the project to assist DSHS in continuing to support the implemented system, and to undertake similar projects in the future.

6. Bidder and Staff Minimum Requirements

A Minimum Requirement is an essential DSHS need that must be met by the Bidder. Mandatory requirements are scored as pass or fail based on the presence of the required experience. Mandatory requirements will also be scored with a numeric score (from 0-5) based on the quality of the Bidder response. Bidder/Staff not fulfilling ALL mandatory requirements will be disqualified from the solicitation process.

6.1 Bidder Requirements

All Bidders shall meet/provide the following minimum requirements:

6.1.1. The Bidder shall have conducted at least three (3) successful engagements of similar or larger scope and complexity as this Statement of Work and shall provide at least three (3) of these engagements as reference projects. The Bidder shall describe these reference projects in detail, including contact information.

6.1.2. The Bidder shall provide a description of its experience in the performance of similar engagements to manage, plan, design, develop, and implement successful efforts that meet the criteria of this Statement of Work. The bidder shall clearly describe the scope and scale of those engagements.


6.1.3. The Bidder shall provide a corporate description with sufficient documented information about the bidder organization to substantiate proven expertise in the products and services being requested in this RFP.

6.1.4. The Bidder shall disclose any company restructurings, mergers, and acquisitions over the past five (5) years or planned to occur during the course of this project.

6.1.5. The Bidder shall specify the location of the organization’s principal office and the number of executive and professional personnel employed at this office.

6.1.6. The Bidder shall state the number of years the Bidder has been providing similar products and services to those being proposed.

6.1.7. The Bidder shall specify the organization’s size in terms of the number of full-time employees, the number of contract personnel used at any one time, the number of offices and their locations, and structure (for example, state, national, or international organization).

6.1.8. The Bidder shall provide the name and the state of incorporation, if incorporated.

6.1.9. DSHS anticipates that the Bidder may have different subcontractors based on the Phase of the project. The Bidder shall identify in its proposal, all known subcontractors for the Assessment and Rehosting Phases. The Bidder shall describe the proposed roles and responsibilities of each, and provide at least three (3) references for each.

6.1.10. The Bidder shall briefly summarize the subcontractors (if any) and their reference projects. The bidder should explain the history of the relationship, its longevity and the results of the collaboration. In addition, if the Bidder does not plan to use subcontractors then the Bidder shall respond “No subcontractors”.

6.1.11. The Bidder shall describe their standard project management methodology, the proposed project management approach for this project, and any tailoring of their standard methodology anticipated for this project.

6.2 Staff Requirements

The Bidder shall meet/provide the following minimum requirements

6.2.1. The Bidder shall provide an organizational chart identifying all personnel proposed for each Phase of the project.

6.2.2. The Bidder shall identify all “Bidder Personnel” roles (e.g. System Architect, Database Administrator, Functional Lead, Test Lead, and Security Expert) that are key to the success of each Phase of the Project.


6.2.3. The Bidder shall provide an explanation of the responsibilities for each role and an estimated percentage for that role by Project Phase.

6.2.4. The Bidder must agree that the Project Manager shall be available to work onsite for the duration of the project.

6.2.5. The Bidder shall indicate that all proposed Bidder Personnel have performed significant roles in at least one (1) project of similar size and scope in the last two (2) years that migrated enterprise z/OS infrastructure inclusive of applications, toolsets, utilities, and databases to a distributed platform.

6.2.6. The Bidder shall provide a resume for all Bidder Personnel proposed for this project. Resumes shall reflect qualifications and recent experience relevant to the scope of the work indicated in this RFP. Resumes shall include at least three (3) references that can be directly contacted to verify the individual’s qualifications and experience. Resumes shall include the office location of each person.

6.2.7. The Bidder shall designate in the Bidder response form, that each staff member assigned to this project has the ability to communicate clearly in the English language both verbally and in written form.

6.2.8. The Bidder shall agree, in the Bidder response form, that any Bidder initiated changes to Bidder Personnel (as identified in Bidder’s response to this RFP) will be subject to prior DSHS approval and that DSHS may request that the Bidder, without impacting the schedule, remove selected staff on three (3) days’ notice and provide replacement staff.

6.3 Service Location Requirements

6.3.1. Work will be performed in Olympia, Washington at Economic Services Administration headquarters, Capital View 2 building located at 724 Quince St SE Olympia, WA 98501, and other locations in Thurston County, as necessary. The Bidder’s Project Manager will be required to be on-site during core business hours, 8:00 a.m. to 5:00 p.m. Monday through Friday for the duration of the project. Other Bidder Personnel must be available as required during core business hours but do not have to be on-site at all times.

6.3.2. This project is envisioned to be a full time effort. DSHS anticipates the project team members will dedicate an estimated 40 billable hours per week per person to the project for the project duration. In addition to core business hours, Bidder Personnel may be required to be on-site to address problems, assist in processes, or any other critical business need.

6.3.3. DSHS does not allow the use of offshore personnel in any capacity

due to data access restrictions.

6.3.4. DSHS agrees to provide standard workspace for the Bidder Personnel. The standard workspace includes a desk with chair and


hardware (desktop PC, telephone, etc.), business productivity software, and normal supplies required to perform the functions in this Work Request. Special equipment, software, supplies required for Bidder resource accommodations must be provided by the Bidder.

6.3.5. A security badge is required and will be provided to the Bidder’s personnel for access into the work area and for agency computer access when necessary. The Bidder’s personnel will be required to complete a non-disclosure agreement and annual Security Awareness training prior to starting work.

7. Period of Contract Performance

DSHS intends to award one Contract for the Services described in this Competitive Solicitation. The period of performance under the Contract shall be for a period of twenty-four (24) months. The term of the contract may be extended by amendment for up to (1) one additional (2) two-year period at the sole discretion of DSHS. Additional services that are appropriate to the scope of this Solicitation, as determined by DSHS, may be added to the Contract in a mutually agreeable amendment. As a federally funded project, the contract and any amendments must be approved by Centers for Medicare and Medicaid Services (CMS) before execution, which can take up to 60 days.

• DSHS has allocated up to eighteen (18) months for completion of the services and deliverables outlined in the Statement of Work.

• DSHS requires six (6) months of post-implementation support and maintenance.

8. Funding

DSHS has budgeted an amount not to exceed $8.95 Million for this Project. DSHS will reject any Response in excess of the not to exceed amount. Any Contract awarded is contingent upon the availability of funding.

9. Payment and Holdback

The contract resulting from this Solicitation will be a fixed fee deliverables based contract. Payment shall be made on a monthly basis dependent upon DSHS’ review and acceptance of the monthly executive summary report. For the monthly executive summary report to be accepted the report must reflect the status of all work items scheduled to be completed during that reporting period, according to the project schedule. Each item scheduled to be completed must be designated either as incomplete or certified by the vendor to be complete. Upon acceptance of the monthly report DSHS will pay eighty-five percent (85%) of the agreed upon monthly payment. DSHS will hold back fifteen percent (15%) of each monthly payment amount. For the base period, holdback will be paid in full ninety (90) days following the Implementation Steady State date, if all deficiencies have been resolved and no new major issues or concerns have been documented by DSHS (See * in Figure 1 below). For the maintenance and operations period, holdback will be paid in full ninety (90) days following the end of the six (6) month maintenance and operations period, if all deficiencies have been resolved and no new major issues or concerns have been documented by DSHS (See ** in Figure 1 below).


DSHS is allocating up to eighteen (18) months for completion of the services and deliverables as outlined in the Statement of Work. If the work is completed in less than eighteen (18) months, DSHS will continue to pay the Bidder monthly according to the agreed upon payment schedule or may, at its discretion, pay the balance as one lump sum. DSHS is requiring a six (6) month maintenance and operations period to commence immediately upon DSHS acceptance of the system implementation and Steady State. DSHS will continue to follow the monthly payment schedule for the six (6) month maintenance and operations period.

Figure 1 – Sample Payment Schedule

Month

Approved Amount

Actual Payment

Holdback

BA

SE

PE

RIO

D

1 $291,666.66 $247,916.66 ($43,750.00)

2 $291,666.66 $247,916.66 ($43,750.00)

3 $291,666.66 $247,916.66 ($43,750.00)

4 $291,666.66 $247,916.66 ($43,750.00)

5 $291,666.66 $247,916.66 ($43,750.00)

6 $291,666.66 $247,916.66 ($43,750.00)

7 $291,666.66 $247,916.66 ($43,750.00)

8 $291,666.66 $247,916.66 ($43,750.00)

9 $291,666.66 $247,916.66 ($43,750.00)

10 $291,666.66 $247,916.66 ($43,750.00)

11 $291,666.66 $247,916.66 ($43,750.00)

12 $291,666.66 $247,916.66 ($43,750.00)

13 $291,666.66 $247,916.66 ($43,750.00)

14 $291,666.66 $247,916.66 ($43,750.00)

15 $291,666.66 $247,916.66 ($43,750.00)

16 $291,666.66 $247,916.66 ($43,750.00)

17 $291,666.66 $247,916.66 ($43,750.00)

18 $291,666.66 $247,916.66 ($43,750.00)

* Base period holdback payment $787,500.00

M&

O P

ER

IOD

19 $291,666.66 $247,916.66 ($43,750.00)

20 $291,666.66 $247,916.66 ($43,750.00)

21 $291,666.66 $247,916.66 ($43,750.00)

22 $291,666.66 $247,916.66 ($43,750.00)

23 $291,666.66 $247,916.66 ($43,750.00)

24 $291,666.66 $247,916.66 ($43,750.00)

** M&O period holdback payment $262,500.00

TOTAL $7,000,000.00 $5,950,000.00 $1,050,000.00


SECTION B

DEFINITIONS

Additional definitions for Contract-specific terms are found in the Sample Contract set forth as Attachment A to this Solicitation and shall apply to those terms as they are used in this Solicitation. The following terms have the meanings set forth below:

Agency or DSHS – The Washington State Department of Social and Health Services.

Amendment – A unilateral change to the Solicitation that is issued by DSHS at its sole discretion and posted on WEBS.

Apparent Successful Bidder (ASB) – A Bidder submitting a Response to this Solicitation that is evaluated and is identified and announced by DSHS as providing the best value to the Agency. Upon execution of a Contract, the ASB is referred to as the successful bidder or the Contractor.

Authorized Representative – An individual designated by the Bidder to act on its behalf who has the authority to legally bind the Bidder concerning the terms and conditions set forth in this Solicitation and related documents.

Bid - An offer, proposal or quote for goods or services and all related materials prepared and submitted by a Bidder in response to this Solicitation. The terms Bid, Quotation, Response and Proposal are all intended to mean the same thing.

Bidder – An individual, organization, public or private agency or other entity submitting a bid, quotation, response or proposal in response to this Solicitation.

Contract – A written agreement entered into between a successful Bidder and DSHS as a result of this Solicitation.

Complaint – A process that may be followed by a Bidder prior to the deadline for bid submission to alert DSHS of certain types of asserted deficiencies in the Solicitation.

Coordinator or Solicitation Coordinator – An individual or designee who is employed by DSHS within the DSHS Central Contracts and Legal Services Office and who is responsible for conducting this Solicitation.

Debriefing – A short meeting an Unsuccessful Bidder may request with the Coordinator following the announcement of the Apparent Successful Bidder for the purpose of receiving information regarding the review and evaluation of that Bidder’s Response.

Procurement - The broad process of identifying goods and services for purchase or acquisition, of effectuating the purchase or acquisition, and of managing the purchase or acquisition. This Solicitation is a part of an overall Procurement process. Despite the broader meaning attributed to “procurement”, for purposes of this Solicitation, the terms Solicitation, RFP and Procurement are interchangeable.

Project - The undertaking or work for which contracted Services are being requested pursuant to this Solicitation.

Protest – A process that may be followed by a Bidder after the announcement of the apparent Successful Bidder to alert DSHS to certain types of alleged errors in the evaluation of the Solicitation.


RCW – The Revised Code of Washington. All references to RCW chapters or sections shall include any successor, amended, or replacement statute.

Responsible Bidder – An individual, organization, public or private agency, or other entity that has demonstrated the capability to meet all the requirements of the Solicitation and to meet the elements of responsibility. (See RCW 39.26.160 (2))

Responsive Bidder – An individual, organization, public or private agency, or other entity who has submitted a Bid that fully conforms in all material respects to the Solicitation and all its requirements, in both form and substance.

Scope of Work – The Project or work scope set forth in this Solicitation Document that identifies DSHS’ contractual needs and requirements.

Services – Labor, work, analysis, or similar activities provided by a contractor to accomplish a specific scope of work.

Small Business - An in-state business, including a sole proprietorship, corporation, partnership, or other legal entity, that: (a) certifies, under penalty of perjury, that it is owned and operated independently from all other businesses and has either: (i) fifty or fewer employees; or (ii) a gross revenue of less than seven million dollars annually as reported on its federal income tax return or its return filed with the department of revenue over the previous three consecutive years; or (b) Is certified with the office of women and minority business enterprises under chapter 39.19 RCW.

Solicitation or Competitive Solicitation – A formal process providing and equal and open opportunity for bidders culminating in a selection based upon predetermined criteria. A Competitive Solicitation requests the submission of bids, quotations or proposals for the consideration of DSHS in contracting to meet its needs. This RFP is a Solicitation.

Solicitation Document – This RFP document, including all attachments and all amendments that are issued by the Coordinator.

Statement of Work – The detailed description services to be performed by the Contractor and set forth in the Contract.

Subcontractor – An individual or other entity contracted by Bidder to perform part of the services or to provide goods under the Contract resulting from this Solicitation. Subcontractors, if allowed, are subject to the advance approval of DSHS.

WEBS – Washington’s Electronic Business Solution, the Bidder notification system found at https://fortress.wa.gov/ga/webs/ and maintained by the Washington State Department of Enterprise Services.


SECTION C EXPLANATION OF SOLICITATION PROCESS

Solicitation Schedule

The Solicitation Schedule set forth below outlines the tentative schedule for important events relating to this Solicitation. Except as modified in an Amendment issued by the Coordinator, the dates and times listed through the date of Response Submission are mandatory deadlines. The remaining dates are estimates and may change without the posting of an Amendment. Failure to meet the Response deadline will result in Bidder disqualification.

Item Action Date

1. DSHS posts Competitive Solicitation 06/30/2017

2. Bidder may submit written questions or requests for change in Contract

Requirements until 3:00 p.m. Pacific Time.

07/24/2017

3. DSHS will post responses to written questions. 07/31/2017

4. Bidders may submit written Complaints by 3:00 p.m. Pacific Time (five

business days before Response is Due).

08/14/2017

5. Bidder must submit Response by 3:00 p.m. Pacific Time 08/21/2017

6. DSHS evaluation of written Responses 09/01/2017

7. Oral presentations, if requested by DSHS 09/21/2017

8. Facilities/site assessment dependent on solution proposed, if requested

by DSHS

TBD

9. Announcement of Apparent Successful Bidder(s) on WEBS and beginning

of contract negotiations

09/26/2017

10. DSHS notifies unsuccessful Bidder(s) 09/26/2017

11. Unsuccessful Bidders may request a debriefing conference until 3:00 p.m.

Pacific Time

09/29/2017

12. DSHS holds debriefing conferences, if requested 10/05/2017

13. Deadline for submission of Protests by unsuccessful Bidders who

participated in a debriefing conference

10/12/2017

Posting of Solicitation Documents

DSHS shall post this Solicitation, and all amendments and announcements relating to this Solicitation, on WEBS. WEBS can be accessed at: https://fortress.wa.gov/ga/webs/. In order to inform the largest number of potential bidders about this opportunity, DSHS shall also post documents relating to this Solicitation on the Procurements page of the DSHS website, found at: https://www.dshs.wa.gov/fsa/central-contract-services/procurements-and-contracting All Bidders must register as a Bidder on WEBS, using an appropriate commodities code listed on the front page of this Solicitation, and must download this Solicitation from WEBS.


This should be done as soon as possible in order for Bidder to receive notifications automatically generated on WEBS, but no later than the date set forth on Section C.1., Solicitation Schedule for Announcement of the Apparent Successful Bidder(s).

Amendment, Cancellation/Rejection of Bids, Reissuance of Solicitation

DSHS may amend or add to, retract from or cancel this Solicitation at any time, in whole or in part, and without penalty. DSHS may reject all bids and cancel or rebid this Solicitation. All amendments and notifications of cancellation shall be posted on WEBS. In the event of a conflict between amendments or between an amendment and this Solicitation Document, the document issued latest shall control.

Communications regarding Solicitation

Upon the posting of this Solicitation, all communications concerning this Solicitation must be directed to the Coordinator listed on the cover page of this Solicitation document. With the exception of the Response, which shall be submitted as provided in Section D, Instructions Regarding Content, Format and Submission of Written Responses, communications with the Coordinator shall be sent via email. DSHS may disqualify any Bidder who communicates with anyone in DSHS other than the Coordinator regarding this Solicitation.

DSHS considers all oral communications unofficial and non-binding on DSHS. Bidders shall rely only on written statements issued by the Coordinator.

Questions and Answers

Bidders may send written questions concerning this Solicitation to the Coordinator by the date and time set forth on the Solicitation Schedule in Section C.1. for submission of Questions. Questions shall be sent via email and shall include the number and title of this Solicitation in the subject line.

DSHS may consolidate Bidder questions and shall respond by posting one or more Amendments on WEBS and on the DSHS Procurement website on or around the date specified in the Solicitation Schedule. Only Bidders who have properly registered and downloaded the original Solicitation directly via the WEBS system: https://fortress.wa.gov/ga/webs/ will receive notification of Amendments and other correspondence pertaining to this Solicitation.

Request for Change in Minimum Requirements

If Bidder believes that this Solicitation contains requirements which would unreasonably prohibit or restrict Bidder’s participation, or believes that different requirements would provide better value to DSHS, Bidder shall submit a written explanation of the issue together with proposed alternative requirements to the Coordinator no later than the deadline for Bidder Questions as stated in the Solicitation Schedule set forth in Section C.1. The Coordinator shall not be required to consider requests for changes after this date. If any changes are made to the Solicitation requirements, an Amendment setting forth those changes will be posted on WEBS.

Complaints

In the event a Bidder believes that this Solicitation either: (a) unnecessarily restricts competition; (b) contains an unfair or flawed evaluation or scoring process; or (c) contains


inadequate or insufficient information to permit preparation of a Response, the Bidder shall submit a written complaint to the Coordinator. The Coordinator will forward the complaint to the DSHS Chief of Central Contracts and Legal Services for review. The complaint shall include a proposed remedy and shall be submitted no later than five (5) business days prior to the date when Responses are due. DSHS shall post its response to the Complaint on WEBS and on the DSHS procurement web page. Should a Bidder’s complaint identify a change that would be in the best interest of DSHS to make, DSHS may issue an Amendment modifying this Solicitation. The DSHS decision regarding a complaint is final and no further administrative appeal is available. If no complaint is filed, a Bidder cannot later file a protest based on any of the above complaint criteria.

Minority & Women’s Business Enterprises (MWBE) and Veteran-Owned Business Enterprises

In accordance with the legislative findings and policies set forth in RCW 39.19, 43.60A.200, and 39.29.052, the State of Washington encourages participation by veteran-owned business enterprises and Minority-Owned and Women-Owned Business Enterprises (MWBE), either self-identified or certified by, respectively, the Department of Veterans Affairs or the Office of Minority and Women’s Business Enterprises (OMWBE). While DSHS does not give preferential treatment, it does seek equitable representation from the veterans, minority and women’s business communities.

Participation by veteran-owned and MWBE contractors may be either on a direct basis in response to this Solicitation or as a subcontractor to a contractor. However, no preference will be given in the evaluation of Bids, no minimum level of MWBE or veteran-owned business participation shall be required, and Bids will not be evaluated, rejected, or considered non-responsive on that basis.

Bidders may contact the Office of Minority and Women’s Business Enterprises (OMWBE) at http://www.omwbe.wa.gov/index.shtml and/or the Department of Veterans Affairs at http://www.dva.wa.gov/BusinessRegistry/default.aspx to obtain information on certified firms for potential subcontracting arrangements or for information on how to become certified.

Nothing in this section is intended to prevent or discourage participation from non-MWBE firms or non-veteran-owned businesses.

Auxiliary Aids and Services

DSHS will provide access to this Solicitation document to individuals with disabilities. Please contact the Coordinator to request auxiliary aids and services.

If an individual believes that the Department has discriminated on the basis of a disability, please contact the DSHS Investigations Unit for the Nondiscrimination Policy Brochure and complaint process. The brochure can be found at https://www.dshs.wa.gov/sites/default/files/SESA/publications/documents/Non-discrim%2022-171.pdf

Cost to Prepare Response

DSHS will not be liable for any costs incurred by the Bidder in preparing, conducting a site assessment, or submitting a Response to this Solicitation.


Acceptance of Solicitation Terms

In submitting a Response, Bidder must include a signed Bid Submission Letter in the form set forth on Attachment B, as well as signed Bidder Certifications in the form set forth on Attachment C. Bidder must acknowledge that in submitting a Response, it accepts all terms of this Solicitation Document, including all of its Attachments, and that Bidder’s Response constitutes a binding offer.

Joint Proposals

If Bidders submit a joint Response with one or more other persons or entities, these persons or entities must designate a prime Bidder. The prime Bidder will be DSHS sole point of contact through the Procurement process. If selected as the Apparent Successful Bidder, the prime Bidder shall sign the contract and any amendments and will be liable and responsible to DSHS for all performance under the contract.

Withdrawal of Responses

After a Response has been submitted, Bidders may withdraw their Response at any time up to the Response due date and time as specified in Section C.1, Solicitation Schedule. A written request to withdraw the Response, signed by an authorized representative of the Bidder, must be submitted to the Coordinator. After withdrawing a Response, the Bidder may submit another Response at any time up to the Response submission date and time.

Ownership of Responses

All materials submitted in response to this Solicitation will become the property of DSHS, unless received after the deadline in which case the Response shall be returned to the sender. DSHS shall have the right to use any of the ideas presented as part of the process in any manner as it deems appropriate or beneficial, regardless of whether it is contained in a Response that results in selection for a Contract.

DSHS Award Options; Improvement of Bid Offers

After Responses are received and written evaluations are completed, DSHS may (but shall not be required to) request best and final offers from one or more Responsible and Responsive Bidders. The written Responses of Bidders invited to provide a best and final offer may be re-evaluated and the point values may be adjusted based upon changes to pricing or proposed services, deliverables or methodologies that are included in a best and final offer, prior to DSHS’ determination of the Apparent Successful Bidder.

Alternatively, after reviewing all Responses, DSHS may enter into negotiations with the highest ranked Responsive and Responsible Bidder in order to determine if the Bid may be improved before identification of the Apparent Successful Bidder.

DSHS shall not be required to request best and final offers or to enter into negotiations and reserves the right to make a Contract award without further discussion of the Response. Therefore the Response should be submitted on the most favorable terms that Bidder intends to offer.

Oral Interviews or Presentations

After bids are received and written evaluations are completed, DSHS may request that one or more Responsible and Responsive bidders participate in an in-person oral interview and/or presentation or demonstration that includes all bidder personnel identified


by the bidder as key to the success of the project (and shall include key personnel that are proposed to work on the project). All oral interviews will be conducted in Olympia, Washington at Economic Services Administration headquarters, Capital View 2 building located at 724 Quince St SE Olympia, WA 98501. If this option is elected, additional points shall be awarded as set forth in Section E.3, Evaluation Criteria and Scoring of Responses.

Announcement of Successful Bidder(s)

DSHS shall announce the Apparent Successful Bidder(s) on WEBS on the date indicated in Section C.1., Solicitation Schedule. All announcements of Apparent Successful Bidders are subject to the negotiation of a Contract satisfactory to DSHS.

Bidders who are not announced as an Apparent Successful Bidder, and were not disqualified or found to be non-responsive may request a debriefing conference with the Coordinator concerning the evaluation of their bid and may, under certain circumstances, file a formal protest requesting that DSHS provide an identified remedy if Bidder believes certain types of errors occurred. A more detailed description of these processes is set forth in Section F, Debriefing and Protest Procedure.

Ethics, Policies and Law

This Solicitation, the evaluation of Responses, and any resulting contract will be made in conformance with applicable Washington State laws and Policies.

Specific restrictions apply to contracting with current or former state employees pursuant to RCW 42.52. Bidders should familiarize themselves with the requirements prior to submitting a Response. Bidders must include, in their Letter of Submittal, information regarding any current or former state employees who are employed by, or subcontracted with, Bidder.


SECTION D INSTRUCTIONS REGARDING CONTENT, FORMAT AND SUBMISSION OF

WRITTEN RESPONSES 1. Bidders Responses

Bidders shall submit their Responses utilizing the forms set forth on Attachments B, C, D, E, F, and G to this Competitive Solicitation. Each Attachment represents a separate section of the Response. Failure to complete and submit all required Attachments, and to sign them, if applicable, may result in Bidder disqualification. Responses shall be neatly typed in 12-point font, using proper grammar, spelling and punctuation and shall be submitted in the following order with each section of the Response clearly labeled.

Bidder’s completed and signed Attachments B and C, together with any documents that are required to be attached, and Bidder’s answers to all administrative questions set forth in Attachment D, comprise the Administrative component of the Response. All required Bidder submissions are listed in the following table.

Required Submission

Required File

Naming Convention Used For

Attachment B – Bid Submission Letter Template

1623-610 Attachment B Bid Submission Letter<bidder name>.docx

Pass/Fail. Used for acknowledging acceptance of all terms and conditions in this Solicitation.

Attachment C – Bidder Certifications and Assurances Template

1623-610 Attachment C Bidder Certifications and Assurances<bidder name>.docx

Pass/Fail. Used for acknowledging compliance with the certifications and assurances associated with this Solicitation and any resulting Contract.

Attachment D – Bidder Response Template

1623-610 Attachment D Bidder Response<bidder name>.docx

Portions Scored. Used for responding to the work and other (e.g. references, etc.) requirements as set out in this document.

• Bidder Proposed Solution Document

1623-610 Bidder Proposed Solution<bidder name>.docx

(Attached to 1623-610 Bidder Response)

Scored. Used for delivering an overview of the methodology and approach to providing the services and deliverables requested in this Solicitation.

• Sample Work Products

1623-610 Sample Work Product <n><bidder name>.docx

Scored. Used for demonstrating performance on past projects of similar size and scope.



• Bidder Annual Report

1623-610 Annual Report<bidder name>.docx


Scored. Used for demonstrating financial soundness.

Attachment F – Bidder Customer Reference Template

1623-610 Attachment G Bidder Customer Reference<bidder name>.docx

Scored. Used for the collection of references for the bidder.

Attachment G – Cost Proposal Template

1623-610 Attachment F Cost Proposal<bidder name>docx

Scored. Used for documenting proposed costs by project phase, proposed costs for all hardware, software and equipment and hourly rates for all Contractor Personnel.

Attachment E – Contractor Intake Form

1623-610 Attachment E Contractor Intake<bidder name>docx

Required ONLY for the ASB.

Attachment B: Bid Submission Letter (Required, pass/fail)

All Bidders must submit a completed bid submission letter in the form and with the minimum contents set forth on Attachment B, which must include all of the required acknowledgments and information. The Bid Submission Letter must be signed by an individual authorized to bind the Bidder contractually.

Attachment C: Bidder Certifications and Assurances (Required, pass/fail) All Bidders must submit the Bidder certifications and assurances form set forth on Attachment C, signed by an individual authorized to bind the Bidder contractually. Attachment D: Bidder Response (Required; portions scored; see Section 6 for the list of requirements) Using Attachment D, Bidders must provide answers to the questions set forth on the Bidder Response Form to demonstrate satisfaction of administrative requirements, bidder and staff qualifications and service level requirements. Bidders must also respond to a series of questions regarding service level objectives. It is the intent of DSHS that, along with the minimum required service level requirements, the service level objectives will be determined and mutually agreed upon by DSHS and the Bidder for incorporation into the final Contract. The Bidder Response Form is posted separately from this Solicitation document in Microsoft Word format. Except for limits that are noted on the Bidder Response Form, Bidders may utilize as much space as is reasonably required to respond to each question, provided all questions are repeated and remain numbered and ordered as set forth in Attachment D. If additional pages are needed, they shall


be attached to the page containing the initial portion of the response to a question and shall be marked clearly to indicate that they provide a continuation of Bidder’s answer to a specific numbered question. Bidders shall not submit product brochures, white papers, customer testimonials, cut sheets, or other pre-prepared materials in response to any of the questions. Bidders must submit complete, well-organized explanatory answers that address all of the specific questions asked in the Bidder Response Form. Bidders shall not assume that evaluators will be familiar with their businesses before conducting the evaluation. Use of Attachment D assures that Bidder responds to specific questions in the space immediately below those questions and helps to avoid confusion among evaluators about the question that is being responded to. In awarding points, evaluators shall not be obligated to search through the Bidder’s answers to questions other than the one being reviewed in order to locate text that is responsive to the question being reviewed. Failure to use the form set forth on Attachment D (with the applicable questions set forth immediately above Bidder’s answers), failure to respond to all questions and/or failure to submit any documents requested in the Bidder Response Form may result in Bidder disqualification. If Bidder is awarded a Contract, DSHS may require that Bidder’s Response to the Bidder Response Form be incorporated, in whole or in part, into the Contract. Bidder Proposed Solution (Required, scored)

In a separate double-sided document, no more than forty (40) pages long, the Bidder must describe its proposed solution. At a minimum, (and in the following order), the Bidder Proposed Solution document must include the Bidder’s project management methodology, a proposed project plan that includes durations and milestones and the benefits of its proposed solution, including examples of past successes in similar engagements. In addition, the Bidder must describe, in detail and by phase, how it will provide the services and deliverables listed in the Statement of Work.

Sample Work Products (Required, scored)

All Bidders must provide, as separate attachments, one each of the following work products, or their equivalents, developed and used in a previous project of similar size and scope:

1. Technical Environment Assessment Report – Refer to Section A Statement of Work item 5.2.3 for DSHS’ requirements for this deliverable.

2. Data Conversion/Migration Design Document – Refer to Section A Statement of Work item 5.3.4 for DSHS’ requirements for this deliverable.

Bidder Annual Report (Required, scored)

The Bidder must provide, as a separate attachment, a copy of their company’s most recent annual report, including consolidated balance sheets and related statements of income, stockholders’ or partners’ equity and changes in financial position, for each of the five (5) fiscal years preceding the end of the most recent fiscal year. The financial information listed above must be compiled, reviewed, and/or audited by a Certified Public Accountant.


At a minimum, DSHS will consider the following items, as numbered in a U.S. Securities and Exchange Commission (SEC) Form 10-K or as equivalently described in a private company’s annual report, when reviewing the Bidder’s annual report.

• Item 1: Business

• Item 1A: Risk Factors

• Item 3: Legal Proceedings

• Item 6: Selected Financial Data

• Item 7: Management’s Discussion and Analysis of Financial Condition

• Footnotes to the Financials

Attachment F: Bidder Customer Reference (Required, scored)

Using Attachment F, Bidders will ask a minimum of three (3) customers to fill out the form, sign it and return it to the Solicitation Coordinator. A minimum of three (3) references must be from comparable engagements. For every Bidder Customer Reference Form, the Bidder must use the table provided in Attachment F – Bidder Customer Reference to provide the company name, contact name, contact job title, address, telephone number and email for that reference. It is the Bidder’s responsibility to ensure that the Bidder Customer Reference Forms are completed and returned to DSHS by the Final Response date. References not received by the Final Response date will be assigned a score of zero. DSHS reserves the right to contact all customer references, and that contact may be considered in evaluating the Bidder’s response. Attachment G: Cost Proposal (Required, scored)

Using Attachment G, Bidders must provide a not-to-exceed price for all services and deliverables, a not-to-exceed price for maintenance and operations and a not-to-exceed price for acquiring all necessary hardware, software and equipment. In addition, Bidders must provide a maximum hourly rate for each role listed in Attachment G, Section G2. Attachment E: Contractor Intake Form (Required ONLY for the ASB, not

scored) The Apparent Successful Bidder (ASB) must complete and sign the Contractor Intake Form (Form 27-043) attached to this competitive Solicitation as Attachment E. This form can be downloaded in Microsoft Word format for ease of completion at https://www.dshs.wa.gov/fsa/forms. Any copy of any business license is acceptable. However, unless Bidder is not required to have a business license, the successful Bidder will need to have a Washington Business License before the contract begins. Prior to performing any work, Bidder will need to obtain a business license, if one is required, through the Washington Department of Licensing. Their web address is: http://www.dol.wa.gov/ Bidder can provide its Washington business license, if required, after award.

2. Proprietary Information/Public Disclosure


Materials submitted in response to this Solicitation shall be deemed public records as defined by RCW 42.56. All Responses and accompanying documentation shall become the property of DSHS upon receipt, and will not be returned. The Bidder’s Response must include, on its Response, a statement identifying the pages, if any, which contain information the Bidder considers proprietary. Each page claimed to be proprietary must be clearly marked by stating the word “Proprietary” on the lower right hand corner. Bidders must be reasonable in designating information as proprietary or confidential. Bidders may not mark their entire Response proprietary. Doing so will not be honored and will disqualify your Response from further consideration.

If DSHS receives a request to view or copy a Bidder’s Response, DSHS will respond according to applicable law and DSHS’s policy governing public disclosure. DSHS will not disclose any information marked “Proprietary” in a Response without giving the Bidder ten (10) days’ notice to seek relief in superior court per RCW 42.56.540.

Bidders may not include any DSHS client information in their Responses. Doing so will result in disqualification of the Response from further consideration. If you wish to include examples of any forms or processes, use a blank form or ensure that all client information is completely redacted. 3. Submission of Responses

Bid Responses must be stored in an acceptable electronic format as set forth below. Bid Responses must be emailed directly to the Coordinator at the email address provided on the cover sheet of this Solicitation Document. Bid Responses must be received by the Coordinator in their entirety on or before the due date and time set forth in Section C.1., Solicitation Schedule, unless a posted Amendment to this Competitive Solicitation changes this due date and time. Bidder’s completed version of each of the submission requirements for this Competitive Solicitation shall be included as a separate attachment to the Bidder’s email(s). Bidders assume all risks for the timely submission of the Response. Bidders are responsible for allowing sufficient time to ensure timely electronic receipt of their Response by the Coordinator and, in Solicitations that also require that hard copies of the Response be submitted, to ensure timely receipt via other delivery methods. DSHS does not assume responsibility for problems with the Bidder’s email, network or problems with the mail, parking, traffic or the services of any third party courier. However, if DSHS email is not working properly, appropriate allowances will be made. DSHS will not accept late Responses, nor grant time extensions for individual Bidders. DSHS will disqualify any Response and withdraw it from consideration if it is received after the Response submission due date and time. The “received date/time” shown on the DSHS email system will be used as the official time stamp.

4. Acceptable Electronic Formats for Submission of Responses

Attachment D, Bidder Response Form, shall be submitted in Portable Document Format (Adobe Acrobat PDF) or Microsoft Word. Other Response documents must be formatted in Portable Document Format (Adobe Acrobat PDF) or Microsoft Word, or Excel, Spreadsheet documents must be submitted in Microsoft Excel and in a live, unprotected file that includes all formulas, macros, and computations that are relied on or used to


calculate any rates or values presented therein. When scanning documents to be submitted in PDF format, scanner resolution shall be set to at least 200 dots per inch. NOTE: DSHS cannot receive emails that are larger than 30MB. To keep file sizes to a minimum, Bidders are cautioned not to use unnecessary graphics in their Responses. If your Response approaches or exceeds 30MB, you must break it up and send it by more than one email so that no single email exceeds 30MB.

5. Alternative Submission Methods

Bidders wishing to request an alternative method for submitting their Response must contact the Coordinator at least ten (10) days before the Response Submission Date. No alternative submission method will be accepted unless agreed to by the Coordinator in writing prior to the Response deadline.


SECTION E EVALUATION OF RESPONSES

Bid Responsiveness; Administrative Review

All Responses will be reviewed initially, prior to the written evaluations, by the Solicitation Coordinator and/or Program Project Manager(s) to determine compliance with administrative and minimum qualification requirements and instructions specified in this Solicitation. Examples of when DSHS may disqualify or reject a Response as nonresponsive at any time, include:

•••• Incomplete or unsatisfactory Response or failure to follow submission or form requirements.

•••• Submission of a Response that proposes services that deviate from the scope and technical requirements set forth in this document and Attachment A, Sample Contract, except as permitted in an Amendment to this Solicitation

•••• Failure to meet the minimum Bidder qualifications or to comply with any requirement set forth in this Solicitation Document, including Attachments

•••• Submission of incorrect, misleading, or false information •••• History of prior unsatisfactory contractual performance

The Coordinator may contact any Bidder for clarification of the Response. If a Response is deemed non-responsive, it shall be removed from further consideration. DSHS shall notify non-responsive Bidder(s) of this determination and the supporting reasons. Bidders whose Responses are found to be non-responsive shall be disqualified from further evaluation and shall be notified in writing. If a Response meets all administrative and Bidder qualification requirements and submittal instructions, DSHS shall continue with the Written Evaluation and, if applicable, the Oral Evaluation.

Errors in Bidder Response

Bidders are responsible for all errors or omissions contained in their Reponses. Bidders will not be allowed to alter Response documents after the deadline for Response submissions. DSHS reserves the right to contact any Bidder for clarification of Response contents. In those cases where it is unclear to what extent a requirement has been addressed, the evaluation panel may, in their discretion and acting through the Coordinator, contact a Bidder to clarify specific matters in the submitted Response. DSHS reserves the right to waive minor administrative irregularities contained in any Bidder Response.

Evaluation Criteria and Scoring of Responses

Following the administrative review, Responses shall be evaluated and points shall be awarded, as applicable, based upon Bidder’s responses to the questions set forth in Attachment D, Bidder Response Form. Response items may be assigned a weight based


on the relative level of importance for that item. Item weights will be multiplied by the evaluator’s score for that item to produce the final score.

3.1 The evaluation will be based only upon the response and not upon the evaluator’s external experience with, or perception of, the Bidder or upon Bidder presentations made prior to the release of this document.

3.2 Scored items will be awarded points by each evaluator (see listing below). Points will be assigned based upon the evaluator’s interpretation of the Bidder’s response to each requirement.

3.3 The evaluation teams will score independently of other teams. Upon completion, the scores will be given to the Coordinator. Scoring will be based upon a scale of zero (0) to five (5), with those scores being defined as follows:

Score Description Discussion

5 Exceptional Feature or capability is clearly superior to that which is average.

4 Above Average Feature or capability is better than that which is average.

3 Average

This is the baseline score for each item with adjustments based upon the evaluator’s interpretation of the Bidder’s response.

2 Below Average Feature or capability is substandard to that which is average.

1 Failing Feature or capability is non-responsive or clearly inadequate to that which is average.

0 No Experience Response shows no experience in this skill or capability.

� The maximum TOTAL point possible for this solicitation is: 1,500

Evaluation Criteria

Available Points

Base S

core

Non-Cost Points TOTAL 800

(D2) Bidder Proposed Solution 400

(D3) Sample Work Products 100

(D4) Bidder Annual Report 30

(D5) Bidder Requirements 20

(D6) Bidder Engagements 50

(D7) Bidder References 50

(F) Bidder Customer References 150

Cost Points TOTAL 200

(G) Services & Deliverables 120

(G) Maintenance & Operations 40

(G) Hardware/Software 40

Total Written Evaluation Points 1,000


Optional Optional Oral Presentations 500

TOTAL Total Possible Points (w/oral interview) 1,500

3.4 Eighty (80%) percent of the base score will be based on the bidder’s proposed solution, sample work products, bidder requirements, annual report, engagements and references, and cost will account for twenty (20%) percent of the base score.

3.5 Purchaser reserves the right to use references to confirm satisfactory customer service, performance, satisfaction with service/product, knowledge of products/service/industry and timeliness; any negative or unsatisfactory response may be an adequate reason for rejecting a bidder as non-responsive and unable to suit the needs of the state. Purchaser reserves the right to waive a reference check. Bidders deemed non-responsive may be rejected.

3.6 An evaluation team will evaluate non-cost submittals and award points consistent with their values and best professional judgment.

3.7 The evaluators will review each Bidder’s responses and award either all or a portion of the available points for each question. Scoring may be performed in isolation or together as a group, or a combination of both.

3.8 Evaluators will provide the total points awarded for each Bidder. The evaluator totals will be combined and averaged based on the number of evaluators. (example below).

Bidder

A Bidder

B Bidder

C Bidder

D

Evaluators

Evaluator 1 260 310 300 320

Evaluator 2 300 280 310 280

Evaluator 3 300 300 270 280

Evaluator 4 320 280 300 300

Evaluator 5 310 290 285 290

Evaluator Total 1490 1460 1465 1470

Evaluator Avg. 298 292 293 294

Score 298 292 293 294

Evaluation of Cost Proposal/Quotations

DSHS has budgeted an amount not to exceed $8.95 million for this Project. DSHS will reject any Response in excess of the not to exceed amount. Any Contract awarded is contingent upon the availability of funding.

The Cost evaluations shall be based upon a calculation that rates each proposal in relation to the lowest cost proposal, in that category. The maximum point value (100% of possible points) shall be granted to the lowest cost (lowest numerical) bid for any given category of pricing that is solicited. The remaining bids in that category shall receive a percentage of the maximum number of points based upon a comparison of their value to that of the lowest cost bid. In other words, the Bidder who offers the lowest rate for each question


shall receive the maximum number of points, with each successive Bidder receiving fewer points in proportion to the lowest cost proposal. The Bidder with the lowest total cost per category will receive the maximum cost points available per that category. Bidders with higher total costs will receive proportionately fewer cost evaluation points based upon the lowest cost totals as follows in the examples below:

Proposed Cost

Category Bidder A Bidder B Bidder C Bidder D

Services & Deliverables $1000 $1250 $1850 $2000

Bidder A: $1000 = 120 Points Lowest cost total. Bidder receives all 120 available points.

Bidder B: $1000 /$1250 = .80 * 120 = 96 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder C: $1000 /$1850 = .54 * 120 = 64.86 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder D: $1000 /$2000 = .5 * 120 = 60 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Proposed Cost


Maintenance & Operations $1500 $1700 $1250 $2350

Bidder C: $1250 = 40 Points Lowest cost total. Bidder receives all 200 available points.

Bidder A: $1250 /$1500 = .83 * 40 = 33.33 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder B: $1250 /$1700 = .74 * 40 = 29.41 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder D: $1250 /$2350 = .53 * 40 = 21.28 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Proposed Cost


Hardware & Software $1050 $750 $2000 $1075

Bidder B: $750 = 40 Points Lowest cost total. Bidder receives all 200 available points.

Bidder A: $750 /$1050 = .71 * 40 = 28.57 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder C: $750 /$2000 = .38 * 40 = 15 Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Bidder D: $750 /$1075 = .70 * 40 = 27.9Points Lowest Bid / Higher Bid = Percentage of Available Points * Available Points = Points Awarded

Cost Points



Services & Deliverables 120.00 96.00 64.96 60.00

Maintenance & Operations 33.33 29.41 40.00 21.28

Hardware & Software 28.57 40.00 15.00 28.00

Total Cost Points 181.9 165.41 119.96 109.28

Written Bid Evaluation Process

DSHS shall designate an evaluation team of at least five (5) evaluators to review, evaluate, and score the written question responses. These evaluators will be selected based on their qualifications, experience, capability and background. If oral interviews or presentations are conducted, additional evaluators may supplement or replace some or all of the individuals performing the written evaluation. Evaluators shall assign scores up to the maximum points available. Individual evaluator points will be totaled and the average points for each Bidder will be calculated.

Bidder’s References

Once the written evaluations are completed, DSHS may contact the references provided by the top-ranked Bidder(s) in order to investigate past performance and validate information in Bidder Responses. In submitting a Response, Bidder agrees that it shall hold harmless DSHS and any individuals identified as references from and against liability resulting from the provision of information or the receipt and use of that information in evaluating Bidder’s Response.

DSHS may, at any time, require additional or substitute references to determine the Bidder’s experience and level of responsibility. If the reference check process reveals information that should properly be considered in evaluating Bidder’s responses, DSHS may, in its sole discretion, reconvene the evaluation panel to reconsider the evaluation scoring in light of the information obtained.

Oral Interview/Evaluation

In addition to evaluating the written response, DSHS may invite one or more of the highest scoring Bidders to make an oral presentation which shall be separately evaluated.

DSHS may, after evaluating the written Proposals, elect to schedule oral presentations with the top bidder(s). The Solicitation Coordinator will notify finalists of the date and time of the oral presentation. All oral interviews will be conducted in-person (and shall include key personnel that are proposed to work on the project) in Olympia, Washington at Economic Services Administration headquarters, Capital View 2 building located at 724 Quince St SE Olympia, WA98501 . DSHS will select evaluators for the oral presentations based on their qualifications, experience, and background relevant to this solicitation. These evaluators may include evaluators who reviewed the written Proposals or DSHS staff who will work with the successful Bidder. Evaluators will score oral presentations in accordance with the solicitation requirements. Oral evaluations will be scored with a maximum of 500 possible points awarded.

Facility/Site Assessment

DSHS reserves the right to visit and assess the facilities proposed to be used by top-


ranked Bidder(s) in delivering services. Unless otherwise noted in this Solicitation document, this assessment shall be evaluated on a pass/fail basis.

If DSHS deems the facility assessments are necessary, the Coordinator will notify the top ranking Bidder(s) of the date and time for their facility assessment. DSHS expects the facility assessments will take place on the dates specified in the Section C.1., Solicitation Schedule.

Selection of Apparent Successful Bidder

The Bidder that receives the highest total number of possible points and who provides DSHS with the best value will be considered the Apparent Successful Bidder and presented to DSHS management for consideration. In the event multiple Contracts will be awarded, the applicable number of top-scoring Bidders will be considered.

To identify an apparent successful bidder, each bidder’s points earned from the cost evaluation and the non-cost evaluation will be added together as follows:

The following table serves ONLY as an example:

Base Score Optional Score

Bidder Non-Cost Points1

Cost Points2 Total (1+2) Oral

Presentation (Optional)4

Overall Total (1+2+4)

Bidder A 710 200 910 390 1300.00

Bidder B 730 157.89 887.89 420 1307.89

Bidder C 695 123.71 818.71 -

Bidder D 725 98.36 823.36 -

Each example is a stand-alone example. Example numbers in this table are not related to other examples.

The bidder with the highest number of total points and who provides DSHS with the best value, will be declared the apparent successful bidder. Purchaser may then enter into contract negotiations with the apparent successful bidder.

The selection process shall determine which Bidder provides the best value in meeting the needs of DSHS. Selection of the Apparent Successful Bidder(s) depends upon DSHS’ assessment of multiple factors, including Bidders’ qualifications, capabilities, efficiency, experience, reliability, responsibility, integrity, quality of proposed services and deliverables, timeliness, cost and potential impact on DSHS’ needs.

DSHS may consider whether the Response encourages diverse contractor participation; whether the Bid provides competitive pricing, economies and efficiencies; whether the Bidder considers human health and environmental impacts; whether the Response appropriately weighs cost and non-cost considerations; and life cycle cost, as applicable. DSHS may also consider a Bidder’s performance on prior State or other contracts and may reject Responses of any Bidder who has failed to perform satisfactorily under any previous contract with the State or another party.

DSHS reserves the right to select a Bidder whose Response is deemed to offer the best overall value and that is in the best interests of DSHS and the State of Washington. Hence, DSHS may choose to not award to the highest scoring or lowest-cost proposal. Any Bidder who would be an Apparently Successful Bidder based on the scores awarded by the evaluators, and who is not selected, shall be provided, upon request, the reasons


why DSHS selected a Bidder with a lower final score.

Designation as an Apparent Successful Bidder does not imply that the state will issue an award; it merely suggests that the state believes a proposal to be responsive and offer the best value to DSHS. This designation allows DSHS an opportunity to perform a responsibility analysis and ask for additional documentation. DSHS is also at liberty to re-review and determine whether a proposal is responsive as initially determined. Bidder must not construe the notification of award, impending award, or attempts to negotiate, etc. as a final award decision. Any assumptions are done so at the Bidder’s own risk and expense.

DSHS management shall make the final determination as to which Bidder(s), initially designated as finalist(s), shall be officially selected and announced on WEBS as the Apparent Successful Bidder(s) on or about the date and time set forth in Section C.1., Solicitation Schedule. DSHS may also notify the Apparent Successful Bidder(s) and the unsuccessful Bidder(s) of its determination via email on or about the date and time specified in Section C.1., Solicitation Schedule.

DSHS’ decision will be subject to the execution of a Contract satisfactory to DSHS within a reasonable period of time following the announcement of the Apparent Successful Bidder on WEBS. In the event the parties are unable to reach agreement on the final details of a Contract, consistent with Attachment A, Sample Contract, DSHS shall have the option of negotiating with the next highest ranked Bidder and of revising the announcement of the Apparent Successful Bidder.


SECTION F BIDDER DEBRIEFING

AND PROTEST PROCEDURE 1. Debriefing Conferences No later than 3:00 p.m. on the third business day following the posted announcement of Successful Bidder(s) on WEBS, Bidders Who have submitted timely bids and who have not been disqualified or designated as non-responsive during the solicitation process may send an email to the Coordinator requesting a Debriefing Conference. Unless a different date is agreed upon by the Coordinator, the Debriefing Conference will be held on a date designated in Section C.1., Solicitation Schedule. Discussion at the debriefing conference will be limited to the following:

• Evaluation and scoring of the Bidder’s Response • Critique of the Response based on the evaluation • Review of Bidder’s final score in comparison with the other final scores

No comparisons between Bids will be allowed during the Debriefing Conference, which shall be conducted by telephone, unless the Coordinator agrees to an in-person meeting, and shall last for a maximum period of thirty (30) minutes.

Grounds and Filing of Protests A Bidder who has participated in a Debriefing Conference may file a formal Protest if the Bidder asserts that there are facts that indicate error in the evaluation of Bids on one or more of the following grounds:

• Bias, discrimination or conflict of interest on the part of the evaluator or in the process

• Mathematical errors in computing the score • Non-compliance with procedures described in the Solicitation document or in

DES policy

Protests must be emailed to the Solicitation Coordinator and must be received no later than 3:00 p.m. (Pacific Time) on the fifth (5th) business day following the day of the Bidder’s Debriefing Conference. The Protest must adhere to the requirements set forth in this Section or it will not be considered. This protest procedure constitutes the sole administrative remedy available to Bidders from DSHS under this Solicitation. Protests must include the protestor’s mailing address and phone number and the name of the individual responsible for filing the Protest. The Protest must state the Solicitation number and title, the grounds for the Pprotest, specific facts to support these grounds, and a description of the relief or corrective action being requested. Protests not based on one of the grounds set forth in this Section will be rejected. It is not grounds for a protest to question an evaluator’s professional judgment on the quality of a Response or DSHS’ assessment of its own needs or requirements. 4. DSHS Protest Review Process The Coordinator will immediately forward any Protest to the Chief of Central Contracts and Legal Services to assign to a Protest Coordinator for review. The Protest Coordinator, an individual who was not involved in the Solicitation, will consider the record and all


available facts and will endeavor to issue a decision within ten (10) business days following receipt of the Pprotest. If additional time is required, the protesting party will be notified of the delay. In the event a Protest may involve the conduct of or information submitted by another Bidder that also submitted a Response, such Bidder will be given an opportunity to submit its views and any relevant information on the issue(s) raised by the protest to the Solicitation Coordinator. 5. Determination of Protests The Protest Coordinator shall issue a written determination regarding the Protest. This written determination shall include one or more of the following determinations: • Upholding DSHS determination of the Apparent Successful Bidder(s) on the basis that there are insufficient facts to establish the alleged error; or • Upholding DSHS’ determination of the Apparent Successful Bidder(s) on the basis that there are only technical or harmless errors in DSHS’ evaluation process; or • Finding errors and identifying actions which may be taken by DSHS, such as:

o Correction of errors and reevaluation of all bids, o Cancellation and reissuance of the Solicitation (in which case all the Bidders

will be notified), or o Other corrective actions as may be appropriate

There is no further administrative process or remedy available within DSHS to appeal the determination that resulted in a Protest. If the protesting party does not accept DSHS’ determination, the protesting party can seek relief from Superior Court in Thurston County, WA.


SECTION G CONTRACTING PROCEDURES

Contract Execution

The Apparent Successful Bidder(s) is expected to sign a contract with DSHS that is substantially the same as Attachment A, Sample Contract, included with this Solicitation, and to enter into any subsequent Contract amendments that may be required to address specific work or services.

DSHS reserves the right to require that some or all of Bidder’s Response be incorporated into the Contract, and to negotiate the specific wording of the Statement of Work, based on the requirements of this Solicitation and the terms of the Response submitted by the Apparent Successful Bidder. If changes are requested as part of the Bid Response, DSHS may consider, but shall be under no obligation to agree to, modifications to the General Terms and Conditions of Attachment A, Sample Contract.

DSHS will require the Bidder’s solution as presented in their proposal, to undergo agency and State security assessments prior to entering into a contract.

If the Apparent Successful Bidder fails or refuses to sign a Contract within ten (10) business days of delivery by DSHS, DSHS may elect to designate the next highest-ranked finalist as the Apparent Successful Bidder.

Insurance

The Apparent Successful Bidder shall provide evidence of its compliance with the insurance requirements included in Attachment A, Sample Contract.

Non-Endorsement

The award of a Contract is not an endorsement by the State or DSHS of the Bidder or Bidder’s Services and shall not be represented as such by Bidder in any advertising or other publicity materials.

By submitting a Response to this Solicitation, the Bidder agrees to make no reference to DSHS in any literature, promotional materials, brochures, sales presentations or the like without the prior written consent of DSHS.

Background Checks

Individuals who will be performing the Contract on behalf of the Apparent Successful Bidder may be required to undergo background checks. Individuals who have disqualifying results (showing crimes and/or negative actions) may not be permitted to provide Services under the Contract.

Electronic Payment

The State prefers to utilize electronic payment in its transactions. The successful Bidder will be required to register in the Statewide Bidder Payment system, http://www.des.wa.gov/services/ContractingPurchasing/Business/BidderPay/Pages/default.aspx, prior to submitting a request for payment under their Contract. No payment shall be made until the registration is completed.


APPENDIX A Number of Objects in Legacy Applications

The items in this appendix document the current DSHS ACES application environment and its corresponding inventory. It is likely that there will be a variance between the system inventory shown below and that collected during the assessment phase due to normal Maintenance and Operations. DSHS expects the Bidder will document an accurate inventory during the assessment phase.

Mainframe Environment

Current H/W Type and Model(s) IBM z13 N30 502

Current O/S & Version No.: z/OS 2.1, Z/VM, z/Linux

Total MIPS rating of Server 1417

Total number of LPARS or Partitions 5

LPARs Information

• P1TSO P1 ACESP1 - ACES, Batch, zVM1

• P5TSO P5 ACESP5

• T4SO T4 ACEST4 – Test LPAR

• P1FTPALT P1 FTPalert

• T4FTPALT T4 FTPalert – Test LPAR

ISPF Panels 20

Total Number of TSO end users 100

Total Number of TSO concurrent users

80

CICS Environments 2

Total Number of Regions 5 (Refer to the Section I ACES Modes of Operations)

Total Number of end users accessing CICS screens

3000

Total Number of concurrent users accessing CICS Screens

2500

Messaging Queue (MQ) Yes

IMS CICS Transaction Gateway (CTG)

Yes

CTG JCA Resource Adapter Yes (The CICS JCA resource adapters are used to support connectivity from JEE application servers to CICS using the facilities of the CICS Transaction Gateway)

CICS Web Services Yes

Universal Client (ECI) based capabilities of CTG

Yes

Common Client (SNA, TCP/IP) Yes

CICS Sockets Yes

CICSPlex Configuration No


Transaction Routing No


Application Environment

Objects Number of Total

Objects Comments

COBOL Programs 1260

COBOL Copybooks 5193

JCL’s/Jobs 4600 Includes BMP Jobs

Job Steps 11000

JCL/Procedures 1169

Procedure Steps 7000

SYSIN’s 4564

IMS DBD Source 326

IMS PSB Source 1015

CICS BMS Maps 259

DB2 Binds 171

Sequential Files 9000

IMS Databases 73 Access Methods used are HIDAM, HDAM and GSAM

IMS Segments 783

DB2 Databases 91

DB2 Tables & Views 3200

VSAM DB 105

GSAM DB 90

Messaging Queues 80

Base GDG’s 1000

Total GDG’s 25000

REXX Programs 100

CLIST Programs 100

Assembler Programs 100

ISPF Panels 20


Data Size Information

Objects Production Size Test Size

Size of VSAM Data 10 GB 2 GB

Size of Sequential Data 600 GB 10 GB

Size of IMS DB Data 750 GB Included in Production

Size of DB2 Data 2400 GB Included in Production


APPENDIX B Application Software

ACES z/OS and z/VM Software’s

The following list contains the OS, Database Management System (DBMS), communication, monitoring, middleware, and other tools that run in the z/OS and z/VM environment.

License types:

• ALC – Annual License Charge

• MLC – Monthly License Charge

• MMC – Monthly Maintenance Charge

• OTC – One Time Charge

Item #

Software Bidder

Product Name License Type

Purpose of Product

z/OS Platform

1 IBM DB2 v11 for z/OS MLC DB2 database support

for mainframe

2 IBM OMEGAMON/CICS ALC Performance

monitoring for CICS

3 IBM OMEGAMON/MVS ALC Performance

monitoring for MVS

4 IBM OMEGAMON for MQ

z/OS ALC Performance

monitoring for MQ

5 IBM OMEGAMON XE for DB2

PE V4 ALC Performance

monitoring for DB2

6 IBM IMS Database Manager

v13 MLC IMS database support

7 IBM AFP Font Collection for

OS/390 OTC Various fonts for

mainframe printing

8 IBM DB2 Utilities Suite ALC DB2 database utilities

9 IBM AFP Toolbox for MVS MMC Includes API used for

Letters printing

10 IBM IMS Index Builder ALC Recover and build IMS

DB indexes

11

IBM IMS HP Unload ALC High Performance Load Utility (Backup/Recovery) for IMS

12

IBM IMS HP Load ALC High Performance Unload Utility (Backup/Recovery) for IMS


Item #

Software Bidder


Purpose of Product

13 IBM Debug Tool Utils & AF

V13.1 ALC Provide developers

with a tool to debug code during testing

14 IBM XML Toolkit z/OS ALC XML Tools for z/OS,

DB2, CICS

15 IBM IMS Library Integrity

Utilities ALC Utilities to manage IMS

DBD, PSB and ACB processes

16 IBM PRT SRV FACILITY V4

for z/OS and OS/390 MLC INFO 4000 printer

driver

17 IBM CICS Transaction

Gateway ALC Web traffic gateway to

CICS transactions

18 IBM CICS TS v5 ALC CICS Transaction

processing

19 IBM Data Encryption IMS and

DB2 ALC Data Encryption for

HBE environment

20 IBM WebSphere MQ Base for

z/OS v8 MLC Message Queuing for

mainframe platform

21 IBM Classic Fed Svr IMS S&S ALC Capture and replicate

IMS data to DB2 tables (ODS)

22 IBM Classic Event Pub IMS

S&S ALC Capture and replicate

IMS data to DB2 tables (ODS)

23 IBM Enterprise Cobol V5.1 MLC COBOL language

support

24 IBM IMS Tools Base for z/OS ALC Hardware (data file)

compression for IMS

25 IBM Page Printer Formatting

Aid / 370 MMC ADM uses for

generating new print formats

26 IBM z/OS Version 2.1 MLC Operating system for

host and tape management

27 IBM z/OS V2 XL C/C++ C /C++ Languages

Compiler

28 z/OS V2 DFSMS dsshsm Backup, Recovery and

Disk Space Management

29 z/OS V2 DFSMS rmm Tape Management

30 z/OS V2 DFSORT Sorting Utility

31 z/OS V2 HLASM Toolkit High-Level Assembler

tools


Item #

Software Bidder


Purpose of Product

32 z/OS V2 RMF System Performance

reporting

33 z/OS V2 SDSF Search and Display

Spool files

34 z/OS V2 Security Server RACF

35 IBM Fault Analyzer V13.1 ALC Fault Analyzer -

organizes and simplifies abend dumps

36 IBM File Manager V13.1 ALC File Manager - for

viewing files and data fixes

37 IBM DB2 Analytics Accelerator ALC High performance DB2

queries

38 IBM Tivoli Decision Support

(TDS) z/OS V1.8 ALC Performance Reporter -

used for capacity planning

39 TDS-CICS Option

CICS Feature

40 TDS Sys Performance Option

System Performance feature

41 IBM NetView Access Services ALC Multi-session product -

NVAS

42 IBM Tivoli Workload Scheduler ALC Job scheduler for batch

on MF

43 IBM Tivoli Monitoring Services

z/OS ALC Tivoli Tools Framework

44 IBM DB/DC Data Dictionary

V1 MMC IMS definitions

repository

45

Allen Systems Group

JOB/SCAN ALC Change, verify and standardize JCL

46

GT Software

ASSIST/GT ALC Screen level and field level help support

47 Levi, Ray & Shoup

VTAM Printer Support (VPS)

ALC Remote printer support

48

VPS/PCL

Remote printer support - AFP to PCL conversion

49 VPS/TCPIP Remote printer support

- TCP/IP feature

50 MQ Software

DataFlow Studio/Q DataLink

State Licensed

Large file transfers


Item #

Software Bidder


Purpose of Product

51

Neon Partitioned Database Facility (PDF) for IMS V3

Site w/Annual Maint.

Better database performance for partitioning

52

OpenTech TAPE/COPY Site w/Annual Maint.

Builds JCL for Tape Library

53

Pitney Bowes

StreamWeaver State License

Pitney Bowes for Duplex Print, etc.

54

William Data Systems

FTPAlert ALC Meet enhanced functional needs for file transfers to outside agencies

z/VM Platform

55 IBM Directory Maintenance

Facility ALC VM/Linux Support

56 IBM Performance Toolkit ALC VM/Linux Support 57 IBM z/VM Version 6 ALC VM/Linux Support

58 IBM z/VM Single System

Image ALC VM/Linux Support


ACES Linux Software

The following list contains the OS, DBMS, communication, monitoring, middleware and other tools that run in the Linux environment.

Item #

Software Bidder


Purpose of Product

1 Novell SUSE Linux Enterprise Server for X86, AMD64 & Intel EM64T, Itanium & IBM Power Processors

IFL Workstation based Linux for Linux administration

2 Novell SUSE Linux Enterprise Server for IBM zSeries

ALC Linux servers for aces.online, eServ, ODM, etc.

3 Novell SUSE Manager for Linux ALC Provide efficient management of Linux servers.

4 IBM DB2 Enterprise Server Edition ALC DB2 for the Data Warehouse and z/VM environments

5 IBM WebSphere

Application Server Network Deployment

ALC aces.online application server for each environment

6 IBM Cognos Impromptu Administrator ALC For Data Warehouse Ad hoc Reporting (being sunset)

7 IBM InfoSphere

DataStage and QualityStage Designer Linux for System z

ALC BI ETL Development workbench

8 IBM InfoSphere

DataStage Linux for System z ALC BI ETL Tool - Production

9 IBM InfoSphere

DataStage for Non-Production Environments Linux for System z

ALC BI ETL Tool - Development/Test

10 IBM InfoSphere

Information Analyzer Linux for System z

ALC BI Information Analyzer

11 IBM InfoSphere

Information Analyzer Workbench Linux on System z

ALC BI Information Analyzer Workbench

12 IBM InfoSphere

Metadata Workbench for Linux on System z

ALC BI Metadata Workbench

13 IBM InfoSphere

Information Governance Catalog Linux on system z

ALC BI Glossary, BI Glossary Workbench, BI Glossary Anywhere - Production PVU

14 IBM InfoSphere

Information Governance Catalog for Non-Production Environments on Linux for System z

ALC BI Glossary and BI Glossary Anywhere - Development/Test PVU

15 IBM Tivoli Storage Manager Extended Edition

ALC Storage management

16 IBM Tivoli Storage Productivity Center Basic Edition Server

ALC Storage management for disk array

17 IBM Security Key Lifecycle Manager - Basic

ALC Store and manage encryption key for disk.


Item #

Software Bidder


Purpose of Product

18 IBM Security Key Lifecycle Manager – Client Device

ALC Store and manage encryption key for disk.

19 IBM WebSphere

ODM Decision Center ALC Rules Engine development, testing and deployment

20 IBM WebSphere

ODM Decision Server Rules Edition for Linux on System z

ALC Rules Engine runtime execution services

21 IBM WebSphere

MQ for zEnterprise BladeCenter Extension and Linux on System z

ALC MQ traffic for LINUX platform

22 IBM Web Content Manager Standard Edition for Linux on Z

ALC Manage static web page content

23 IBM Cognos Business Intelligence Analytics Administrator for zEnterprise BladeCenter Extension and Linux on System z

ALC Admin for enterprise DW

24 IBM Connections Authorized User for Linux on System z

ALC Admin for enterprise DW

ACES Windows Software

The following list contains the tools that run in the Windows environment.

Item #

Software Bidder


Purpose of Product

1 Allen Systems Group (ASG)

Cypress ALC

Reports management system

2 InfoPrint AFP2PDF Transform ALC Allow for imaging of Letters print output. Actually runs on Linux on Intel.

3 Intelligent Search Technology

CORRECTADDRESS (5 Servers)

ALC Address verification

4 Motio, Inc Motio CI (3 Servers)

ALC Data Warehouse change management tool

5 IBM Database Enterprise Developer Edition

ALC For DBA development in Windows environment

6 IBM DB2 Connect Enterprise Edition 25 Floating Users

ALC To support ODBC access to ODS in mainframe DB2

7 IBM DB2 Connect Personal Edition Client Device

ALC Used for developers to access the mainframe DB2 UDB databases


Item #

Software Bidder


Purpose of Product

8 IBM Host Access Client Package for Multiplatform

ALC ACES Mainframe LAN (consoles)

9 IBM Rational Application Developer for Java ALC Eclipse-based integrated development environment (IDE)

10 IBM Rational Architect Extension for Integrated Architecture Frameworks

ALC Web development tool for analysis and design.

11 IBM Rational Software Architect ALC Web development tool for modeling and design.


APPENDIX C ACES Modes of Operation

ACES operational complex currently supports seven different environments to manage application changes. They are the following: • RELS: Development and unit testing environment.

• DEVL: Integration testing environment, also the environment where static code analysis and secure code analysis will be conducted.

• SYTST: System test environment by DSHS Testers for both manual and automated testing.

• UACPT: User Acceptance Test environment.

• HBE-U: User Acceptance environment exclusively for coordinated testing of Magi Eligibility Service and the Healthplanfinder.

• TRAIN: Training environment.

• PROD: Production environment.


APPENDIX D ACES Reference Architecture Diagram

The following ACES Reference Architecture Diagram describes the technical environments, corresponding hardware and software to support ACES and its associated systems.

The processor, an IBM z13, supports both the legacy and modernized components of the ACES application. It is a multi-technology platform. The legacy components are built on z/OS operating system using Common Business Oriented Language (COBOL) as the primary programming language. Information Management System (IMS) and Data Base 2 (DB2) are used as database management systems and CICS is used for transaction processing.


z/VM is the virtualization hypervisor and SuSE Linux Enterprise Server is the operating system. Java is the primary programming language, with DB2 as the database server. WebSphere Application Server (WAS) is the application server container for the Java programs. WebSphere Operational Decision Manager (ODM) is the Business Rules Management System (BRMS). Cognos provides Business Intelligence (BI) and analytics reporting services. InfoSphere Server is used for data Extraction/Transformation/Load (ETL) and data replication support.

The disk array, an IBM DS8870, provides data storage for both the legacy and modern technologies. The disk usage has historically grown in direct relationship to the caseload. In 2014 and 2015 there has been a significant increase in the support of eServ and ACES modernization.

The virtual tape server (IBM TS7720) and automatic tape library (IBM TS3500) provide data backup services for both the legacy and modern technologies. The capacity of the tape server is measured in both total storage capacity and tape transports.


APPENDIX E ACES Software Reference Architecture Diagram

The following ACES Software reference architecture diagram describes the three major platforms – Windows, z/OS, z/VM Linux – each have a software stack that runs in that environment.

As shown in above figure, The three major platforms – Windows, z/OS, z/VM Linux – each have a software stack that runs in that environment. The Windows base install, with the OS is provided by NIS.


Most of the system software for the ACES environment is provided through the ACES Maintenance & Operation (M&O) outsourcing contract. There are a limited number of items with a license type to indicate software that is provided by DSHS. Most of the the software provided are IBM products, but non-IBM software that is provided by Independent Software Bidders (ISV


APPENDIX F ACES Hardware Schema

The ACES Mainframe Complex resides at the Consolidated Technology Services (CTS) State Data Center (SDC). The print services for the mainframe reside at the DES print facility. Under this new strategic initiative, print services are provided at a central location and ACES produces image files that are transferred for printing. DSHS pays for this service through an agreement with DES.

Both of these facilities have been reviewed for compliance with federal and state privacy and security standards.

The ITS team that maintains and operates ACES are all primarily located at a single DSHS office. However, there are thousands of field users across the state in Community Service Offices (CSOs) and Home and Community Services (HCS). ACES also supports two mobile CSOs with one usually in the Eastern part of the state and one in the West.

All of the ACES Mainframe Complex hardware is leased by DSHS. The print devices shown are for clarity, but these devices are not owned by DSHS. DSHS pays for printed output as a service charged through DES.

DSHS also has a contract for a disaster recovery site. The site is located in Boulder, Colorado and the hardware mirrors, or nearly mirrors, the ACES Mainframe Complex. Since this is a service, provided through a contract, the available equipment may not always be an exact match to the ACES environment. However, the contract does require configuration that nearly matches ACES. It includes all of the basic equipment at the SDC that is part of critical business processing.

All networking for ACES and the disaster recovery site are provided by CTS.


APPENDIX G ACES Applications

The overall technical environment as shown in Appendix I (System Context Diagram) that supports the various ACES application components are. • ACES Mainframe Customer Information Control System (CICS) – This

represents the legacy data collection process and application internal to DSHS. This is also used by Health Care Authority staff to support business functions. This process currently does everything ACES 3G supports and several miscellaneous processes. It has support of the parameters, alerts, issuance, QA/QC among other sub-systems. The data collection portions will be decommissioned once all the approriate functionality has been moved to the web application, ACES 3G.

• ACM and other supported functions – This includes the processing of the actions that happen throughout the day and the issuance of benefits and letters to clients. ACES communicates the results of those actions to multiple agencies depending upon the type of assistance and the result of the action. ACES receives multiple inbound interfaces which trigger automated actions. ACM supports ongoing case management of eligibility for those items that are time event related.

• Eligibility Service/Eligibility Subsystem – The Eligibility Service is the component that supports eligibility related processes for the Affordable Care Act. It determines eligibility for Medicaid based on MAGI, which incorporates IRS rules and verification methods. This process also provides determination of APTC (Advanced Premium Tax Credit) eligibility. The Eligibility Subsystem determines eligiblity for all of the other cash, food and classic Medicaid programs.

• aces.online – This is an intranet worker-facing Web application supporting screening, letters and inquiry functionality. Data collection and case actions (called 3G) are also accessed from aces.online. The process supports the data collection of household and client demographic information required to complete the eligibility determination process. This function facilitates the processing of an interview and finalization of the application. Based on the ACES Modernization Roadmap, this function will be expanded to handle everything done today in the mainframe green screens. It is not just a technological re-platform of the ACES application, but an enhanced version that brings new functionality that aids workers to increase productivity and accuracy.

• WACON – Washington Connection – This is an internet client-facing Web application designed to accept electronic data for applications, eligibility reviews and changes of circumstances. This process captures the application for economic assistance benefits such as food, child care, medical and cash assistance. It also includes an “am I eligible” feature and does referrals to other state and local agencies where clients may gain access to additional services.

• Data Warehouse Environment - The data warehouse is comprised of collections of DB2 databases that provide data staging and data reporting functions. The data bases are hosted on both z/OS and WINTEL platforms. There are two core functions of the DW. The first is to capture system data created by ACES and other systems. The second is to create and store transformed data for reporting purposes. The data warehouse provides data to support federal reporting, operational and analytical reporting for numerous state agencies.


• Paper, phone, and walk up – These are different communication channels for the same features provided in Washington Connection. This includes application, eligibility review, and change in circumstances.

• PING – This process is called the Request for Inquiry Ping. PING is the common term for a feature used by Healthplanfinder and ACES that communicates information back and forth as clients may switch from MAGI to Classic Medicaid or vice versa. It does not udpate eligibility, but only shares information. This includes both batch file and transactional communications.

• Healthplanfinder (HPF) – This is an external system that provides access to health care for residents of the State of Washington. This portal is owned and administered by HBE. The application is named Healthplanfinder (HPF) and supports the collection of client demographics, including household composition, tax filing relationships and other information. This system integrates with ACES to determine Modified Adjusted Gross Income (MAGI) and Advanced Payment Tax Credits (APTC) eligibility for their clients.


APPENDIX H ACES Complex Architecture

ACES BatchCICS

(ACES Mainframe)

Web Applications

(WACON, ACES Online)

Web Services

(eServ, BVS, IVR etc)Cognos

ACES Complex

ACES

(IMS Database)

ACES

(ODS Database)

Read and UpdateRead Only

InfoShpere

Classic Data

Event Publisher

Message Queue

DataStage

Flat Files DataStage to

StageStage Tables

ACES Data

Warehouse

DataStage to

DW/DM

Business

Glossary

Other Data

Warehouses

IBM Information Server Meta Data Repository

Read Only

Metadata

Workbench

Data Warehouse Environment(Overnight)

(Near Real-time Replication)

Data

Administration

ACES system of record Denormalized Database

APPENDIX I

System Context Diagram At an enterprise level, the System Context describes the primary users and systems and their interactions with the eligibility determination subsystem. The current Eligibility subsystem participates in an application-to-application interaction with the remaining functional components of ACES. These functional components include:

1. Mainframe data collection screens and aces.online (the Web page data collection component) are two entry points into the current Eligibility subsystem for real-time access.

2. Automated Case Maintenance (ACM) – This batch process includes the processing of the actions that happen throughout the day, generating issuance of client benefits and letters to clients. ACES communicates the results of those actions to multiple agencies depending upon the type of assistance and the result of the action. ACES receives multiple inbound interfaces which trigger automated actions. It supports ongoing case management of eligibility for those items that are time event related.

APPENDIX J ACES Hardware/Software Matrix

Various ACES application components use different development and support tools.

The typical business process for non-HBE clients is initiated by a financial worker in one of the CSOs. These processes are initiated through aces.online or ACES Legacy. aces.online provides browser-based pages that are developed in Java. ACES Legacy components are developed primarily in COBOL with user interface through CICS screens.

Java development is done using the Rational Application Developer (RAD) tool listed in ACES Windows Software Section I. Open source tools are also used in this environment and a list of ACES open source software used for development is included in Appendix K.

Business rules management is done using Operational Decision Manager (ODM). The ODM Decision Center is used for rules visualization and development. ODM Decision Server provides the runtime execution services.

ITS staff use Rational ClearQuest (CQ), Rational RequisitePro (ReqPro), and Rational ClearCase in support of the System Development Life Cycle (SDLC). CQ is primarily a change management tool used to capture change requests (CRs), call records, and resulting problem reports (PRs). CRs and PRs are bundled and tracked as releases. CQ also supports testing scenarios and defects. ReqPro is a document repository for the detailed system changes required in support of CRs and PRs. ClearCase manages version control – used at ITS to manage JAVA software versioning. IBM Source Control Library Manager (SCLM) is used for source code management and versioning of COBOL code.

The following diagram illustrates various ACES application components and their corresponding hardware/software technical environments.

Intel

WindowsServer

Mainframe

z/OS z/VMLinux

Cognos BI

InfoSphereServer

ACES Hardware/Software Matrix

EnterpriseService Bus

Correct Address

JAVA

XML

IMS

CICS

Websphere AS

Websphere ODM

Cobol

Batch

ClearQuest

Correct Address

ReqPro

ClearCase

RDz

AC

ES

Leg

acy

ac

es

.on

line

Websphere MQ

DB2

AC

ES

Leg

acy

ac

es

.on

line

WaC

on

n

AC

ES

Eserv

ac

es

.on

line

AC

ES

Eserv

WaC

on

n

InfosphereServer

APPENDIX K Open Source Software

The following Open Source Software are used as part of ACES complex in web based applications.

AGLP Affero General Public License

GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software.

Apache Apache Software Foundation

http://www.apache.org/foundation/license-faq.html

BSD Berkeley Software Distribution

BSD licenses are a family of permissive free software licenses, imposing minimal restrictions on the redistribution of covered software.

Freeware Portmanteau of "free" and "software"

Computer software that is available for use at no monetary cost, which may have restrictions such as redistribution prohibited, and for which source code is not available

GPL General Public License

GNU General Public License is a free, copyleft license for software and other kinds of works.

LGPL Lesser General Public License

https://www.gnu.org/licenses/lgpl.html

MIT License

Massachusetts Institute of Technology

Permissive free software license that permits reuse within proprietary software provided all copies of the licensed software include a copy of the MIT License terms and the copyright notice.

MS-PL Microsoft Public License

http://www.microsoft.com/en-us/openness/licenses.aspx

Item #

Product Name Description License Type

Source

1 IBM Installation Manager

Used to download IBM software.

Freeware http://ibm.com

2 iText JAVA library that allows you to

generate PDF files on the fly. AGLP http://www.lowagie.c

om/iText/

3 Prototype JavaScript library used for

AdmEstimation Tool. MIT license (GNU GPL Compatible)

http://www.prototypejs.org/

4 Yahoo User Interface (YUI)

Client-side, JavaScript framework for building web applications.

BSD http://developer.yahoo.com/yui/

Item #


Source

5

Microsoft Enterprise Library

Microsoft Enterprise Library targets issues like logging, validation, data access, and exception handling, as well as many others. Used in Online Service Application (OSA) and Address Validation Service (AVS) to provide support for logging.

MS-PL http://msdn.microsoft.com/en-us/library/cc467894.aspx

6

Web Service Software Factory

Integrated collection of resources designed to help you quickly and consistently build Web services that adhere to well-known architecture and design patterns.

MS-PL http://msdn.microsoft.com/en-us/library/cc487895.aspx

7

Apache FOP Application that reads a formatting object (FO) tree and renders the resulting pages to a specific output. Driven by XSL formatting objects.

Apache V2 fop.jar, Avalon-framework-cvs-100109.06.jar, batik.jar

8

Log4J With log4j it is possible to enable logging at runtime without modifying the application binary. The log4j package is designed so that these statements can remain in shipped code without incurring a heavy performance cost. Logging behavior can be controlled by editing a configuration file, without touching the application binary. Used in PrintService for Letters to PDF to provide support for logging. Java logging framework used by MotioCI for the version control and testing product for IBM Cognos.

Apache v2 http://logging.apache.org/log4j/1.2/

9

clearant lib (for ClearCase)

This library is a collection of "value-add" Ant tasks for integrating IBM Rational ClearCase with Apache Ant.

Apache Software license 2.0

http://clearantlib.sourceforge.net/

10

Spring framework

The Spring Framework is an open source application framework for the Java platform. The framework provides MVC support and flexibility to integrate Messaging, aspect orientation, enterprise apps.

Apache Software license 2.0

http://www.springsource.org/

Item #


Source

11

JCAPTCHA JCAPTCHA stands for Java Completely Automated Public Test to tell Computers and Humans Apart. The open source java framework for captcha definition and integration.

LGPL v2.1 http://jcaptcha.sourceforge.net/

12 FreeTTS Speech synthesizer written

entirely in the JavaTM programming language

BSD http://freetts.sourceforge.net/docs/index.php

13

jQuery Fast, concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development.

MIT & GPL http://jquery.org

14

jQuery UI Provides abstractions for low-level interaction and animation, advanced effects and high-level, theme-able widgets, built on top of the jQuery JavaScript Library that can be used to build highly interactive Web applications.

MIT & GPL http://jquery.org

15

Apache HTTP Server

Web Server to host static content

Apache v2 http://www.apache.org

16

Barcode4J Used to apply Barcode for form 14001 generated for Eapp, used in conjunction with FOP

Apache v2 http://barcode4j.sourceforge.net/index.html

17

YUI Compressor

Minifies JavaScript and CSS files to improve client side performance of web applications.

BSD + MPL License

http://developer.yahoo.com/yui/compressor/

18

Yslow Analyzes web pages and why they are slow based on Yahoo!'s rules for high performance web sites.

MPL v1.1 http://developer.yahoo.com/yslow/

19

Checkstyle Development tool to help programmers write Java code that adheres to coding standards. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

GNU Lesser General Public License

http://checkstyle.sourceforge.net/index.html

Item #


Source

20

Metrics Provides metrics calculation and dependency analyzer plugin for the Eclipse platform. Measure various metrics with average and standard deviation and detect cycles in package and type dependencies and graph them.

Common Public License 1.0

http://metrics.sourceforge.net/

21

JDepend Traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.

BSD License

http://clarkware.com/software/JDepend.html

22

PMD PMD scans Java source code and looks for potential problems like:

•••• Possible bugs - empty try/catch/finally/switch statements

•••• Dead code - unused local variables, parameters and private methods

•••• Suboptimal code - wasteful String/StringBuffer usage

•••• Overcomplicated expressions - unnecessary if statements, for loops that could be while loops

•••• Duplicate code - copied/pasted code means copied/pasted bugs

BSD License.

http://pmd.sourceforge.net/

23

FindBugs Uses static analysis to look for bugs in Java code

GNU Lesser General Public License

http://findbugs.sourceforge.net/index.html

Item #


Source

24

jQuery Cross Slide

jQuery plugin that implements common slide-show animations in Javascript, traditionally only available via Adobe Flash or other proprietary plugins. Cross Slide builds upon jQuery's animation facility, so it is as portable across browsers as jQuery itself (that is, a lot!).This plugin will be used on the Washington Connection home page to rotate/slide the pictures.

MIT / GPL License

http://tobia.github.com/CrossSlide/

25

jQuery Flexigrid

Lightweight but rich data grid with re-sizable columns and a scrolling data to match the headers 1. Resizable columns 2. Resizable height and width 3. Sortable column headers 3. Cool theme 4. Can convert an ordinary table 5. Ability to connect to an Ajax data source (XML and JSON[new]) 6. Paging 7. Show/hide columns 8. Toolbar (new) 9. Search (new) 10. Accessible API This plugin will be used in all the Summary Pages. The plugin loads the page faster when compared to JQuery

MIT / GPL License

accordion.http://flexigrid.info/

26

JQuery Wijmo Tooltip

JQuery wijtooltip widget allows showing a popup tooltip or an overlay that provides information about a target element in a callout or small box. Embed any HTML, images, and text to create a fully customized tooltip. This plugin will be used on the Washington Connection pages wherever the tooltip is required. This will be used more like help feature on the site.

GPLv3 License

http://wijmo.com/wiki/index.php/Tooltip

27 Spring Data-JPA

Spring Data JPA - Simplifies the development of creating a JPA-based data access layer

Apache Software License 2.0

http://www.springsource.org/spring-data/jpa

Item #


Source

28

Apache Santuario for Java

The Apache SantuarioTM project is aimed at providing implementation of the primary security standards for XML XML-Signature Syntax and Processing. XML Encryption Syntax and Processing. The Apache XML Security for Java library supports XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002 and XML Encryption Syntax and Processing, W3C Recommendation 10 December 2002.

Apache License, Version 2.0 (current)

http://santuario.apache.org/javaindex.html

29

Bouncy Castle Bouncy Castle Crypto APIs for Java is a lightweight cryptography API, A provider for the Java Cryptography Extension and the Java Cryptography Architecture. Bouncy Castle enables AES-GCM encryption. Bouncy Castle API is widely used as based JDK and does not provide capabilities for algorithms like AES-GCM.

MIT License http://opensource.org/licenses/mit-license.php

http://santuario.apache.org/javaindex.html

30

HDIV HDIV as a Java Web Application Security Framework. HDIV extends web applications behavior by adding Security functionalities, maintaining the API and the framework specification.

Apache License, Version 2.0 (current)

http://www.hdiv.org/

31

dom4j Open source Java library for working with XML, XPath and XSLT using the Java Collections Framework and with full support for DOM, SAX and JAXP. Copyright by MetaStuff Ltd. Used as part of gradle package.

BSD http://www.dom4j.org/

32

Apache Ant Java build and package utility used to manipulate files for aces.online code promotes and distributions, used as part of gradle package

Apache v2

Item #


Source

33

Jaxen Jaxen is an open source XPath library written in Java. It is adaptable to many different object models, including DOM, XOM, dom4j, and JDOM. Is it also possible to write adapters that treat non-XML trees such as compiled Java byte code or Java beans as XML, thus enabling you to query these trees with XPath too. Java Xpath library used by MotioCI for the version control and testing product for IBM Cognos

Custom license located at http://jaxen.org/license.html

http://jaxen.codehaus.org/

34

commons-collections

Java collection framework extension tool used by MotioCI for the version control and testing product for IBM Cognos also used as part of gradle package

Apache license 2.0

http://commons.apache.org/

35

commons-io Collection of I/O utilities used by MotioCI for the version control and testing product for IBM Cognos. Also used by the testing automation framework when searching for files created on a given date. Used as part of the gradle package.

Apache license 2.0


36

commons-lang Java.lang support tool used by MotioCI for the version control and testing product for IBM Cognos. Also by the testing automation framework when parsing date entries received from the user. Also used as part of gradle package

Apache license 2.0


37

Maven Provides a uniform build system for Java projects and is packaged with m2e. Used as part of the gradle package.

Apache license 2.0

http://maven.apache.org/

38

Gradle Used for simplifying java projects automation build process and easy to manage the subprojects and libraries dependencies.

Apache License Version 2.

http://www.gradle.org

39

SonarQube Used for analyzing and managing code quality. It covers the 7 axes of code quality - architecture & design, comments, coding rules, potential bugs, complexity, unit tests, duplications.

LGPL version3

http://www.sonarqube.org

APPENDIX L DSHS DATA SECURITY REQUIREMENTS

DSHS Data Security Requirements

1. Definitions. The words and phrases listed below, as used in this Exhibit, shall each have the following definitions:

a. “Authorized User(s)” means an individual or individuals with an authorized business requirement to access DSHS Confidential Information.

b. “Hardened Password” means a string of at least eight characters containing at least one alphabetic character, at least one number and at least one special character such as an asterisk, ampersand or exclamation point.

c. “Unique User ID” means a string of characters that identifies a specific user and which, in conjunction with a password, passphrase or other mechanism, authenticates a user to an information system.

2. Data Transport. When transporting DSHS Confidential Information electronically, including via email, the Data will be protected by:

a. Transporting the Data within the (State Governmental Network) SGN or Contractor’s internal network, or;

b. Encrypting any Data that will be in transit outside the SGN or Contractor’s internal network. This includes transit over the public Internet.

3. Protection of Data. The Contractor agrees to store Data on one or more of the following media and protect the Data as described:

a. Hard disk drives. Data stored on local workstation hard disks. Access to the Data will be restricted to Authorized User(s) by requiring logon to the local workstation using a Unique User ID and Hardened Password or other authentication mechanisms which provide equal or greater security, such as biometrics or smart cards.

b. Network server disks. Data stored on hard disks mounted on network servers and made available through shared folders. Access to the Data will be restricted to Authorized Users through the use of access control lists which will grant access only after the Authorized User has authenticated to the network using a Unique User ID and Hardened Password or other authentication mechanisms which provide equal or greater security, such as biometrics or smart cards. Data on disks mounted to such servers must be located in an area which is accessible only to authorized personnel, with access controlled through use of a key, card key, combination lock, or comparable mechanism.

For DSHS Confidential Information stored on these disks, deleting unneeded Data is sufficient as long as the disks remain in a Secured Area and otherwise meet the requirements listed in the above paragraph. Destruction of the Data as outlined in Section 5. Data Disposition may be deferred until the disks are retired, replaced, or otherwise taken out of the Secured Area.

c. Optical discs (CDs or DVDs) in local workstation optical disc drives. Data provided by DSHS on optical discs which will be used in local workstation optical disc drives and which will not be transported out of a Secured Area. When not in use for the contracted purpose, such discs must be locked in a drawer, cabinet or other container to which only Authorized Users have the key, combination or mechanism required to access the contents of the container. Workstations which access DSHS Data on optical discs must be located in an area which is accessible only to authorized personnel, with access controlled through use of a key, card key, combination lock, or comparable mechanism.

d. Optical discs (CDs or DVDs) in drives or jukeboxes attached to servers. Data provided by DSHS on optical discs which will be attached to network servers and which will not be transported out of a Secured Area. Access to Data on these discs will be restricted to Authorized Users through the use of access control lists which will grant access only after the Authorized User has authenticated to the network using a Unique User ID and Hardened Password or other authentication mechanisms which provide equal or greater security, such as biometrics or smart cards. Data on discs attached to such servers must be located in an area which is accessible only to authorized personnel, with access controlled through use of a key, card key, combination lock, or comparable mechanism.

e. Paper documents. Any paper records must be protected by storing the records in a Secured Area which is only accessible to authorized personnel. When not in use, such records must be stored in a locked container, such as a file cabinet, locking drawer, or safe, to which only authorized persons have access.

f. Remote Access. Access to and use of the Data over the State Governmental Network (SGN) or Secure Access Washington (SAW) will be controlled by DSHS staff who will issue authentication credentials (e.g. a Unique User ID and Hardened Password) to Authorized Users on Contractor staff. Contractor will notify DSHS staff immediately whenever an Authorized User in possession of such credentials is terminated or otherwise leaves the employ of the Contractor, and whenever an Authorized User’s duties change such that the Authorized User no longer requires access to perform work for this Contract.

g. Data storage on portable devices or media.

(1) Except where otherwise specified herein, DSHS Data shall not be stored by the Contractor on portable devices or media unless specifically authorized within the terms and conditions of the Contract. If so authorized, the Data shall be given the following protections:

(a) Encrypt the Data with a key length of at least 128 bits

(b) Control access to devices with a Unique User ID and Hardened Password or stronger authentication method such as a physical token or biometrics.

(c) Manually lock devices whenever they are left unattended and set devices to lock automatically after a period of inactivity, if this feature is available. Maximum period of inactivity is 20 minutes.

Physically secure the portable device(s) and/or media by

(d) Keeping them in locked storage when not in use

(e) Using check-in/check-out procedures when they are shared, and

(f) Taking frequent inventories

(2) When being transported outside of a Secured Area, portable devices and media with DSHS Confidential Information must be under the physical control of Contractor staff with authorization to access the Data.

(3) Portable devices include, but are not limited to; smart phones, tablets, flash memory devices (e.g. USB flash drives, personal media players), portable hard disks, and laptop/notebook/netbook computers if those computers may be transported outside of a Secured Area.

(4) Portable media includes, but is not limited to; optical media (e.g. CDs, DVDs), magnetic media (e.g. floppy disks, tape), or flash media (e.g. CompactFlash, SD, MMC).

h. Data stored for backup purposes.

(1) DSHS data may be stored on portable media as part of a Contractor’s existing, documented backup process for business continuity or disaster recovery purposes. Such storage is authorized until such time as that media would be reused during the course of normal backup operations. If backup media is retired while DSHS Confidential Information still exists upon it, such media will be destroyed at that time in accordance with the disposition requirements in Section 5. Data Disposition

(2) DSHS Data may be stored on non-portable media (e.g. Storage Area Network drives, virtual media, etc.) as part of a Contractor’s existing, documented backup process for business continuity or disaster recovery purposes. If so, such media will be protected as otherwise described in this exhibit. If this media is retired while DSHS Confidential Information still exists upon it, the data will be destroyed at that time in accordance with the disposition requirements in Section 5. Data Disposition.

4. Data Segregation.

a. DSHS Data must be segregated or otherwise distinguishable from non-DSHS data. This is to ensure that when no longer needed by the Contractor, all DSHS Data can be identified for return or destruction. It also aids in determining whether DSHS Data has or may have been compromised in the event of a security breach. As such, one or more of the following methods will be used for data segregation.

b. DSHS Data will be kept on media (e.g. hard disk, optical disc, tape, etc.) which will contain no non-DSHS data. And/or,

c. DSHS Data will be stored in a logical container on electronic media, such as a partition or folder dedicated to DSHS Data. And/or,

d. DSHS Data will be stored in a database, which will contain no non-DSHS data. And/or,

e. DSHS Data will be stored within a database and will be distinguishable from non-DSHS data by the value of a specific field or fields within database records.

f. When stored as physical paper documents, DSHS Data will be physically segregated from non-DSHS data in a drawer, folder, or other container.

g. When it is not feasible or practical to segregate DSHS Data from non-DSHS data, then both the DSHS Data and the non-DSHS data with which it is commingled must be protected as described in this exhibit.

5. Data Disposition. When the contracted work has been completed or when no longer needed, except as noted in Section 3. Protection of Data b. Network Server Disks above, Data shall be returned to DSHS or destroyed. Media on which Data may be stored and associated acceptable methods of destruction are as follows:

Data stored on: Will be destroyed by:

Server or workstation hard disks, or

Removable media (e.g. floppies, USB flash drives, portable hard disks) excluding optical discs

Using a “wipe” utility which will overwrite the Data at least three (3) times using either random or single character data, or

Degaussing sufficiently to ensure that the Data cannot be reconstructed, or

Physically destroying the disk

Paper documents with sensitive or Confidential Information

Recycling through a contracted firm provided the contract with the recycler assures that the confidentiality of Data will be protected.

Paper documents containing Confidential Information requiring special handling (e.g. protected health information)

On-site shredding, pulping, or incineration

Optical discs (e.g. CDs or DVDs) Incineration, shredding, or completely defacing the readable surface with a coarse abrasive

Magnetic tape Degaussing, incinerating or crosscut shredding

6. Notification of Compromise or Potential Compromise. The compromise or potential compromise of DSHS shared Data must be reported to the DSHS Contact designated in the Contract within one (1) business day of discovery. If no DSHS Contact is designated in the Contract, then the notification must be reported to the DSHS Privacy Officer at [email protected]. Contractor must also take actions to mitigate the risk of loss and comply with any notification or other requirements imposed by law or DSHS.

7. Data shared with Subcontractors. If DSHS Data provided under this Contract is to be shared with a subcontractor, the Contract with the subcontractor must include all of the data security provisions within this Contract and within any amendments, attachments, or exhibits within this Contract. If the Contractor cannot protect the Data as articulated within this Contract, then the contract with the sub-Contractor must be submitted to the DSHS Contact specified for this contract for review and approval.

8. Security Assessment Requirements. DSHS will require the Bidder’s solution as presented in their proposal, to undergo agency and State security assessments prior to entering into a contract.

COMPETITIVE SOLICITATION #1623-610 REQUEST FOR …€¦ · Project Title: Eligibility Service and...

Documents

Transcript of COMPETITIVE SOLICITATION #1623-610 REQUEST FOR …€¦ · Project Title: Eligibility Service and...