attachment a rfp 4060

Attachment A

RFP 4060

Technical Requirements

TABLE OF CONTENTS

A. How to Respond ............................................................................................................... 1

B. Vendor Qualifications ....................................................................................................... 1

C. Vendor Implementation Team .......................................................................................... 2

D. Current Application — Architecture Overview ................................................................... 2

E. Current Solution — System Materials and Components ................................................... 3

F. Current Solution — Base Functionality ............................................................................. 4

G. Current Solution — Enhancements .................................................................................. 5

H. Access ............................................................................................................................. 6

I. User Interface ................................................................................................................... 6

J. Data Migration .................................................................................................................. 6

K. Ownership of Developed Software ................................................................................... 6

L. Ownership of Data ............................................................................................................ 7

M. Product Updates............................................................................................................... 7

N. Software Administration and Security ............................................................................... 7

O. Project Schedule and Implementation .............................................................................. 7

P. Training and Documentation ............................................................................................ 8

Q. Maintenance and Support ................................................................................................ 8

R. Warranty .......................................................................................................................... 9

S. Additional Requirements .................................................................................................. 9

T. Change Order Process ................................................................................................... 10

Attachment A RFP 4060 Technical Requirements

1 of 10

A. How to Respond

Beginning with Section B, Item 8 of this attachment, label and respond to each outline point within each section as described below.

The Vendor must respond with “ACKNOWLEDGED,” “WILL COMPLY” or “AGREED” to each point in each section of this attachment. In addition, many items in this RFP require detailed and specific responses to provide the requested information. Failure to provide the information requested will result in the Vendor receiving a lower score for that item, or, at the State’s sole discretion, being subject to disqualification.

“ACKNOWLEDGED” should be used when no vendor response or vendor compliance is required. “ACKNOWLEDGED” simply means the vendor is confirming to the State that he read the statement. This is commonly used in the RFP sections where the agency’s current operating environment is described or where general information is being given about the project.

“WILL COMPLY” or “AGREED” are used interchangeably to indicate that the vendor will adhere to the requirement. These terms are used to respond to statements that specify that a vendor or vendor’s proposed solution must comply with a specific item or must perform a certain task.

If the Vendor cannot respond with “ACKNOWLEDGED,” “WILL COMPLY,” or “AGREED,” then the Vendor must respond with “EXCEPTION.” (See Section V of RFP 4060, for additional instructions regarding Vendor exceptions.)

Where an outline point asks a question or requests information, the Vendor must respond with the specific answer or information requested.

In addition to the above, Vendor must provide explicit details as to the manner and degree to which the proposal meets or exceeds each specification.

B. Vendor Qualifications

MANDATORY: Vendor must be capable of and have previous experience in providing vendor hosted, web-accessible fisheries management solutions that meet the technical specifications required by this procurement. Vendor must have been in the business of providing such solutions for at least the last three years.

Vendor must provide at least two examples of fisheries management software currently running in a production environment. Representative solutions should support a user base of greater than one thousand users and at a minimum, must demonstrate core fisheries program management capabilities, data tracking capabilities and robust compliance reporting functions.

Vendor must provide an introduction and general description of its company's background and years in business providing vendor hosted solutions.

Vendor headquarters must be located in the United States and must provide U.S. based customer support.

Vendor must specify the location of the organization's principal office and the number of executive and professional personnel employed at this office.


2 of 10

Vendor must 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).

Vendor must disclose any company restructurings, mergers, and acquisitions over the past three (3) years.

C. Vendor Implementation Team

Vendor must demonstrate that all team members have the necessary experience to design, implement, host, and maintain web-accessible, fisheries management solutions similar in size and scope to the current DMR solution known as Tails n’ Scales, which is more fully described herein.

Identify the primary, key staff members who will be responsible for the execution of the various aspects of the project, including but not limited to project management, development, implementation, testing, and training.

Describe team member roles, functional responsibilities and experience with projects similar in size and scope to the services required by this procurement.

For each team member assigned to the design and implementation of this project, provide a resume or a list of qualifications that shows readiness for this project. Indicate years of experience and length of employment with your company.

Vendor must ensure that each team member assigned to this project has the ability to communicate clearly in the English language, both verbally and in writing.

D. Current Application — Architecture Overview

The following diagram presents a high-level overview of the current system application architecture. It is being provided for your review. You only need to acknowledge that you have reviewed it.


3 of 10

E. Current Solution — System Materials and Components

Upon contract execution, the Mississippi Department of Marine Resources, hereafter referred to as MDMR, will make available to the awarded vendor, the source code and all other system materials necessary to wholly reproduce and fully operate the proposed solution in a manner equivalent to the current solution. Using current system materials, Vendor must reproduce and implement the proposed solution with full functionality, whether or not a specific function is described or included as a requirement in this Attachment to RFP 4060.

