REQUEST FOR PROPOSALS
“Status Board 2”
Minnesota Department of Public Safety
Division of Emergency Communication Networks
Project Overview
The purpose of this project is to deploy a secure internet-based application that mirrors and expands upon the functionality of the Status Board application. For convenience, the internet-based version of this application is to be called “Status Board 2”.
Status Board is an application used to coordinate the use of shared interoperability resources, and in particular, those available through Allied Radio Matrix for Emergency Response (ARMER). Status Board is an existing application operating upon dedicated clients on a closed network (ARMER), and is not accessible by any entity that does not have the client installed on their computer and is not connected to the closed network.
ARMER is a shared, interoperable, statewide project 25 trunked radio system. A talkgroup is a radio communications channel over this statewide network. All users whose radios are set to a specific talkgroup, or channel, will talk to all other users whose radios are set to the same channel. Each user of ARMER includes within their fleet two types of talkgroups:
· Operations talkgroups, which are used for routine, internal communications (e.g., for a particular police department)
· Interoperability talkgroups, which are used for mutual aid operations (e.g., for a particular police department from County A to speak to EMS responders from County B)
Users of ARMER include interoperability talkgroups in all radios programmed to operate on the radio system. Interoperability talkgroups generally fit into one or more of the following categories:
· Statewide
· Regional
· Discipline-Specific
· Special
Consequently, the set of interoperability talkgroups is not the same for each user of ARMER
The coordination of interoperability talkgroups is a significant planning and coordination issue. A talkgroup cannot be assigned to two separate events at the same time. Current standard operating procedure dictates that the first available talkgroup is assigned to a particular incident. The purpose of Status Board is to assist in determining which interoperability talkgroups are available at any given moment.
“Interoperable communications resources” includes, for the purposes of this project:
· Interoperability talkgroups, (S-TAC, F-TAC, CM-TAC, etc)
· Interoperability channels (VCALL/VLAW, 8CALL/8LAW, IR, LE, etc)
· Other categories at the discretion of individual administrators
Through Status Board, users may claim or schedule use of shared interoperability resources for a specific period of time, such as at the present or at some point in the future. Status Board does not control access to shared talkgroups or dictate the performance of talkgroups in any way; rather, Status Board is a place where one user may notify others that a shared resource is in-use. It is a place to claim temporary ownership of a particular talkgroup or to assign it to a specific event (such as a major training exercise or joint response).
Presently, Status Board is a Windows application utilizing a shared database over the ARMER network. Accordingly, only dispatch operators with interconnected workstations are capable of using the application. This configuration restricts the pool of users with access to Status Board to the population of ARMER users who have interconnected dispatch consoles; those without interconnected consoles and/or who are not ARMER users do not have access to Status Board. Accordingly, it is the directive of the Statewide Radio Board that Status Board is deployed on the public internet. Currently, about 75% of users of ARMER have access to Status Board, but only 50% of public safety answering points (PSAPs) do.[a]
Status Board 2 is an application that has, at minimum, full feature parity with the original Status Board in addition to other features described in the Tasks section below. Principally, Status Board 2 is accessible through the public internet with secure login in addition to other features such as calendar scheduling.
It is the intention of this project to replace Status Board with Status Board 2.
This project supports ECN’s mission to provide comprehensive emergency communication networks. This project will substantially enhance interoperability in the state of Minnesota by opening access to Status Board 2 to all users throughout Minnesota, and not exclusively PSAPs with direct connections to the closed ARMER network as is presently the case.
Goal
The goal of this project is to enhance public safety communications interoperability in the state of Minnesota through deploying a version of Status Board on the public internet. Deploying Status Board on the internet will allow access by:
· All dispatchers, regardless of whether their dispatch consoles are interconnected with ARMER
· All users, regardless of whether the user is a dispatcher
· All devices with a supported web browser
Additionally, it is the goal of this project to provide needed enhancements to the Status Board application, such as calendar scheduling and local administration, view filters, and reports.
It is the vision of this project that field users, such as Communications Unit Leaders (COMLs), would be capable of viewing Status Board from a portable device in addition to every dispatcher in the state of Minnesota. In special cases, Status Board may be viewable by field responders as well. It anticipated that only public safety communications dispatchers would have write access to Status Board.
Tasks
The Contractor selected through this RFP shall develop a web-based application, Status Board 2, that has, at a minimum, full feature parity with Status Board in addition to other features described in this scope of work. The Contractor shall also provide a plan for hosting the application with 99.999% (five nines) availability, through an ongoing service agreement with the Contractor or, at its option and with approval of the State, through a third party.
The application shall be developed to the following specifications:
1. Access; The application must be or include:
A. Available through Public Internet
B. User Authentication
C. Secure Connection
D. Refresh rate; configurable by:
a. User
b. System-wide (default and minimum/maximum for all users to override user refresh rate)
2. Resources; Application Interoperability Resources must be or have:
A. Administrator-defined; i.e., an administrator user must be able to add, change, remove, and delete any resource that administrator has control over
B. The following fields:
I. Resource Name
II. Resource Description
III. Event Description/Purpose for Reservation
IV. Claimed Start (time and date)
V. Claimed End (time and date)
VI. Claimed by (reference to User)
VII. Resource Owner
VIII. Resource Access Permissions (per account type; per organization)
3. Scheduling; Application scheduling feature must support the following:
A. Resources to be scheduled for numerous sessions into the future
B. Resources to not have overlapping reservations
I. An attempt to schedule an overlapping reservation shall prompt the user with an error message. This error message shall provide contact information for the entity placing original reservation.
C. Scheduled reservations shall include user-viewable information indicating the user who has reserved the resource.
D. Administrative Override
4. GUI; The application user interface must support:
A. In general, a similar interface to the original Status Board application
B. View Filters; to be configurable by the appropriate administrator
C. Multiple view levels
I. Overview or Dashboard
II. Detail View for Resource
III. Calendar View
IV. Each view shall support the addition, removal, or change of a schedule resource reservation
5. Administration; Administration shall be organized into the following hierarchy:
A. User Accounts
I. Actions
a. View
b. Reserve
c. Change
II. Info
a. Name
b. Organization (e.g., agency)
c. Email
d. Telephone
e. Alt Telephone
f. Alt Contact
III. Access Level, to be configurable per resource; e.g., each user shall be configured to be allowed to view, reserve, and/or change each resource with permissions either unique to that combination of user and resource or as applicable to that combination of user and resource category, at the discretion of the appropriate administrator
B. Administrator Accounts
I. Add/ Change/Disable/Remove Users
II. Access level configurable by resource and/or user. Levels are to be divided into the following hierarchy:
a. Statewide “Super” user; full access
b. Regional
c. County
d. Local
e. Organizational
f. Other categories to be configurable by a Statewide “Super” user. These categories may be placed above or below any of the preset categories described above.
III. An administrator may create or edit the permissions of other administrators and users at or below the same level.
6. Portability
A. Support >90% market share desktop-oriented web browsers[b]
I. IE—38.9%
II. Firefox—25.5%
III. Chrome—20.2%
IV. Safari—7.7%
B. Support for >90% market share mobile-oriented browsers[c]
I. WebKit browsers (Safari Mobile, Android Browser, etc)—54%
II. Opera Mini/Mobile—20%
III. Blackberry Browser—18%
C. Low-overhead [d]
I. No high-overhead frameworks; e.g. Flash, Silverlight/.Net, etc
II. No high-overhead middleware such as Sharepoint
III. No user plugin installation required
7. Reports
A. User
I. Login time
II. Login attempts
III. # refreshes
IV. User settings
V. User activity
B. Resources
I. Events; time reserved, reserved by, etc.
C. System/Database Information
I. # Users
II. # Accounts
III. # Number Resources
D. Records, in general, shall be exportable in .CSV format
8. Application Help File; The application must have a help file available to users which includes:
A. General description of software
B. Description of each command in Status Board available to the user
C. Description of each command in Status Board available to the administrator
D. Support and use information in general, per industry best practice for application help file
The application hosting plan must include the following:
· Availability and Resiliency
I. “24x7x365” availability
II. 99.999% aggregate uptime (five nines)
III. Any pre-planned downtime (e.g., a maintenance window) is to be agreed upon by DECN five business days prior to the scheduled downtime.
· Scale; hardware must be sized to accommodate:
I. <5000 concurrent sessions
II. <30,000 user accounts
III. <1000 resources
IV. <500 Scheduled Events
V. <100 Concurrent administrative actions
a. User changes
b. Reports/Data Dumps
VI. Refresh rate of at most 60 seconds, per activity levels described above
· Terms of hosting arrangements
· Expenses
I. Non-recurring
II. Recurring (e.g., monthly, annually)
The Contractor shall deliver the most current version of application source code to DPS every first and third Monday of each month throughout the duration of development. In the event that there are no changes to the application source code between the first and third Monday of each month, the Contractor shall certify, in writing, that no changes have been made to the application’s source code.
The Contractor shall include programmer’s comments in the application source code per industry best-practice sufficient to describe the operation of each class, function, method, and/or other comparable category of organization within the source code.
The Contractor will have direct access to the State’s assigned project manager, Brandon Abley, Minnesota Department of Public Safety, Division of Emergency Communication Networks, as well as a workgroup formed to oversee the Status Board 2 project. The Contractor will not have substantial resources from the State to support this project outside of the aforementioned staff who will serve in advisory roles. The Status Board workgroup shall be considered this project’s project steering committee.
Any change requests to the project scope or to individual tasks shall be submitted, in writing, by either the Contractor or the State, with minimum 2 weeks’ advance notice of the project change.
Project Deliverables:
ECN anticipates the following project deliverable schedule:
DELIVERABLE / DUE / DESCRIPTIONContractor work plan and schedule / Week 1 / The Contractor shall provide a plan of the Contractor’s work, including any changes to the anticipated deliverable schedule.
Hosting Arrangements / Week 2 / The Contractor shall provide detail for its hosting arrangements as indicated in its proposal.
Application and Data Logic / Week 3 / The Contractor shall provide a detailed written description of the application and network logic and theory of operation.
User Application GUI / Week 5 / The Contractor shall provide an initial GUI (Graphical User Interface) for the application. The GUI may be mockup images and non-functional, but should accurately reflect the planned final GUI each user will see.
Hosting Setup / Week 6 / The Contractor shall have completed all substantial work to meet hosting arrangements as indicated in its proposal and modified, if applicable, between weeks 1-6.
Database Prototype / Week 7 / The Contractor shall have completed setting up and configuring the application database.
Prototype User Application / Week 9 / The Contractor shall provide a functional working prototype of the user application. The prototype shall be feature-complete, but may be a development build that does not yet perform to the indicated reliability specifications in the RFP.
Completed Database / Week 11 / The Contractor shall have completed development of major database work.
Completed user Application / Week 13 / The Contractor shall have completed all work on the user application.
Source Code / Week 14 / The Contractor shall deliver the final version of application source code and foundational data.
Acceptance and Close / Week 15 / The Contractor shall have completed all application development work.
The Contractor shall agree to a weekly project conference call to briefly outline the status of deliverables, answer any questions, and accept any input from the project manager and Status Board Workgroup.
The prototype database and user application shall be tested continuously by members of the project steering committee and the PSAP community throughout weeks 7-13. It is expected that the Contractor shall keep a detailed errors and issues log and will correct any errors, or “bugs”, in the application software by close of week 13.
The Contractor is not expected to populate the application database outside of test data. Data entry will be performed by the customer after project acceptance and close.
The Contractor shall begin on the date stated in contract or upon full execution of the contract, whichever is later, and will substantially complete development work by May 30, 2012.
The term of the contract is anticipated to run from April 2, 2012 to June 30, 2012, which the option to extend an additional four 1-year periods.
Responders are encouraged to propose additional tasks or activities if they will substantially improve the results of the project. These items should be separated from the required items on the cost proposal.