170025 solución para la gestión integral de las ... · 2.4 aplicaciones auxiliares: euskarri. ......

170025 Solución para la gestión integral de las emergencias del servicio de bomberos.

Pliego de Bases Técnicas

170025 Solución para la gestión integral de las emergencias del servicio de bomberos

Unitatea

Unidad:

Informatika

Informática

-

Contenido

1 Perfil de la compañía .............................................................................................. 4

1.1 Introducción y estrategia de administración electrónica ......................................... 4

1.2 Finalidad y objetivos del proyecto ............................................................................. 5

2 Introducción ............................................................................................................ 5

2.1 Aplicaciones de Gestión: Bomberos Intervención. .................................................. 5

2.2 Aplicaciones GIS: Salidas, EmerCAD, EmerGIS, EmerWEB. ................................... 6

2.3 Aplicación PLCs: TELEMANDO .................................................................................. 7

2.4 Aplicaciones Auxiliares: EUSKARRI. ......................................................................... 7

3 Objeto de expediente de contratación .................................................................. 8

4 Requisitos ................................................................................................................ 8

4.1 Requisitos generales ................................................................................................... 8

4.2 Requisitos específicos de Gestión de Emergencias .............................................. 10

4.3 Requisitos específicos de WebMapping de Emergencias ..................................... 11

4.4 Requisitos específicos de Salidas de Emergencias ............................................... 11

5 Requisitos de integración con otras aplicaciones ............................................. 11

5.1 Resumen de integraciones: necesarias y otras ...................................................... 11

5.2 Integraciones necesarias .......................................................................................... 12 5.2.1 Bomberos Intervención ......................................................................................... 12 5.2.2 TELEMANDO ........................................................................................................ 15

5.3 Otras integraciones a tener en cuenta ..................................................................... 15 5.3.1 Localización de Recursos en Tiempo Real ........................................................... 15 5.3.2 Gestión de Comunicaciones ................................................................................. 16 5.3.3 Web de la DFG ..................................................................................................... 16

6 Requisitos Funcionales del Sistema GIS de Emergencias ................................ 16

6.1 Resumen de las funcionalidades requeridas .......................................................... 16

6.2 Aplicación Gestión de Emergencias ........................................................................ 17 6.2.1 Módulo de Gestión de Intervenciones ................................................................... 17 6.2.2 Módulo de Tácticas Operativas ............................................................................. 21

6.3 Aplicación WebMapping de Emergencias ............................................................... 22 6.3.1 Módulo de Cartografía .......................................................................................... 22

6.4 Aplicación Salidas de Emergencias ......................................................................... 25 6.4.1 Módulo de Navegación ......................................................................................... 25


Unitatea

Unidad:

Informatika

Informática

-

7 Contenido de la oferta técnica ............................................................................. 25

8 Información complementaria a aportar relativa a las condiciones del servicio de postventa y asistencia técnica de la solución ..................................................... 27

9 Plazo de ejecución y entrega ............................................................................... 28

10 Plazo de garantía ............................................................................................... 28

11 Confidencialidad y seguridad ........................................................................... 28

11.1 Recursos humanos .................................................................................................... 28

11.2 Sistemas...................................................................................................................... 28

11.3 Acceso y protección de datos .................................................................................. 29

12 Procedimiento de consulta técnica .................................................................. 29

Criterios de adjudicación ............................................................................................ 30


Unitatea

Unidad:

Informatika

Informática

-

1 Perfil de la compañía

IZFE, S.A. es una sociedad pública de la Diputación Foral de Gipuzkoa que tiene definidos, con carácter general, en su objeto social, los fines siguientes:

El estudio, desarrollo y racionalización de los procesos de captura, almacenamiento,

tratamiento y explotación de información mediante la utilización de tecnología de la

información.

La prestación de servicios informáticos a la Diputación Foral de Gipuzkoa y la

colaboración con ella en la esfera propia de dichos servicios para el cumplimiento de

sus fines.

La cooperación en la realización de estudios e informes que se le requieran en

materia de organización, implantación de nuevos servicios, programas y procesos.

IZFE, tiene la condición de medio propio y servicio técnico de la Diputación Foral de Gipuzkoa pudiendo conferirle encomiendas y adjudicarle contratos en los términos y con las condiciones que se determinen por los órganos correspondientes en cada caso.

La sociedad es el instrumento del que se dota la organización de la Diputación Foral, para alcanzar los objetivos en relación a la implantación y desarrollo de la administración electrónica y a sus Sistemas y Tecnología de la Información, previstos en el modelo director de la función informática.

1.1 Introducción y estrategia de administración electrónica

Este documento constituye el Pliego de Bases Técnicas para la contratación del desarrollo e implantación de una solución informática para la planificación y gestión de las emergencias encomendadas al Servicio de Prevención, Extinción de Incendios y Salvamento, del Departamento Gobernanza y Comunicación, de la Diputación Foral de Gipuzkoa.

El proyecto se enmarca, en ámbito de la evolución de los servicios implementados por la administración electrónica prestados por la Diputación Foral de Gipuzkoa, en el marco de la modernización del sector público y en el marco de la mejora y la eficacia en el servicio que se tiene que dar a los ciudadanos, constituyendo éste un objetivo fundamental.

Es una realidad que seguridad y tecnología están íntimamente unidas. La incorporación de las nuevas tecnologías en la gestión de esta administración facilita la prevención de riesgos, permite la alerta temprana y ayuda a minimizar los daños derivados de las catástrofes y emergencias.

Por ello, es necesario contar con los últimos avances tecnológicos que faciliten una mayor optimización de los objetivos y dotarse de elementos que faciliten la alerta temprana, lo que permite estar atentos para disponer y coordinar todos los medios necesarios, así como anticipar determinadas situaciones que puedan producirse.


Unitatea

Unidad:

Informatika

Informática

-

Las tecnologías de la información y la comunicación desempeñan un papel fundamental en la gestión de las emergencias. Su implantación en el ámbito de la protección ciudadana requiere de un sistema, que permita facilitar la toma de decisiones, así como la sincronización y coordinación de las acciones necesarias para responder ante ellas.

Se requiere, entre otros aspectos, mejorar la rapidez y la eficacia en la atención de la emergencia; optimizar los diversos procesos que desarrollan los diferentes cuerpos y servicios que se movilizan para minimizar las situaciones de riesgo; facilitar el acceso a la información de manera fiable y precisa, así como compartirla; incrementar la eficiencia de los procesos y facilitar herramientas para la planificación de la prevención y la actuación.

1.2 Finalidad y objetivos del proyecto

La finalidad de la solución informática demandada en el objeto de este pliego, permitirá al Servicio de Prevención, Extinción de Incendios y Salvamento, del Departamento Gobernanza y Comunicación, de la Diputación Foral de Gipuzkoa, satisfacer entre otros, los siguientes objetivos estratégicos básicos en el ámbito de la mejora del sistema de gobernanza y seguridad de Gipuzkoa:

Dotar, por medio de las tecnologías y los sistemas de información dentro de la administración electrónica, de una mayor eficiencia a los servicios de gestión de las emergencias, extinción de incendios y salvamento prestados.