Vendors who want to view a representative sample of the existing source code and system materials while preparing a response to this RFP should submit their request to Jeannie Williford using the contact information on the RFP cover page.

Vendor must provide software, hardware, and networking technologies to provide managed hosting services for the proposed solution.

Secure Web Portal: Vendor must provide a secure web portal in accordance with the current solution standards, which are detailed below:

The web portal contains the web application which is accessed by all users. The web portal requires all communication via SSL. The web portal is developed using the Angular.js framework and supports a partially responsive design. The system is built using HTML, CSS, JavaScript and AJAX based technologies. The web portal consumes PHP-based web services, provides validations and other business logic along with the user interface. The system uses a Model View Controller architecture. For each component there is a controller file that handles business logic and the view file, which decides the user interface. The view components are used for displaying the content and managing user interface validations. The views use the CSS file, images and bootstrap libraries present for displaying the various data forms and also to support responsive design in mobile devices. The views use Angular.js directives like ng-max, ng-pattern, ng-required for form level validation.

View controller: All business logic is performed in the view controller. The view controller uses the view data and invokes the appropriate service methods to perform business validations.

If vendor proposed solution exceeds the standards of the current solution, Vendor should detail the extent to which the present standards would be exceeded.

Web Services: Vendor must provide web services in accordance with the present standards, which are detailed below.

The web services are developed using the PHP-based Yii framework. The Yii framework acts as a link between the database and web portal and hybrid app. It exposes several REST API endpoints that use JSON over HTTPS to transfer application related data from the mobile app and web server. In several instances, the Yii framework also provides business logic, i.e.: generation of user tokens, sending emails, etc. Each view has its own service. Services will call appropriate REST API PHP calls to store and retrieve data from the database.


4 of 10


Hybrid Apps: Vendor must provide hybrid apps in accordance with the present standards, which are detailed below.

The iOS and Android mobile apps were developed using Apache Cordova and the Ionic framework. Since Ionic framework is based on the Angular.js methodology the mobile apps also consume the same web services that were exposed. Apache Cordova provides the core framework to wrap the HTML/CSS/JavaScript based application code into a hybrid app. To fine tune the mobile application, XCode for iOS Apps and Android Studio for the Android platform are utilized.


Database/Server: Vendor must provide database/server services in accordance with the present standards, which are detailed below.

The web portal is hosted on a Debian Linux (64 bit, 2 core, 8GB RAM, 100GB HDD) server instance in the Linode cloud. The application uses a single MySQL database to store all application data.

The application uses MySQL as the Database Management system. The entire application uses a single database to store the information running on the same host where the application server is running. The production host server is a Debian Linux Linode instance.


F. Current Solution — Base Functionality

Listed below are descriptions of critical base functions of the current solution. This list is not all-inclusive. Vendor must agree to incorporate all functionality of the current solution in the proposed solution, even if it is not specified in this document.

Vendor must agree that all functionality in the proposed solution will meet or exceed the ease of use standards of the current solution.

Upon first use, the angler registers in the system via an email address and provides basic demographic information. Each email address is validated via a link sent through an email response. Vendor must reproduce this functionality in the proposed solution.

After successful registration, the angler has the ability to create a new trip, close an already open trip, review previous trips, and view current weather information. The reporting system will only allow one open trip at a time per angler. Vendor must reproduce this in the proposed solution.

When creating a new trip, the angler provides basic trip information and the system issues a unique trip authorization number. This number is issued to one


5 of 10

angler per vessel, not to each individual aboard the vessel. The trip authorization number is emailed to the angler. This number is unique for each trip. Vendor must reproduce this functionality in the proposed solution.

Upon trip completion, the angler enters harvest data and other trip information into the system. The angler is then able to create a new trip, review previous trip data or exit the system. Angler is unable to create a new trip until the previous trip data is successfully provided. Vendor must reproduce this function in the proposed solution.

All reporting and tracking functionality within the current solution must be replicated in the proposed solution.

The current solution contains the following permissions-based, user roles. User roles are assigned by the administrator after the user profile is created. The proposed solution must include the roles presently defined, as described below.

Angler: The default user role allows public users to create or close trips and view their personal archived data.

Administrator: Used by MDMR staff for managing and reporting within the system. Staff can modify user profiles, review all trip information and export data for reporting purposes. The administrator role is the only role with full access to all user information as well as the ability to create, change, and delete users.

Law Enforcement: Used by MDMR law enforcement to view daily trip authorizations and vessel identification numbers to verify Tails n' Scales program participation and more easily provide on-the-water enforcement.