Garantizar el servicio prestado a los ciudadanos por la Administración Foral de Gipuzkoa permitiendo optimizar los parámetros de calidad y eficiencia en estas materias.

Ofrecer una solución digital avanzada que asegure la gestión eficaz de todos los aspectos relacionados con las emergencias y actuaciones, garantizando efectivamente una mayor protección y seguridad del ciudadano y de las personas que prestan dichos servicios.

2 Introducción

El servicio de bomberos de la DFG comprende 8 parques y BAIESAN.

BAIESAN es el centro de control (actualmente ubicado en las dependencias de la DFG) encargado de gestionar todas actuaciones que se producen en el territorio de Gipuzkoa, a excepción de las actuaciones de Donostialdea. Este servicio permanece activo las 24h del día, 365 días al año.

El sistema integrado de gestión de bomberos de la DFG comprende un conjunto de aplicaciones independientes que se usan en el BAIESAN, divididas en 4 bloques principales y que se comportan de la siguiente manera:

2.1 Aplicaciones de Gestión: Bomberos Intervención. Es la aplicación donde principalmente se gestionan los diversos recursos del servicio: parques, personas y vehículos. Estos recursos están disponibles en las aplicaciones GIS y PLCs mediante “vistas” que apuntan a las BD de la aplicación Bomberos Intervención.


Unitatea

Unidad:

Informatika

Informática

-

2.2 Aplicaciones GIS: Salidas, EmerCAD, EmerGIS, EmerWEB.

SALIDAS: aplicación WEB que visualiza en los parques la ruta a seguir hasta el lugar de la actuación a modo de facilitar el itinerario a los bomberos: en el momento en que BAI ESAN localiza el QTH (lugar del siniestro) en EMERCAD, en las pantallas colocadas en los parques se puede ver la ubicación de la intervención y el itinerario desde el parque hasta el QTH. Permite optar entre el itinerario propuesto por Google Maps y el propuesto por Openstreetmap.

Complementariamente a la aplicación de Salidas y para el mismo fin, el personal hace uso de:

1. Una aplicación de mapping (GOOGLE MAPS) para destinos que se pueden ir por carretera. Compartimos una misma cuenta entre BAI ESAN y las diferentes tablet del Servicio: una tablet por parque y Sargentos de guardia. En BAIESAN localizamos el QTH y lo guardamos. Automáticamente el lugar puede ser consultado en todas las tablet y pueden navegar mediante Google Maps.

2. En casos de rescate de montaña u otras intervenciones fuera de la red de carreteras, el sistema de proporcionar itinerarios hasta el QTH es a través de cargar las coordenadas del lugar en la aplicación Orux Maps GFA y navegar hasta ese punto siguiendo la información que proporciona dicha aplicación. Está sin resolver satisfactoriamente el traspaso de las coordenadas desde BAIESAN a las tablet de los bomberos. En la actualidad BAIESAN envía las coordenadas en formato kml por correo electrónico al dispositivo seleccionado.

EMERCAD: aplicación de Gestión de Actuaciones (sólo se usa en BAIESAN). Tiene integración con la aplicación de Gestión de Bomberos Intervención (recoge el personal que está de turno en el momento de la actuación, vehículos disponibles e información de parques). También se integra con la aplicación de EmerGIS, ya que cabe la posibilidad de importar las coordenadas de la actuación desde ahí (para edificios se usan coordenadas y para las zonas topónimos). Para finalizar, también puede importar información de la actuación desde el Telemando (aplicación PLC). Generalmente las actuaciones primero se levantan en el Telemando y luego se importan desde EmerCAD.

Es en EmerCAD donde se actualiza el QTH (lugar de la intervención) y se envía a la aplicación de Salidas.

EMERGIS: Aplicación cliente/servidor que se utiliza para referenciar geográficamente las actuaciones (sólo se usa en BAIESAN). Tiene integración con EmerCAD (exporta las coordenadas de las actuaciones). También es posible generar directamente cualquier actuación en esta aplicación y exportarla a EMERCAD.

Desde EMERGIS (Acceso a terceros→ Externos→ Google Maps) también es posible marcar el QTH que luego verán reflejado en los tablets con Google Maps.


Unitatea

Unidad:

Informatika

Informática

-

EMERWEB: aplicación WEB de consulta de actuaciones. Existen 3 mapas:

1. Mapa usado por jefatura.

2. Mapa usado por los parques.

3. Mapa público.

Dependiendo del perfil que accede a la aplicación tienen acceso a uno u otro mapa.

2.3 Aplicación PLCs: TELEMANDO

TELEMANDO: aplicación PLC cuya finalidad es controlar de forma remota diferentes instalaciones de los parques gestionados por el servicio de bomberos de la DFG Y levantar actuaciones de forma rápida.

Si la actuación es competencia del servicio, el operador de BAIESAN la levanta en primera instancia desde esta aplicación. Lo hace primero aquí debido a que la prioridad es avisar al parque para que salgan al lugar de la actuación lo antes posible.

El operador levanta la actuación indicando una serie de datos básicos:

1. El lugar del siniestro QTH (inicialmente no es exacto, puede variar durante el transcurso de la actuación).

2. El parque.

3. El tipo de actuación (fuego, rescate en medio rural o urbano, inundaciones, elurte, des-encarcelaciones…etcétera).

4. Se detalla una breve descripción de la actuación.

Finalmente el operador activa la alarma del parque y abre las puertas del mismo (la alarma tiene un color y sonido diferente, en función de la tipología de la actuación).

2.4 Aplicaciones Auxiliares: EUSKARRI. “Euskarri” es una aplicación del Gobierno Vasco que sirve como plataforma para la creación y difusión de información hacia las diferentes agencias de emergencias y seguridad, como son los servicios de bomberos de Gipuzkoa, S.O.S DEIAK y la ERTZAINTZA.

Esta aplicación se encuentra instalada en BAIESAN en 2 equipos (+ 1 Rooter) que pertenecen al departamento de Interior del Gobierno Vasco. Cualquier incidencia que tengan con los equipos, la aplicación o el Rooter es resuelta mediante el servicio ARRETA del propio Departamento de Interior del G.V.


Unitatea

Unidad:

Informatika

Informática

-

El servicio de bomberos de la DFG (BAIESAN) usa esta aplicación para poder tener conocimiento de las actuaciones que le competen (también recibe información relativa a ERREPIDE, Departamento de Infraestructuras Viarias de la DFG); que son levantadas en la mayoría de las ocasiones y en primera instancia por “SOS Deiak”. Conforme se va desarrollando la actuación, BAIESAN accede a Euskarri y actualiza la información que considera necesaria (parque principal que acude, si han llegado al lugar...si vuelven al parque...etc).Es una aplicación blindada, es decir, no comparte la información que puedan estar generando otras agencias en relación al mismo siniestro. Cuando se da por finalizada la actuación, BAIESAN realiza el cierre de la misma en Euskarri. A partir de ese momento Euskarri genera un resumen de la intervención tanto en formato PDF como en EXCEL y lo envía mediante email tanto al propio BAIESAN como a ERREPIDE. Si la intervención es de ERREPIDE, el asunto del email es marcado con una R para que en el Departamento de Infraestructuras Viarias de la DFG puedan discriminar las actuaciones que les pertenecen de las que no.

Cabe destacar que en la actualidad el Gobierno Vasco proporciona unas librerías para aplicaciones que quieran integrarse con Euskarri, sin necesidad de instalar la aplicación en ningún equipo ni configurar ningún rooter.

3 Objeto de expediente de contratación

El objetivo del presente pliego es la obtención de una solución informática que sustituya al bloque aplicaciones GIS (Salidas, EmerCAD, EmerGIS, y EmerWEB), por otra/s nueva/s manteniendo los requisitos (funcionales, integración,…) descritos en el pliego y garantizando el funcionamiento integral del sistema.

NOTA: A efectos de explicar los requisitos que tiene que cumplir la nueva solución informática nombraremos:

A la solución que sustituya a EmerCAD: Gestión de Emergencias

A la solución que sustituya a EmerGIS y EMERWEB: WebMapping de Emergencias y

A la solución que sustituya a Salidas: Salidas de Emergencias.

4 Requisitos

La solución informática demandada deberá satisfacer los siguientes requisitos técnicos tanto a nivel general como en cada una de las partes o aplicaciones que la componen.

4.1 Requisitos generales

● Rendimiento: que el sistema tenga la capacidad de gestionar eficientemente actuaciones de gran tamaño donde como mínimo se movilicen 5 parques, 60 bomberos y 25 vehículos, sin que se interrumpa ni bloquee la aplicación.


Unitatea

Unidad:

Informatika

Informática

-

● Seguridad: en principio se utilizará la aplicación corporativa de Accesos y Usuarios

desarrollada a estos efectos por IZFE, S.A., con tecnología Web, que garantiza tanto el control de accesos, la seguridad y el establecimiento de los diferentes perfiles de gestión de los datos en el sistema.

● Requisitos legales:

● Bilingüismo (Decreto Foral 4/2009).

La nueva aplicación o aplicaciones que se desarrollen irán íntegramente tanto en euskera como en castellano. En caso de que se decida utilizar alguna aplicación existente está también deberá ser bilingüe.

● Lenguaje inclusivo (Ley Orgánica 3/2007 Art. 28.4) no sexista,

En la aplicación se utilizará lenguaje no sexista.

● Usabilidad: cumplimiento de las normas WCAG (Web Content Accessibility Guidelines) del protocolo WAI (Web Accessibility Initiative), en al menos su nivel AA y parte de AAA. Estas normas tienen una vigencia mundial y están oficialmente reconocidas como estándar de Internet por la W3C (World Wide Web Consortium). De todas formas, al ser un sistema de aplicaciones de uso interno y conociendo las características de los equipos de los usuarios, se permitirá el uso de JavaScript.

● Soporte de la información: todos los datos estructurados deberán custodiarse en base de datos relacionales y/o espaciales. Los datos no estructurados estarán debidamente protegidos y deberán alojarse en repositorios adecuados dentro de la infraestructura de IZFE S.A.

El formato de documentos no tendrá ninguna limitación, podrán almacenarse en formato (PDF, DOC, DOCX, ODF, XLS, PPT…etc.)

● Criticidad: al tratarse de un sistema de gestión de emergencias, éste deberá estar activo las 24h del día, 365 días al año. En la solución propuesta se especificará un plan de contingencia.

● Concurrencia y escalabilidad: el sistema debe soportar concurrencia ilimitada de usuarios. Por otra parte tendrá que ser fácilmente escalable si es necesario.

Deberá permitir agregar nuevos repositorios de información, en cualquier momento, tanto estructurada como no estructurada.

● Sistema Redundante: se hace especial hincapié en que el nuevo GIS tiene que estar redundado. Las nuevas aplicaciones GIS deberán estar siempre operativas en BAIESAN, aunque sea de manera local. Cualquier incidencia de corte de servicio en CPDs, cortes de internet, NO pueden paralizar el sistema.

Arquitectura

● Tanto las aplicaciones como los datos deberán de estar alojados dentro de la infraestructura de IZFE

● Los estándares de respaldo serán los establecidos para toda la organización

● La oferta técnica, deberá incluir una propuesta detallada de la arquitectura que contemple soluciones de alta disponibilidad en todos sus componentes.

● La arquitectura final se consensuará entre el adjudicatario e IZFE en las reuniones de planificación y diseño del proyecto.


Unitatea

Unidad:

Informatika

Informática

-

B.D

● La BBDD en la que se desarrollará la solución propuesta será una de las siguientes y que son estándar en IZFE: DB2 for LUW, Oracle o SQL Server; debiendo ajustarse a la versión operativa en el momento. En cualquier caso, también será necesaria la integración de la solución con otros aplicativos actualmente en funcionamiento en IZFE y que alojan sus datos en SQL Server

Comunicaciones:

● TCP/IP ● JDBC

Servidor de aplicaciones

● Se usará alguno de los siguientes operativos en IZFE: IBM WebSphere Application Server for Linux, JBoss o Tomcat.

Compatibilidad con navegadores:

● Firefox. ● Internet Explorer ● Chrome

Sistemas operativos: según los estándares de IZFE

Licencias: todas las licencias de los productos que se utilicen para el desarrollo deberán estar incluidas en el precio. Siempre y cuando no estén disponibles y sin coste en la infraestructura de IZFE.

Entornos de desarrollo: los entornos de desarrollo en el cual estará desplegada la solución serán 2: el de preproducción y producción.

Formación : se contemplara en la oferta la formación necesaria a:

● los usuarios finales: para el correcto uso de la aplicación. ● Los técnicos de desarrollo de IZFE, en su caso. ● Los técnicos de sistemas de IZFE: para asegurar la operatividad y el pleno

rendimiento de la solución.

Documentación: la solución demandada deberán incluir sus respectivos manuales; manuales de instalación, manuales técnicos de diseño, manuales de administración y manuales de usuario.

4.2 Requisitos específicos de Gestión de Emergencias

● Interoperabilidad: la aplicación deberá ser capaz de integrarse con otras aplicaciones y bases de datos relacionales. El acceso a dichas bases de datos relacionales debe hacerse vía los estándares definidos en IZFE: servicios WEB, vistas, funciones y procedimientos almacenados, etc…

● Requisitos ofimática: los existentes en IZFE: debe tener compatibilidad con Microsoft Office (Word/Excel) y Open Office (Writer/Calc) para la exportación de datos.


Unitatea

Unidad:

Informatika

Informática

-

4.3 Requisitos específicos de WebMapping de Emergencias

Clientes de WebMapping: tecnología de base HTML5+ CSS3+ JavaScript + librerías/framework de propósito específico como OpenLayers o Leaflet.

4.4 Requisitos específicos de Salidas de Emergencias

Clientes de WebMapping: tecnología de base HTML5+ CSS3+ JavaScript + librerías/framework de propósito específico como OpenLayers o Leaflet.

5 Requisitos de integración con otras aplicaciones

5.1 Resumen de integraciones: necesarias y otras

● Necesarias: Gestión de Emergencias, necesariamente tendrá integración con otras aplicaciones existentes actualmente en el servicio de Bomberos de la D.F.G, para garantizar el funcionamiento integral del sistema:

1. Tendrá que mantener la integración con Bomberos Intervención: es la aplicación de gestión que ofrece los recursos del sistema (personas que están de turno, vehículos operativos y parques) al GIS actual y que necesariamente seguirá ofreciendo dichos recursos a la nueva aplicación Gestión de Emergencias (ver 5.2.1).

2. Tendrá que mantener integración con TELEMANDO: para importar desde la nueva aplicación de Gestión de Emergencias, información de la intervención creada en el TELEMANDO (ver 5.2.2).

● Otras integraciones para las cuales se pide propuesta:

1. Localización de recursos en tiempo real: poder integrar la localización de recursos (vehículos del servicio de bomberos) en tiempo real, en la nueva aplicación WebMapping de Emergencias (ver 5.3.1).

2. Gestión de Comunicaciones: poder integrar el envío automatizado de SMS en la nueva aplicación Gestión de Emergencias para pasar información de las intervenciones en marcha (ver 5.3.2).

3. Web de la DFG.: poder integrar información relativa a intervenciones en la web de la DFG: intervenciones on time, resumen de las intervenciones diarias (lugar+tipo de intervención+ recursos empleados)…etc. (ver 5.3.3).


Unitatea

Unidad:

Informatika

Informática

-

5.2 Integraciones necesarias

5.2.1 Bomberos Intervención

Descripción general de la aplicación:

Aplicación de gestión de recursos y actuaciones, dividida en 4 bloques principales:

● Gestión de Turnos: bloque donde se generan partiendo de la definición de calendarios,

los turnos de trabajo y de libranza de todo el personal del servicio (bomberos, cabos, sargentos, técnicos y personal de BAIESAN). Este proceso de generación tiene en cuenta cualquier incidencia que pueda afectar a la presencia de la persona al turno: cambios de turno y ausencias.

● Gestión de Actuaciones: bloque que visualizará información relativa a actuaciones que se crearán en la Aplicación de Gestión de Emergencias. Está información se usará para crear partes unificados de actuación o PUAS, e informes y certificados de intervenciones que luego serán expedidos a entidades privadas (casas de seguros, particulares) o públicas (Ertzaintza, Juzgados…etc.).

● Gestión de Horas: bloque donde se registran los excesos de horas generados por prolongaciones de jornadas o asistencias a cursos, sustituciones…etc. El servicio lleva un registro pormenorizado de la bolsa de horas de cada bombero.

● Gestión de Vehículos: bloque donde se gestionan todos los vehículos del servicio. Se dan de alta, de baja...se les dará presencia en la Aplicación de Gestión de Emergencias.


Unitatea

Unidad:

Informatika

Informática

-

Requisitos de la integración:

1. La Aplicación de Gestión de Emergencias permitirá necesariamente integración en tiempo real con la Aplicación Bomberos Intervención, para leer información de las dotaciones de los parques y los vehículos que están activos en el momento que se produce la intervención. También accederá a leer las denominaciones de los recursos ajenos a DFG, y los Servicios Colaboradores.

La integración se hará mediante vistas y funciones, definiéndolas en la B.D. de la Aplicación de Gestión de Emergencias. Es decir, la aplicación tendrá que acceder a datos de Bomberos Intervención, a lectura, para poder vincular recursos a sus servicios (personas, vehículos, parques). Las vistas y funciones que necesariamente deberá tener creadas en la B.D de la aplicación requerida, son:

● Vista Bomberos De Guardia: vista que lee los bomberos que están de guardia en el momento

que se produce la consulta. Esta vista tiene en cuenta las ausencias parciales; es decir, si en el momento de lanzarla hay alguien con ausencia parcial a turno, no la muestra.

● Vista Bomberos Localizables: vista que obtiene los bomberos que tienen localización en el momento que se produce la consulta. Esta vista tiene en cuenta las ausencias parciales; es decir, si en el momento de lanzarla hay alguien con ausencia parcial a localización no la muestra.

● Vista Turno Operadores: vista que obtiene los operadores de BAIESAN, los Sargentos (con turno guardia, de gestión o de gestión + localización), y los oficiales + suboficiales con localización, en el momento que se produce la consulta.

● Vista Turnos: vista que obtiene los turnos de presencia del calendario de BAIESAN, en el momento que se produce la consulta.

● Vista Vehículos Disponibles: vista que obtiene los vehículos operativos y visibilizados, en el momento que se produce la consulta. También se añaden a esta vista los vehículos y recursos de la DFG no pertenecientes al servicio de bomberos.

● Función Bomberos De Guardia: función que devuelve una tabla de resultados con los bomberos que están de guardia según la fecha y hora consultada. Esta vista tiene en cuenta las ausencias parciales; es decir, si en el momento consultado hay alguien con ausencia parcial a turno, no la muestra.

● Función Bomberos Localizables: función que devuelve una tabla de resultados con los bomberos que están de localización según la fecha y hora consultada. Esta vista tiene en cuenta las ausencias parciales; es decir, si en el momento consultado hay alguien con ausencia parcial a localización, no la muestra.

● Función Bomberos Resto: función que devuelve una tabla de resultados con los bomberos disponibles que NO están de guardia según la fecha y hora consultada.


Unitatea

Unidad:

Informatika

Informática

-

● Función Datos Vehículo: función que devuelve una tablas de resultados con los vehículos

operativos y visibilizados, según fecha y hora consultada.

Vista Recursos Externos Tipo Entidades: vista que obtiene la lista de todos los tipos de servicios colaboradores ajenos a DFG.

Vista Recursos Externos Entidades: vista que obtiene la lista de todas las entidades de servicios colaboradores ajenos a DFG

Vista Recursos Externos: vista que obtiene la lista de todos los servicios colaboradores ajenos a DFG, tanto los oficiales como los privados u otros servicios colaboradores.

2. La Aplicación de Gestión de Emergencias permitirá necesariamente integración en tiempo real con la Aplicación Bomberos Intervención, para escribir información de los recursos vinculados a cada intervención. Esto se hará necesariamente de esta manera para que Bomberos Intervención pueda realizar la Gestión de PUAs (Partes Unificados de Actuación) y la Gestión de Horas de Profesionales.

La integración se hará mediante procedimientos almacenados definidos en la B.D. de la Aplicación de Gestión de Emergencias. Es decir, cada vez que Gestión de Emergencias asigne un parque, persona o vehículo a una intervención, manipulará las siguientes tablas de Bomberos Intervención:

● AGENTES INTERVENCIÓN

● PERSONAS INTERVENCIÓN

● VEHÍCULOS INTERVENCIÓN

3. La Aplicación de Bomberos Intervención permitirá necesariamente integración en tiempo real con la Aplicación de Gestión de Emergencias, para leer datos de intervenciones, principalmente para poder crear PUAS y gestionar horas por intervención.

La integración se hace mediante vistas definidas en la B.D. de la Bomberos Intervención.

● INTERVENCIONES

● ESTADOS INTERVENCIONES

● ESTADOS INTERVENCIONES AGENTES

● ESTADOS INTERVENCIONES PERSONAS

● ESTADOS INTERVENCIONES VEHICULOS

● RECURSOS EXTERNOS INTERVENCIONES


Unitatea

Unidad:

Informatika

Informática

-

5.2.2 TELEMANDO

Descripción general de la aplicación:

TELEMANDO es una aplicación PLC cuya finalidad es controlar de forma remota diferentes instalaciones de los parques del servicio de bomberos de la D.F.G.