Call Center Agent: Used by external call center employees to assist with trip creation when an angler does not have access to the web portal or mobile app, register new users and change forgotten passwords.

Other roles as defined by MDMR, or to be defined by MDMR.

G. Current Solution — Enhancements

The following enhancements are necessary to support new fisheries management objectives:

In addition to red snapper, proposed solution must accommodate the capture of information on multiple species for a given trip. MDMR will define the additional species to be tracked by the solution as needed.

Proposed solution must allow the system administrator(s) to control which users are given multi-species harvest options.

Proposed solution must be able to send trip authorizations, expired trip reminders, and additional notifications as defined by MDMR, to users via SMS text and other viable mobile notification methods.

Proposed solution must be able to send SMS text and mobile notifications to individual users and/or groups of users.

Proposed solution must allow MDMR system administrator(s) to control individual user access to all or part of the solution.

Proposed solution must allow MDMR system administrator(s) to add new user profiles to the ones already defined in the current system.


6 of 10

Vendor's Cost Information Submission, Section VIII of this RFP, must specify costs to provide the enhancements to the current solution.

H. Access

Proposed solution must offer the same accessibility as the current solution. The current solution offers two forms of access: a secure web portal and a mobile app that accommodates iOS and Android users.

Functionality for the public user (angler) must be the same, whether accessed from the secure web portal or the mobile app.

Proposed solution must be compatible with the current version and two preceding versions of common browsers including Chrome, Internet Explorer, Microsoft Edge, Firefox, and Safari.

Note: The current solution requires an active internet connection to function. There are currently no off-line features.

I. User Interface

MDMR intends for the user interface of the proposed solution to be as closely matched to the current solution as possible. To minimize user confusion and to prevent the need for additional training for existing users, Vendor must provide a user interface that looks and feels like the current solution.

To view the user interface and experience the current solution, vendors may access the web portal and register as a test user with the following information.

1. Website: https://tailsnscales.org

2. Userid: [email protected]

3. Password: reppans2018

4. Apple App Store & Google Play Store app name: Tails n’ Scales

Vendor must be able to match the current user interface as described above. However, Vendor may also propose improvements or updates to the look and feel of the user interface so long as the functionality remains the same. If Vendor proposes to change the look and feel of the user interface, Vendor must adequately demonstrate the recommended user interface so that MDMR can assess whether or not to accept the recommendation.

J. Data Migration

Vendor must guarantee that all registered users and related trip information contained in the current solution database will be successfully migrated to the proposed solution.

Vendor must guarantee that all archived information within the current solution database will be successfully migrated to the proposed solution.

K. Ownership of Developed Software

Vendor must acknowledge and agree that MDMR is the sole owner of any and all software developed in response to this procurement, with exclusive rights to use, alter, or distribute the software without restriction. This requirement applies, but is not limited to, source code, object code, and documentation.

https://tailsnscales.org/

mailto:[email protected]


7 of 10

L. Ownership of Data

Vendor must acknowledge and agree that MDMR is the sole owner of any and all database content migrated from the current solution to the proposed solution, and any future database content created within the awarded vendor solution, with exclusive rights to use the database content without restriction.

M. Product Updates

Describe your release management methodology and processes for updating your software for all types of releases, including but not limited to:

Security Updates

System Maintenance

System Enhancements

Education and Training

System Enhancements and updates must be included with annual maintenance fees. Annual maintenance fees must be specified in the Vendor's Cost Information Submission, Section VIII of this RFP.

N. Software Administration and Security

Proposed solution must provide controlled access to features and functions by configurable, role-based permissions as defined by the current solution.

Proposed solution must validate each angler's email address.

Proposed solution must accommodate secondary backup methods by MDMR.

Proposed solution must adhere to all relevant security protocols and privacy standards, and Vendor must agree to implement all relevant security updates.

If the proposed solution exceeds the software administration and security standards of the current solution, Vendor should present in detail how the proposed solution exceeds the standards of the current solution.

O. Project Schedule and Implementation

MDMR intends to implement the proposed solution no later than April 5, 2018. All system functionality, including the enhancements required in Section G of this document, MDMR user acceptance testing, and MDMR staff training must be completed in order to go-live by April 5, 2018. This schedule presumes that contract negotiations will be completed by March 14, 2018.

Provide the implementation milestones and estimate the amount of time you will require for each one so that MDMR can assess your ability to implement the proposed solution by April 5, 2018.

Present the details of your implementation plan, which must include, but not be limited to development, user testing and acceptance processes, user training and production.

In your implementation plan, all customizations, integrations, interfaces, and hosting services must be tested and validated.