Si la intervención es competencia del servicio, el operador de BAIESAN la levanta en primera instancia desde esta aplicación. Lo hace primero aquí debido a que la prioridad es avisar al parque para que salgan al lugar de la actuación lo antes posible.

El operador levanta la actuación indicando una serie de datos básicos:

1. El lugar del siniestro QTH (inicialmente no es exacto, puede variar durante el transcurso de la actuación).

2. El parque. 3. El tipo de intervención (fuego, rescate en medio rural o urbano, inundaciones, elurte,

des-encarcelaciones…etcétera). 4. Se detalla una breve descripción de la actuación.

Finalmente el operador activa la alarma del parque y abre las puertas del mismo (la alarma tiene un color y sonido diferente, en función de la tipología de la actuación).

Requisitos de la integración:

1. La Aplicación de Gestión de Emergencias permitirá necesariamente integración en tiempo

real con la aplicación del TELEMANDO para importar información de la intervención desde ésta, dado que generalmente las intervenciones primero se levantarán en el TELEMANDO y luego se importarán desde la Aplicación de Gestión de Emergencias.

5.3 Otras integraciones a tener en cuenta

5.3.1 Localización de Recursos en Tiempo Real

- En la actualidad: o Podemos ver la ubicación de recursos únicamente en las aplicaciones

EUSKARRI y GureNet (Intranet G.V). Se localizan los recursos a través de la señal GPS de las emisoras TETRA o (futura) Red Digital DMR Foral, de vehículos y talkies.

o Otra posibilidad es ver la ubicación de las Tablet a través de la aplicación Google+.

- Se pide propuesta para integrar la localización de recursos en tiempo real e introducción de estados desde los propios vehículos.


Unitatea

Unidad:

Informatika

Informática

-

5.3.2 Gestión de Comunicaciones

- En la actualidad pasamos información de las intervenciones en marcha a través de un programa de envío de SMS, aplicación no integrada con EMERCAD. Se pide una propuesta para:

o Envío automático de SMS. o Envío automático de información a redes sociales (Twitter).

Poder twittear y publicar información de intervenciones del servicio de bomberos de Gipuzkoa en la cuenta que se les habilitará para tal efecto, de la misma manera que en otros servicios de bomberos (como por ejemplo el de Bizkaia): https://twitter.com/bomberosbilbao/status/885549883817689088?refsrc=email&s=11

5.3.3 Web de la DFG

- La futura web de bomberos de la DFG va a desarrollar un apartado específico para el servicio de bomberos de la DFG. Este nuevo apartado deberá integrar información relativa a intervenciones on time, resumen de las intervenciones diarias (lugar+tipo de intervención+ recursos empleados)…etc. Ejemplo de esta información lo podemos ver en la web de bomberos de Bizkaia

http://www.bizkaia.eus/home2/temas/detalletema.asp?tem_codigo=153&idioma=ca

http://www.bizkaia.eus/herri_administrazioa/suhiltzaileak/salidas.asp?idioma=Ca&Tem_Codigo=1880&dpto_biz=7&codpath_biz=7|153|1880

http://www.bizkaia.eus/herri_administrazioa/suhiltzaileak/ultsalidas.asp?idioma=ca&Tem_Codigo=1881&dpto_biz=7&codpath_biz=7|153|1881

6 Requisitos Funcionales del Sistema GIS de Emergencias

6.1 Resumen de las funcionalidades requeridas

El sistema deberá satisfacer las siguientes necesidades funcionales:

● Deberá implementar una Aplicación de Gestión de Emergencias que contenga los siguientes módulos:

1. Módulo Gestión de Intervenciones (ver 6.2.1)

2. Módulo Gestión de Tácticas Operativas (ver 6.2.2)

● Deberá implementar una Aplicación WebMapping de Emergencias que contenga el siguiente módulo:

1. Módulo Cartografía (ver 6.3.1).


Unitatea

Unidad:

Informatika

Informática

-

● Deberá implementar una Aplicación Salidas de Emergencias que contenga el siguiente

módulo:

1. Módulo Navegación (ver 6.4.1).

● Estas aplicaciones estarán integradas dentro del mismo sistema y se alimentarán la una a la otra; es decir, las intervenciones creadas vía alfanumérica en la parte de Gestión de Emergencias se podrán localizar y visualizar en la parte WebMapping de Emergencias y viceversa, intervenciones creadas sobre un punto concreto del mapa podrán ser visualizadas de manera alfanumérica en la parte de Gestión de Emergencias.

6.2 Aplicación Gestión de Emergencias

Será la aplicación que gestione de forma alfanumérica los datos relativos a intervenciones y recursos asignados a dichas intervenciones (personas, vehículos y parques movilizados).

6.2.1 Módulo de Gestión de Intervenciones

El módulo de Gestión de Intervenciones deberá permitir:

1. Dar de alta una intervención y modificar sus propiedades generales y los estados por los que pasan los recursos participantes en dicha intervención.

La intervención deberá contener las siguientes propiedades:

● Nro. Identificador de la intervención

● Fecha y hora del siniestro.

● Fecha y hora del conocimiento del siniestro.

● Fecha y hora de movilización de recursos.

● Nro. Ref. del 112: introducir el número de intervención correspondiente a EUSKARRI.

● Parque principal

● Tipo de intervención: tipificación de las intervenciones (fuego, rescate en medio rural o urbano, inundaciones, elurte, des-encarcelaciones…etcétera).

● Si es de intervención (Si/No)

● Estado de la intervención.

● Prioridad (alta, media, baja).

● Origen (SOS Deiak, Policía Autonómica Ertzaintza, Policía Municipal…etc.): identificar el origen del aviso.

● V.B(Si/No)

● Descripción libre del lugar (municipio, calle, centro…etc.)


Unitatea

Unidad:

Informatika

Informática

-

● Resumen de la intervención, en dos apartados:

o Resumen para el exterior.

o Observaciones internas (anotaciones internas de BAIESAN).

Cada vez que se documente algo (se hagan anotaciones sobre una intervención) se insertará en una tabla con fecha y hora. Esto facilitará las búsquedas y abrirá la oportunidad de incluir códigos al documentar una actuación. (La idea es poder algo similar a la funcionalidad de estados de vehículos, personas…etc.)

● Localización: edición de estos datos mediante una herramienta de búsqueda cartográfica (ver 6.3.1 punto 2).

o Coordenadas (latitud y longitud)

o Provincia y municipio.

o Localización manual: campo de libre escritura para búsquedas.

● Estados de la intervención: es el histórico de estados por los que va pasando la intervención. El sistema deberá permitir asignar estados a la intervención. Los posibles estados de una intervención, son:

o Nueva o Estado 3 – en camino. o Estado 4 – ha llegado al lugar de la intervención. o Controlado. o Recogiendo material. o Estado 1 – de regreso al parque. o Estado 2 – ha llegado al parque. o Pendiente de revisión.

● Recursos de la intervención:

● Agentes: son los agentes participantes de la actuación con su histórico de estados. El sistema deberá permitir la inserción de parques actuantes y de asignar los estados que les corresponda.

● Personas: son las personas participantes en una intervención con su histórico de estados. El sistema deberá permitir insertar personas que están de turno a fecha y hora de consulta, y de asignar los estados que les que correspondan. Los posibles estados de una persona, son:

o Estado 3 – en camino. o Estado 4 – ha llegado al lugar de la intervención. o Estado 1 – de regreso al parque.


Unitatea

Unidad:

Informatika

Informática

-

o Estado 2 – ha llegado al parque. o Ha sido movilizado/a. o Ha hecho acto de presencia. o En la actuación.

● Vehículos: son los vehículos participantes en una intervención con su

histórico de estados. El sistema deberá permitir insertar vehículos que están operativos a fecha y hora de consulta, y de asignar los estados que les correspondan. Los posibles estados de un vehículo, son:

o Estado 3 – en camino. o Estado 4 – ha llegado al lugar de la intervención. o Estado 1 – de regreso al parque. o Estado 2 – ha llegado al parque. o En la actuación.

● Recursos Externos: aparte de bomberos, permitirá introducir otros

recursos externos que han participado en la intervención: o Policía autonómica Ertzaintza o Policía municipal o Osakidetza o Cruz Roja o DYA o Otros organismos o Otros servicios de bomberos o Bomberos Voluntarios o Servicios Técnicos o SOS Deiak…etc.

● El sistema deberá permitir realizar una consulta rápida de intervenciones anteriores ocurridas en ese mismo lugar o en las cercanías (a x metros de distancia).

2. Implementar una pantalla de consulta de intervenciones que visualice la siguiente información :

● Intervenciones Vigentes. ● Intervenciones Finalizadas (con filtro de fechas para limitar el número de

intervenciones a mostrar). ● Recursos:

o Todos los Agentes o Todas las Personas o Todos los Vehículos

● Anotaciones.


Unitatea

Unidad:

Informatika

Informática

-

3. Asignar recursos a la intervención vigente en caliente arrastrándolos con el ratón, pudiendo

asignarlos en grupo, o también mediante comandos en la línea de comandos.

4. Implementar una ventana de comandos para la ejecutar las siguientes operaciones:

● Crear una nueva intervención.

● Vincular una agente a la intervención vigente.

● Vincular recursos (personas y vehículos) a la intervención vigente.

● Vincular los recursos según su estado de un parque a la intervención vigente.

● Cambiar el estado de la intervención vigente y de los recursos asociados a la misma (personas y vehículos).

● Insertar observaciones de carácter interno en la intervención vigente.

● Insertar observaciones de carácter externo en la intervención vigente.

● Modificar el campo referencia de la intervención vigente.

● Modificar el campo tipo de la intervención vigente.

● Mostrar todos los recursos de un parque.

● Actualizar todas las ventanas de la aplicación.

● Deseleccionar la fila de la intervención vigente.

● Seleccionar la fila de la intervención vigente.

● Limpiar la ventana de comandos.

● Salir de la ventana de comandos.

5. Actualizar el QTH (lugar del siniestro) y enviarlo a la nueva aplicación demandada de Salidas de Emergencias.

6. Clasificar las intervenciones según prioridad.

7. Recoger otras incidencias que han ocurrido durante el turno de trabajo de cada operador de

BAI ESAN.

8. Redactar informes detallados de la intervención o informes tipo listado, con numerosos filtros (por fecha, por parque, por tipo,…), incluyendo representación sobre mapa.

9. Integración con la aplicación Bomberos Intervención para saber en todo momento las

dotaciones de los parques (bomberos que están trabajando en ese momento, contemplando cambios, bajas, licencias,…) y los vehículos que están operativos (ver 5.2.1-punto 1).

10. Integración con la aplicación de Bomberos Intervención para ofrecerle información de cualquier

intervención (vigente o finalizada) de manera que ésta pueda generar sus Partes Unificados de Actuación y sus Registros de Horas por Intervención (ver 5.2.1 -punto 2).


Unitatea

Unidad:

Informatika

Informática

-

11. Integración con la WebMapping de Emergencias, para obtener información geográfica, ya que

cabe la posibilidad de importar las coordenadas de la intervención desde ahí. El objetivo de la integración será localizar el lugar del siniestro en base a diferentes posibilidades de búsqueda, accediendo a diferentes bases de datos geográficas. En base a esa localización, se recogerán las coordenadas del lugar.

12. Integración con la aplicación del TELEMANDO, para importar información de la intervención

desde la misma. Generalmente las intervenciones primero se levantarán en el TELEMANDO y luego se importarán desde Gestión de Emergencias (ver 5.2.2).

13. Integración con el programa de envío de SMS (ver 5.3.2).

14. Integración con la Web de la DFG (ver 5.3.3).

6.2.2 Módulo de Tácticas Operativas

El módulo de tácticas operativas se implementará necesariamente para generar una propuesta automatizada de asignación de recursos según el tipo y lugar de la intervención vigente. Para ello el sistema a desarrollar deberá implementar varias pantallas de mantenimiento de “Cuadros de Movilización de Recursos”, según las diferentes tácticas operativas del servicio de bomberos de la D.F.G.:

1. Pantalla Cuadro de Movilización de Parques (según ubicación): el cuadro de

movilizaciones definido servirá para obtener el orden de parques a movilizar según la ubicación de la intervención (hay que definir necesariamente una capa de zonificación de parques actuantes en la Aplicación WebMapping de Emergencias). Una vez localizado el lugar del siniestro en WebMapping de Emergencias, se indicará de manera adecuada el orden de parques a movilizar en ese punto, incluyendo los tiempos de llegada desde cada parque a ese punto.

2. Pantalla Cuadro de Movilización de Recursos (según el tipo de intervención y parque):

el cuadro de movilizaciones definido servirá para proponer los recursos que habría que movilizar, además de información relevante al tipo de intervención (información sobre TPC, protocolos especiales,…etc.), según el tipo de siniestro y el parque principal movilizado.


Unitatea

Unidad:

Informatika

Informática

-

6.3 Aplicación WebMapping de Emergencias

Será la aplicación que permitirá gestionar intervenciones sobre mapas.

6.3.1 Módulo de Cartografía

El módulo de Cartografía deberá permitir necesariamente:

1. Dar de alta una intervención y modificar sus propiedades generales y las del histórico de estados de recursos participantes en dicha intervención (necesariamente deberá tener integración con el Módulo de Gestión de Intervenciones de la Aplicación Gestión de Emergencias – ver 6.2.1 punto 1).

2. Realizar búsquedas geográficas mediante la implementación de una herramienta propia

de búsqueda cartográfica, cuya utilidad sea tanto modificar la localización de una intervención si la búsqueda es invocada de la Aplicación de Gestión de Emergencias, como para navegar y encontrar lugares en el mapa si la invocamos desde la propia Aplicación de WebMapping de Emergencias. La herramienta de búsqueda deberá permitir realizar tres tipos de búsquedas geográficas:

a. Por coordenadas, en diferentes formatos de latitud y longitud: en el sistema decimal, sexadecimal, TETRA y UTM 30 Norte…etc. El sistema deberá permitir conversión automática de coordenadas.