8 of 10

MDMR expects the Vendor to work with the MDMR project manager to ensure effective project management during all project phases.

As it relates to this procurement, state all Vendor assumptions or constraints regarding the proposed solution and overall project plan, timeline, and project management.

Identify any potential risks, roadblocks and challenges you have encountered in similar implementations that could negatively affect a timely and successful completion of the project. Recommend a high-level strategy to mitigate these risks.

P. Training and Documentation

For any enhancements or processes that cause the system to be used or administered in a way that is different from the current solution, Vendor must document such differences and adequately train MDMR staff in the new methods, and must make suitable training available to public users.

Describe your method of providing training for MDMR staff and public users. MDMR prefers personal training for MDMR staff. MDMR will accept web-based training for public users, assuming it will adequately and clearly inform public users.

Proposed solution must provide thorough online tutorial documentation geared toward infrequent users.

Vendor must provide training documentation and keep it updated as appropriate. Web-accessible format is acceptable to MDMR.

Q. Maintenance and Support

Vendor must commit to maintaining active support for all current and proposed solution components.

Vendor must commit to maintaining support for latest mobile and non-mobile operating systems and web browsers, with ongoing support as updates are released.

For critical issues, MDMR must have direct access, by phone and email, to a vendor service representative during regular business hours, Monday-Friday from 8:00 a.m. to 5:00 p.m. Central Standard Time.

For critical service issues, MDMR requires Vendor’s response within one hour of intake and trouble resolution within four hours of intake by Vendor.

For non-critical service issues, MDMR requires Vendor’s response within four hours of intake and resolution within 24 hours of intake by Vendor.

Describe how trouble and support issues are reported.

Describe your trouble resolution process.

Detail your process for receiving, recording, tracking and resolving software issues identified by the users of the software.

Detail your service levels and trouble escalation procedures.


9 of 10

Upon implementation, Vendor is required to provide complete documentation of all support processes and keep it updated at all times. Web-accessible format is acceptable to MDMR.

Describe your policies and procedures for notifying users of scheduled maintenance, unscheduled maintenance, emergency maintenance, downtime, system errors, or degraded performance.

Vendor must provide advance notice on all scheduled maintenance activities.

Proposed solution must maintain the production environment at a 99% availability rate, including scheduled maintenance. All maintenance and updates must be completed in a test environment prior to go-live.

Vendor's Cost Information Submission, Section VIII of this RFP, must specify costs to provide the proposed support on an annual basis, for up to five years.

R. Warranty

The warranty period is a one-year period during which the Vendor must warrant, at no cost to MDMR, all work performed as stated in RFP 4060, Vendor’s proposal, and any subsequent Statement(s) of Work. The warranty period must include the necessary vendor support to correct any deficiencies found and to provide any other consultation as needed.

For any phased implementations or processes, the warranty period for each phase or process will begin only when Vendor has fully implemented the phase or process and MDMR has accepted the phase or process as functioning properly and in coordination with any previously implemented phase(s) or process(es).

The Vendor must agree to warrant all proposed application software to be free of errors for a minimum period of one year after acceptance. During this period, the Vendor must agree to correct, at his own expense, any discovered errors. If the system fails during warranty period due to a defect, the Vendor will offer a workaround solution within 24 hours and a full fix within five business days.

The Vendor must state and discuss the full warranty offered during the warranty period on all proposed software and services and indicate if it is longer than the minimum.

This warranty must cover all components for which services were provided, including all programs, forms, screens, reports, subroutines, utilities, file structures, documentation, interfaces, conversions, configurations, or other items provided by the Vendor.

The Vendor must agree that all corrections made during the warranty period are integral to work associated with this project, and will therefore be made at no additional charge.

S. Additional Requirements

ITS acknowledges that the specifications within this RFP are not exhaustive. Rather, they reflect the known requirements that must be met by the proposed solution. Vendors must specify, here, what additional components may be needed and are proposed in order to complete each configuration.


10 of 10

If any components necessary for the successful operation of the proposed solution are omitted from the Vendor’s proposal, Vendor must be willing to provide the component(s) at no additional cost. This includes, but is not limited to all components necessary for vendor hosting, secure web portals, web application servers, web services, mobile and non-mobile access, mobile and hybrid applications, database/servers, networking, technologies, and support and maintenance of the proposed solution.

T. Change Order Process

After implementation and acceptance of the services procured by this RFP, MDMR may require additional services, such as enhancements or other system related needs. Vendor must include a fully loaded change order rate as a separate line in the Vendor’s Cost Information Submission, Section VIII of this RFP.

attachment a rfp 4060

Documents