b. Personalizadas. Posibilidad de configurar búsquedas variadas. Es decir, posibilidad de realizar búsquedas por campos, configurados por el propio servicio de bomberos; por calles (municipio y nombre de la calle)…etc. Para agilizar el proceso, será necesario implementar búsquedas sobre campos con caracteres comodín (*). El uso de los comodines en un campo, se dará tanto de forma sencilla cómo múltiple (el sistema posibilitará hacer búsquedas de municipios que empiecen, por A*, por B*…etc.).

c. Sobre capas de Información Territorial, capas propias del servicio (hidrantes, edificios de Ermua, Aramaio,...etc).

3. Realizar consultas sencillas de intervenciones. Mostrar y filtrar intervenciones en el

mapa. Se podrán consultar las intervenciones según el estado de las mismas:

a. Consulta de intervenciones vigentes.

b. Consulta de intervenciones finalizadas, con filtro de fechas.


Unitatea

Unidad:

Informatika

Informática

-

La herramienta de consulta dará como resultado una lista de intervenciones. El usuario podrá seleccionar una de ellas y visualizar el punto sobre el mapa. Una vez seleccionada, el sistema le dará la opción de definir información tanto geográfica como alfanumérica complementaria: le permitirá definir una vista geográfica específica para esa intervención, su área de efecto, geoposicionamiento de vehículos y recursos externos que intervienen; a su vez, le permitirá añadir incidencias y observaciones relacionadas…etc.

4. Realizar consultas estadísticas de intervenciones (explotación estadística configurable de intervenciones) mediante la implementación de una herramienta de generación de mapas estadísticos donde se visualicen las zonas con mayor concentración de actuaciones. La herramienta de consulta permitirá filtrar por parques, tipos de actuaciones y fechas. Los mapas estadísticos generados dispondrán de diferentes opciones de visualización (estilo de representación, precisión…etc.) y podrán ser almacenados en la base de datos del sistema para su consulta posterior.

5. Implementar las herramientas habituales de cualquier sistema GIS: zoom +, zoom-, desplazamientos mediante el ratón arriba/abajo e izquierda/derecha, selección de áreas, cambio de escala, impresión del mapa, cambio a mapa de referencia b5m u otro…etc.

6. Trabajar con diferentes mapas: mapa de Gipuzkoa, de Europa, Errepide…etc.

7. Implementar un sistema de gestión de capas: a. Personalizándolo en un árbol de capas organizado por grupos:

▪ Que permita crear grupos de capas del sistema geográfico (capas de mediciones, de itinerarios, de búsquedas, de emergencias, de riesgos…etc.)

▪ Que permita crear grupos de capas con información propia (capas informativas, silos de silos de sal, webcams, agua…etc.)

▪ Posibilidad de confeccionar y mantener capas propias.

b. Personalizándolo en un árbol de capas favoritas: ▪ Para poder definir las capas más frecuentemente utilizadas.

c. Posibilidad de personalizar la visualización de todas las capas activándolas/desactivándolas.

d. Posibilitar la inclusión de ortofotos en capas sobre o bajo el resto de capas.

8. Vinculación con cartografía de terceros: que la aplicación permita abrir otras webs geográficas centradas según la vista del mapa que esté visualizándose en ese momento.

a. Vuelos 3D.


Unitatea

Unidad:

Informatika

Informática

-

b. Vinculación cartográfica interna:

i. GIS de Obras Hidráulicas. ii. Leyenda de Obras Hidráulicas. iii. Aforos de Obras Hidráulicas. iv. B5M v. Visor de carreteras.

c. Vinculación cartográfica externa: posibilidad de incorporar de manera ágil cartografía externa o poder utilizar diferentes mapas de fondo.

i. Google Maps. ii. Google Earth. iii. Bing Maps. iv. Yahoo Maps. v. Euskalmet. vi. Aemet.

9. Posibilidad de integrar información de diferentes orígenes y formatos (shp, bbdd,…)

10. Acceso a información vinculada (pdf, jpg,…). Mantener la información vinculada.

11. La realización, almacenamiento y consulta de:

a. Mediciones de distancias. b. Mediciones de superficies. c. Puntos.

Dichos objetos podrán ser nombrados para su posterior recuperación.

12. Configurar tooltips informativos: permitir dibujar y guardar incidencias y observaciones en el mapa, mediante la definición y asignación de nombres a puntos, líneas o áreas. Estos objetos (puntos, líneas, áreas) serán asignados a capas de incidencias que por defecto estarán siempre visibles. (Se podrán dejar invisibles desactivando la capa).

13. Configurar riesgos: dibujar y guardar riesgos (áreas) que serán asignados a capas de riesgos que por defecto estarán siempre invisibles.

14. Añadir la funcionalidad de edición de elementos y objetos geométricos.

La funcionalidad permitirá necesariamente la edición de:

2. Puntos situados en plano con datos e incluso archivos asociados. Estos puntos reflejarán capas de hidrantes, pivotes, bocas de riego, depósitos de agua…etc.

3. Líneas situadas en plano con datos y archivos asociados sobre longitudes, tensiones, anchos de pistas, acometidas…etc. Estas líneas reflejarán capas de pistas, calles peatonales, conducciones de gas y agua, líneas eléctricas...etc.

4. Áreas situadas en plano con datos y archivos asociados. Estas áreas reflejarán zonas quemadas de monte, cálculos de superficies, desalojos de población en proximidades de intervenciones…etc.


Unitatea

Unidad:

Informatika

Informática

-

6.4 Aplicación Salidas de Emergencias

6.4.1 Módulo de Navegación

Será la aplicación que facilitará el itinerario a los bomberos. Los principales objetivos de dicho módulo serán:

● Poder ver en cualquier dispositivo (tablets…etc.) la ubicación de los incidentes y poder

navegar hacia el incidente seleccionado.

● Poder optar entre diferentes itinerarios (Google Maps, OpenStreetMap o itinerarios personalizados); es decir, que a la hora de visualizar una ruta se puedan usar como mapa base Google Maps, OpenStreetMap…etc., y que dicha ruta se adapte a los cambios de sentido y cortes de circulación de las carreteras para que las dotaciones de bomberos, especialmente las dotaciones que se acercan desde parques secundarios y no conocen bien el lugar de la intervención, sepan por donde tienen que ir.

7 Contenido de la oferta técnica

Para facilitar el estudio de las ofertas técnicas, se presentaran en papel y en formato electrónico y en dos modalidades:

Las ofertas técnicas se presentarán en dos modalidades:

1. Oferta resumen ejecutivo, donde se recogerán los aspectos fundamentales de la oferta y sus elementos de valor añadido esenciales, conteniendo la información más relevante para la evaluación de la oferta según los criterios de adjudicación publicados. Este resumen ejecutivo no podrá superar el número de 25 páginas (25 páginas, A4 de una sola cara) 2. Oferta completa, si se considera conveniente, donde se podrá explicar y detallar los diferentes aspectos de la oferta, siempre que supongan una información directamente relacionada con los servicios propuestos en el pliego.

Ambas modalidades de ofertas se deberán ajustar al siguiente contenido y formato:

1. Introducción:

Se detallará el contexto en el que se realiza la proposición del licitador para entender y satisfacer los requerimientos de la presente licitación y el objeto del contrato.


Unitatea

Unidad:

Informatika

Informática

-

2. Descripción técnica de la solución propuesta:

Se reflejarán las características operativas y funcionales de la solución:

- Adecuación y cumplimiento de los requisitos generales, específicos, funcionales y de integración definidos en el pliego.

- La calidad de las prestaciones de la solución.

- La facilidad de manejo.

- Sus posibilidades de parametrización y flexibilidad.

- Seguridad de la solución.

- la simplicidad y economía en cuanto a la infraestructura hardware y software propuesta.

3. Gestión del proyecto:

- Plan de Trabajo.

Descripción del plan de trabajo detallado para desarrollar las tareas solicitadas, en el plazo de tiempo establecido y con la garantía de calidad requerida. Este plan de trabajo deberá detallar actividades y tareas, las fases e hitos, presentando su calendario de ejecución y diagrama de tiempo.

- Plan de formación.

- Control y seguimiento del proyecto.

Se describirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.

- Metodología y calidad.

Se describirá la Metodología seguida por el licitador para el desarrollo de proyectos de estas características.

4. Mejoras y prestaciones adicionales a las requeridas en el pliego:

Prestaciones adicionales funcionales, técnicas u operativas, no contempladas en el pliego y que supongan un incremento de valor añadido o mejora del modelo, de la aplicación o del sistema. Estas mejoras se entenderán, en todo caso, incluidas dentro del precio de licitación ofertado:

- Mejoras funcionales.

- Mejoras técnicas.

- Mejoras operativas.


Unitatea

Unidad:

Informatika

Informática

-

8 Información complementaria a aportar relativa a las condiciones del servicio de postventa y asistencia técnica de la solución

De forma accesoria, se anexarán a la oferta técnica, las condiciones del servicio postventa y de asistencia técnica de la solución.

Este servicio postventa de asistencia técnica comprenderá la línea de mantenimiento y evolución del sistema:

1. Línea de mantenimiento correctivo

Definido como aquel proceso orientado a la reparación de defectos existentes en un sistema software. Especialmente los críticos que impiden el funcionamiento operativo del servicio de bomberos.

Estos defectos pueden manifestarse de distintas formas:

· Cuando el programa falla o termina inesperadamente.

· Un programa produce un resultado que no es acorde con los requisitos.

2. Línea de mantenimiento preventivo/perfectivo.

Definido como el conjunto de acciones propuestas por el proveedor orientadas a la modificación de las aplicaciones con el fin de minimizar el mantenimiento correctivo y mejorar la calidad de las mismas.

3. Línea de mantenimiento adaptativo.

Definido las modificaciones que afectan a los entornos en los que el aplicativo opera, como, cambios de configuración de del hardware, software base, gestor de B.D., comunicaciones, etc.

4. Línea de evolución.

Son las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la evolución o cambio de las necesidades del usuario, es decir, la incorporación de nuevas funcionalidades a la cobertura actual del software.

Asimismo, se describirá:

o Horario del servicio de asistencia.

o Capacidad de que el proveedor pueda albergar la infraestructura en sus instalaciones y así, ser más eficiente en el mantenimiento.

o Tiempo de respuesta.

La documentación o datos relativos a la proposición económica de este servicio se incluirán en el sobre correspondiente a la oferta económica. No se incluirán en el sobre de la oferta técnica. Su presentación en otro sobre, conllevará el rechazo de la oferta presentada por la licitadora.


Unitatea

Unidad:

Informatika

Informática

-

9 Plazo de ejecución y entrega

Plazo máximo de ejecución será de 24 semanas desde la formalización del contrato.

10 Plazo de garantía

Plazo de garantía de un año a partir de la puesta en funcionamiento de la solución informática plenamente operativa.

11 Confidencialidad y seguridad

El adjudicatario se compromete a cumplir la siguiente normativa en cuanto a confidencialidad y seguridad.

11.1 Recursos humanos

El personal del adjudicatario, estará obligado a conocer y respetar las normas de confidencialidad que dicte IZFE.

El adjudicatario será responsable de que tanto los materiales, equipos instalados y maquinaria auxiliar, como el personal que haga uso de los mismos, cumplan con la normativa vigente en cuanto a Seguridad Laboral.

11.2 Sistemas

No se difundirá ni publicarán los sistemas de seguridad existentes o previstos.

No se revelará la información obtenida de los sistemas de información del IZFE, ni la documentación que se le suministre o la que pudiera tener acceso en el desempeño de sus funciones, con independencia del soporte en que se encuentre contenida.

Acceso exclusivo a la información necesaria para el desempeño de las funciones encomendadas. Se utilizarán exclusivamente las credenciales de autenticación a él asignadas y adquirirá el compromiso de actuar de forma cuidadosa para su custodia.

Los equipos conectados a la red de IZFE no podrán conectarse a ningún sistema informático o de telecomunicaciones público o privado ajeno, sin autorización expresa.

Utilizará adecuadamente y de forma cuidadosa los sistemas de seguridad implantados, de forma que se respeten y mantengan los máximos niveles de seguridad sin incurrir en ningún riesgo.


Unitatea

Unidad:

Informatika

Informática

-

11.3 Acceso y protección de datos El adjudicatario quedará expresamente obligado a mantener absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer con ocasión del cumplimiento del contrato, especialmente los de carácter personal, que no podrá copiar o utilizar con fin distinto al que figura en este Pliego de Prescripciones Técnicas, ni tampoco ceder a otros ni siquiera a efectos de conservación.

El adjudicatario quedará obligado al cumplimiento de lo dispuesto en el Reglamento de desarrollo de la LOPD, aprobado por Real Decreto 1720/2007, de 21 de Diciembre la Ley orgánica 15/1999 de 13 de diciembre, sobre protección de datos de carácter personal.

12 Procedimiento de consulta técnica

Durante el periodo de presentación de ofertas, el licitador podrá realizar las consultas en relación a este Pliego que estime necesarias de acuerdo al siguiente procedimiento:

El licitador enviará su consulta por correo electrónico con acuse de recibo a la

dirección de IZFE [email protected]

En el caso de que en su correo se incluya más de una consulta, estas estarán numeradas.

IZFE recibirá las consultas, codificará cada una de ellas y también su respuesta.

El tiempo estimado de respuesta será de 48-96 horas, aun cuando se tratará de minimizar este tiempo.

En caso de que este tiempo deba ser mayor por necesidad de escalado de la consulta, se informará al licitador indicando el tiempo de respuesta estimado.

Las consultas y respuestas realizadas, serán enviadas a los licitadores que hasta el momento de realizarse la consulta hayan mostrado su interés en el presente expediente.

Para el caso de licitadores que se incorporen al proceso en fecha posterior a una consulta, IZFE enviará todas las consultas y respuestas que se hayan realizado hasta ese momento.


Unitatea

Unidad:

Informatika

Informática

-

Criterios de adjudicación

Los criterios de adjudicación y la ponderación de los mismos, que se emplearán para la adjudicación del presente expediente de contratación, serán:

1. Precio de la oferta ........................................................................................................ 30

2. Calidad técnica de la solución presentada ................................................................ 53

3. Gestión del proyecto . .................................................................................................. 12

4. Mejoras y prestaciones adicionales ............................................................................. 5

170025 solución para la gestión integral de las ... · 2.4 aplicaciones auxiliares: euskarri. ......

Documents