contrato mixto (Servicios- Suministro) de “PLATAFORMA WEB DE DIFUSIÓN TURÍSTICA, APLICACIÓN MÓVIL TURISMO DE ALCÁZAR Y PANEL DE CAPTACIÓN DE DATOS TURÍSTICOS”

En este proyecto se indicaba la línea de actuación L24 (Plan de modernización tecnológica para la promoción y conservación del patrimonio) englobada en el Objetivo Temático 2 (OT2: Mejorar el acceso, el uso y la calidad de las tecnologías de la información y la comunicación), así como la linea de actuación L22 (Ordenación de la actividad turística) englobada en el Objetivo Temático 6 (OT6: Conservar y proteger el medio ambiente y promover la eficiencia de los recursos), con el objetivo de dotar x Xxxxxxx de San Xxxx de las herramientas necesarias para convertirse en un destino turístico inteligente (SMART DESTINATION).

El uso de la tecnología sirve para redefinir la organización y los procesos por los que se prestan servicios a las dos comunidades de ciudadanos (residentes y turistas) que forman parte de un destino turístico, transformándolo en un destino turístico inteligente. Gracias al empleo de las TIC en el desarrollo de las ciudades y territorios turísticos, se impulsa su transformación en destinos turísticos inteligentes y se mejora la sostenibilidad energética y medioambiental de la actividad turística de los mismos.

Los proyectos que se plantean dentro de esta Iniciativa, principalmente inciden en los seis ámbitos definidos por la Dirección General para políticas internas del Parlamento Europeo, así como un séptimo ámbito adicional:

0.Xxxxx Economy

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

0.Xxxxx Mobility 0.Xxxxx People 0.Xxxxx Living 0.Xxxxx Governance 0.Xxxxx Environment 0.Xxxxx Heritage

El desarrollo xx Xxxxxxx de San Xxxx como una ciudad inteligente se plantea como la herramienta que permitirá conseguir un objetivo estratégico como es la mejora del bienestar social y económico de los ciudadanos xx Xxxxxxx de San Xxxx. A partir del uso de las Tecnologías de la información y las Comunicaciones (TIC’s) basadas en la infraestructura digital y en servicios digitales, se construye una ciudad que se gestiona de forma más eficiente y sostenible en el uso de sus recursos, ofreciendo a sus ciudadanos mejores servicios.

El Ayuntamiento xx Xxxxxxx de San Xxxx quiere realizar una apuesta por la innovación y el uso de las nuevas tecnologías como elementos imprescindibles para alcanzar un nuevo modelo que permita la creación de oportunidades de generación de empleo y de actividad económica, y avanzar sobre la gestión inteligente de la ciudad.

Uno de los principales retos al que se enfrenta la Iniciativa Xxxxxxx Smart City es generar un modelo de Destino Turístico Inteligente adaptable a los destinos de la ciudad xx Xxxxxxx de San Xxxx, definir una estrategia y propuesta de actuaciones para la configuración de Destinos Turísticos Inteligentes y proponer tecnologías y métodos para el desarrollo turístico inteligente.

Los principales objetivos son aumentar los beneficios económicos y sociales derivados del sector turístico; consolidar el buen posicionamiento nacional e internacional xx Xxxxxxx de San Xxxx como ciudad con una identidad propia, con una completa y variada oferta de ocio, y como un destino de experiencias con un atractivo permanente;

mantener la posición competitiva de la ciudad xx Xxxxxxx de San Xxxx como destino con un producto multisegmento diferenciado, con una amplia oferta de productos turísticos: monumental y cultural, espacios naturales, salud, deportivo, de ocio, gastronomía; e incrementar la eficiencia en la gestión turística.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Para ello, entre otras actuaciones, se creará un sistema integral de gestión inteligente de servicios turísticos, que permita mostrar la oferta de manera integrada al turista teniendo en cuenta las nuevas demandas y necesidades del turista de la sociedad de la información; dentro de este sistema integral se desarrollarán una nueva web de turismo así como una aplicación móvil con posibilidades de nuevos formatos de contenido (interactivo, 360º, etc.). Adicionalmente, este sistema integral contará también con un panel de captación de datos turísticos, y en su conjunto se relacionará con la plataforma de Ciudad Inteligente xx Xxxxxxx de San Xxxx.

Este proyecto está cofinanciado por el Fondo Europeo de Desarrollo Regional (FEDER), en el marco de las ayudas para la realización de estrategias de desarrollo urbano sostenible integrado.

1.1. ÁMBITO DEL PROYECTO Y CONSIDERACIONES PREVIAS

En los siguientes apartados se detallan las características que debe cumplir el contrato objeto de adjudicación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Los requisitos enumerados en los siguientes apartados son de cumplimiento obligatorio. Las ofertas que ofrezcan características que no se ajusten a estos requisitos no serán tomadas en consideración en el presente procedimiento de licitación. Las múltiples referencias a protocolos, certificaciones o estándares que se indiquen a lo largo de este Pliego deberán entenderse acompañado de la mención “o equivalente”.

En este proyecto se contempla el suministro de una solución llave en mano que incluya todos aquellos aspectos necesarios para la puesta en funcionamiento de los diferentes componentes descritos en los siguientes apartados, que conforman una solución integral para el Ayuntamiento xx Xxxxxxx de San Xxxx.

Las actuaciones a abordar dentro del marco del Contrato, que incluirán el suministro e instalación de software y hardware, así como los servicios profesionales necesarios asociados al suministro e instalación, abarcan componentes interrelacionados que deberán integrarse proporcionando información tanto estratégica como operativa al Ayuntamiento xx Xxxxxxx de San Xxxx, con el fin de seguir avanzando en la mejora de los servicios que actualmente presta.

El eje estratégico Xxxxxxx Accesible tiene como objetivo la gestión inteligente del patrimonio cultural, de manera que se ponga en valor y sea accesible a través de las TIC, y se desarrolla en la línea estratégica Patrimonio digital y accesible del Plan Director:

Las actuaciones a realizar objeto del presente Pliego se han dividido en los componentes siguientes:

1. Plataforma Web de Difusión Turística.

2. Aplicación Móvil TurismoAlcázar.

3. Panel de Captación de Datos Turísticos.

Dichos componentes no han sido divididos en contratos diferenciados con el objetivo de que al tener el mismo adjudicatario se mejore la integración y sincronización entre los distintos componentes y se mejoren las sinergias existentes entre todos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El alcance pormenorizado del suministro y servicios objeto de este Pliego de Prescripciones Técnicas se encuentra descrito en los apartados que siguen en este documento.

Las características de los suministros y servicios objeto de este Pliego de Prescripciones Técnicas se consideran características mínimas, por lo que la oferta de cualquier otra configuración superior implica la aceptación de las condiciones y requisitos establecidos en este Pliego.

Estarán incluidos en la oferta todos los materiales que se consideren necesarios para la correcta implantación técnica y operativa, con la inclusión de todas las funcionalidades y prestaciones requeridas en este Pliego de Prescripciones Técnicas.

En caso de ser necesario, el alcance del suministro también incluye todos los elementos y dispositivos adicionales, los repuestos, cursos de formación, ayudas a la instalación y garantía de la instalación en estado operativo conforme al nivel de calidad y servicio especificado.

El alcance del servicio también incluye soporte técnico y garantía del estado operativo conforme al nivel de calidad y servicio especificado.

1.2. SITUACIÓN Y ENTORNO TECNOLÓGICO ACTUAL

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

A continuación, se describe la situación actual y los elementos del entorno tecnológico existentes en la ciudad xx Xxxxxxx de San Xxxx, con algún tipo de relevancia o impacto sobre los trabajos a desarrollar para cada uno de los componentes del presente Pliego.

1.2.1. INFRAESTRUCTURA

El Ayuntamiento dispone de servidores físicos (siendo los más modernos del modelo Lenovo ThinkSystem SR630) que se utilizan como VMware ESXi Hosts con el objeto de albergar maquinas virtuales. Estos servidores están conectados mediante switches de fibra óptica con una cabina de disco cuyo espacio de almacenamiento se está viendo agotado y que esta teniendo problemas de mantenimiento dada su obsolescencia.

1.2.2. SISTEMA DE AUTENTICACIÓN MUNICIPAL

Actualmente, el Ayuntamiento xx Xxxxxxx de San Xxxx dispone de un sistema de gestión de usuarios basado en el protocolo LDAP mediante el cual el usuario se autentica con nombre de usuario y clave a través del Directorio Activo de Microsoft Server 2019.

1.2.3. PÁGINAS WEB TURÍSTICAS

La información turística de la ciudad se presenta principalmente a través de la página web xxx.xxxxxxxxxxxxxx.xx, que ha ido creciendo y actualizándose periódicamente. Es una web que contiene completa información sobre la ciudad xx Xxxxxxx de San Xxxx como destino turístico incluyendo, entre otros, datos de monumentos, museos, alojamientos y restaurantes.

También se dispone de la web xxx.xxxxxxxxxxxxxxxxxxxxxxx.xxx que está relacionado con la web de turismo ya que el patrimonio cultural de la ciudad es también un recurso turístico a explotar.

1.2.4. SERVIDOR WEB DEDICADO

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El Ayuntamiento dispone en la actualidad de un servidor web dedicado externo con un Panel de Control Plesk para las webs que el Ayuntamiento decide mantener en una estructura on Cloud.

1.2.5. PLATAFORMA DE CIUDAD INTELIGENTE

El Ayuntamiento xx Xxxxxxx de San Xxxx cuenta con una plataforma de Ciudad Inteligente basada en Fiware y que cumple la norma UNE 178104:2017, que va a permitir la captura y gestión integral de información heterogénea procedente de los Servicios Municipales, los sensores desplegados y otras plataformas, su transformación en elementos inteligentes de información o indicadores de servicio y su puesta a disposición, si procede, a través de servicios avanzados a:

• La Administración, para el control de la gestión y la toma de decisiones.

• La ciudadanía, para la mejora de su calidad vida.

• Los prestadores de servicios urbanos, para la mejora de los servicios urbanos.

• El sector local TIC, para la promoción de la innovación, la cooperación y el desarrollo de nuevos negocios en la región.

Los componentes software objeto de este Pliego deberán ser interoperables con esta plataforma que servirá de soporte en materia de Business Inteligence a la toma de decisiones en ámbito turístico-cultural.

1.2.6. PORTAL DE DATOS ABIERTOS

El Ayuntamiento xx Xxxxxxx de San Xxxx cuenta con un portal de datos abiertos que permite la publicación de los datos que el Ayuntamiento y sus organismos autónomos consideren “abiertos” y facilita el acceso y la reutilización de los datos por terceros (ciudadanos y empresas).

Los componentes software objeto de este Pliego deberán ser interoperables con este portal con el objeto de publicar los datos abiertos de carácter turístico-cultural que se estimen oportunos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

1.3. ENTORNO TECNOLÓGICO FUTURO

1.3.1. SISTEMA DE INFORMACIÓN GEOGRÁFICA

El sistema de información geográfica corporativo municipal (SIG) actualmente existente en el Ayuntamiento xx Xxxxxxx de San Xxxx está basado en la arquitectura de AL LocalGIS 2. Como parte de la Iniciativa Xxxxxxx Smart City, al estar completamente obsoleto y por ello, en desuso, en un futuro cercano se renovará dicho sistema de información geográfica migrándose la información actual al nuevo sistema.

El futuro sistema dispondrá de servicios WMS (Web Map Services), servicios WFS (Web Feature Services) y de una API REST para el acceso directo a objetos almacenados en la geodatabase municipal. Esto permitirá la integración con aplicaciones que requieran funcionalidades geoespaciales.

Los componentes software objeto de este Pliego deberán ser interoperables con el nuevo SIG para garantizar una localización exacta desde la nueva web y app dentro del SIG.

2. REQUISITOS COMUNES

2.1. REQUISITOS GENERALES

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Todas las actuaciones desarrolladas en el marco del presente expediente de licitación deberán cumplir los siguientes requisitos generales:

• Se especifican los requisitos mínimos que deberán cumplir los equipos ofertados, si bien los mismos podrán ser mejorados por los licitadores.

• Las propuestas que ofrezcan características inferiores a las especificaciones técnicas mínimas requeridas no serán tomadas en consideración en el presente procedimiento.

• Los trabajos a desarrollar por el adjudicatario se consideran “llave en mano”, por lo que este deberá suministrar todos los elementos hardware, software, accesorios y materiales que sean necesarios, así como el personal técnico adecuado.

• El adjudicatario suministrará todas las herramientas, aparatos, equipos de medida, material de seguridad, así como el personal técnico adecuado con la preparación y experiencia necesarias, para llevar a cabo las tareas requeridas para la ejecución del Contrato.

• Todos los entregables, soluciones y demás elementos que formen parte del presente Xxxxxx, deberán estar alineados con la identidad visual de la iniciativa.

• Los componentes que se implanten deberán estar disponibles 24 horas al día durante 365 días al año.

2.2. REQUISITOS DE HARDWARE

Salvo indicación expresa del Ayuntamiento xx Xxxxxxx de San Xxxx, y siempre que no provoque incompatibilidad con la situación xx xxxxxxx tecnológica del Ayuntamiento xx Xxxxxxx de San Xxxx, el hardware suministrado por el adjudicatario en los distintos

componentes de la iniciativa deberá incorporar la última versión de microcódigo, firmware

o software publicada por el fabricante.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Todos los elementos a suministrar por el adjudicatario como parte de la ejecución de este contrato, incluidos sus componentes y elementos de conexionado, deberán ser necesariamente nuevos, no admitiéndose equipos usados, ni total o parcialmente reparados o reconstruidos.

Todos los elementos suministrados de un mismo tipo serán del mismo fabricante.

Aquellos elementos hardware a instalar en exteriores, o en interiores en los que las condiciones existentes requieran de una protección ante el polvo y el agua, deberán contar con las protecciones IP y para el entorno en el que deben operar, teniendo en cuenta las condiciones especiales de la ubicación en la que se instalen.

Aquellos elementos hardware a suministrar en el proyecto, y que cuenten con capacidad de gestión remota, deberán contar también con capacidad de acceso a través de puerto local, garantizando las labores de mantenimiento, actualización de firmware, etc., en caso de fallo de comunicación que imposibilite el acceso remoto.

A fecha de publicación del presente pliego, todos los elementos a suministrar por el adjudicatario como parte de la ejecución de este contrato no tendrán fecha anunciada de finalización del ciclo de vida ( End Of Life) del fabricante o bien se cumplirá uno de los siguientes supuestos:

• Estará anunciada y será superior a 5 años a partir de la fecha de publicación del presente pliego.

• Estará anunciada y será inferior a 5 años a partir de la fecha de publicación xxx xxxxxx, en cuyo caso, el adjudicatario deberá haber reemplazado esos equipos antes de dicho final de vida, por otros de iguales o superiores características con fecha de final de vida posterior a 5 años a partir de la fecha de publicación xxx xxxxxx. En tal caso, el adjudicatario llevará a cabo todas las tareas necesarias para garantizar la continuidad del servicio y asumirá todos los costes de instalación y configuración.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

En el caso de que sea necesario un cambio en los modelos de los equipos o en alguno de sus componentes, por actualización tecnológica, obsolescencia del equipamiento, descatalogación, etc., el adjudicatario deberá notificar con una antelación mínima de un (1) mes al Ayuntamiento xx Xxxxxxx de San Xxxx este cambio, para poder evaluar el impacto en el proyecto en ejecución y ser homologado según el procedimiento establecido por el Ayuntamiento xx Xxxxxxx de San Xxxx.

El adjudicatario se compromete a ofrecer equipos con las mismas características técnicas o superiores a los equipos inicialmente ofertados en el presente procedimiento de contratación.

Como norma general, el número de serie del equipamiento suministrado deberá ser visible en alguna superficie del mismo sin que sea necesaria su desinstalación.

La alimentación de todo elemento suministrado deberá cumplir lo dispuesto en el vigente Reglamento Electrotécnico para Baja Tensión, RD 842/2002 (en adelante REBT) y sus instrucciones técnicas complementarias, con las normas particulares vigentes de la empresa suministradora de energía aprobadas por el Ministerio para la Transición Ecológica y Reto Demográfico y el Plan General de Ordenación Urbana del Ayuntamiento xx Xxxxxxx de San Xxxx junto con sus correspondientes Ordenanzas Municipales.

El cableado de red de datos, en el caso de ser necesario, se realizará con cable UTP CAT6 o Clase E, o con fibra OM3/OM4, según las normas TIA/EIA-568-B e ISO/IEC 11801 2ª edición, o equivalentes.

Las instalaciones de cableado estructurado de telecomunicaciones (cobre, coaxial, fibra óptica, etc.) utilizados en las infraestructuras comunes de telecomunicaciones en el interior de las edificaciones, deberá cumplir con lo enunciado en la norma UNE-EN 50575:2015 (o equivalente) y Adenda 1 (UNE-EN 50575:2015 /A1:2016) (o equivalente) y su correspondiente actualización según se indica en la directiva ECE/983/2019 de 26 de Septiembre, por la que se regulan las características de reacción al fuego de los cables de telecomunicaciones en el interior de las edificaciones y se modifican determinados anexos del Reglamento regulador de las infraestructuras comunes de telecomunicaciones para el acceso a los servicios de telecomunicación en el interior de las edificaciones.

2.3. REQUISITOS DE SOFTWARE

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Todo software puesto a disposición en el marco del presente procedimiento de licitación y cualquiera de los componentes software expresamente enumerados en el presente Pliego de prescripciones técnicas deberá cumplir los requerimientos expuestos en el presente apartado.

Los componentes y desarrollos destinados a funcionar sobre explorador soportarán los navegadores más extendidos en el mercado en sus dos últimas versiones en el momento de la entrega de los desarrollos, siempre que estén soportados por el fabricante, así como en los navegadores y versiones existentes en las infraestructuras del Ayuntamiento xx Xxxxxxx de San Xxxx a la fecha de la implantación.

Para aquellas soluciones software que se instalen en las infraestructuras del Ayuntamiento xx Xxxxxxx de San Xxxx:

• El adjudicatario garantizará su funcionamiento sobre equipos cliente con los sistemas operativos implantados en el Ayuntamiento xx Xxxxxxx de San Xxxx.

• El adjudicatario implantará dichas soluciones en el hardware que indique el Ayuntamiento xx Xxxxxxx de San Xxxx, sin necesidad de conectividad con recursos o sistemas instalados en la nube, salvo solicitud debidamente justificada por el adjudicatario, y aceptación explícita del Ayuntamiento xx Xxxxxxx de San Xxxx.

Todo el software deberá tener capacidad para desplegarse tanto On Premises como

On Cloud, en función de las necesidades del Ayuntamiento xx Xxxxxxx de San Xxxx.

Las soluciones software propuestas deberán basarse en estándares y serán de fácil mantenimiento y amplia presencia en el mercado, con el objeto de maximizar la interoperabilidad y las posibilidades de integración.

Los servicios que incorpore el software se deben ofrecer bajo tecnología de servidor de aplicaciones.

Deberá haber compatibilidad entre todo el software que forma parte de la solución descrita en el presente Pliego, con los sistemas operativos implantados en el

Ayuntamiento xx Xxxxxxx de San Xxxx, con las plataformas de bases de datos y servidor de aplicaciones, así como con el resto del aplicaciones y servicios que integran el resto de componentes descritos en el presente Pliego.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Las funcionalidades solicitadas en los diferentes componentes objeto de la licitación y que se describen en los siguientes apartados de este Pliego deberán estar operativas en el momento de la entrega, pudiéndose comprobar su correcto funcionamiento.

Todos los interfaces de usuario deberán proporcionarse en castellano. Los interfaces de usuario tendrán la capacidad de visualizar, almacenar y gestionar contenido en varios idiomas.

Cualquier solución software debe permitir acceso concurrente desde varios dispositivos al mismo tiempo.

En el desarrollo de aplicaciones accesibles desde un navegador, el adjudicatario deberá tener en cuenta principios de desarrollo que optimicen el tiempo de carga, tales como optimizar imágenes y otros elementos de las páginas, utilizar algoritmos de compresión sin pérdida para reducir el número de bytes enviados a través de la red, evitar redirecciones de páginas, o utilizar herramientas de optimización de la memoria caché, siempre y cuando no interfieran en el buen funcionamiento del portal web.

En cuanto al licenciamiento y accesibilidad, preferentemente el software deberá ser puesto a disposición a través de una licencia que permita su utilización por parte de cualquier Administración española en el ejercicio de sus funciones. Dicha licencia cumplirá las siguientes condiciones:

• Que permita su cesión a favor de cualquier Administración pública española para el ejercicio de sus funciones, para todo el mundo y por el plazo máximo permitido legalmente.

• Que la cesión incluya los derechos de reproducción y transformación a favor de cualquier Administración pública española.

En el caso de que el software utilizado sea software privativo, el adjudicatario otorgará una licencia que permita el acceso al citado software por parte del Ayuntamiento xx

Xxxxxxx de San Xxxx en el ejercicio de sus funciones por el mayor plazo permitido legalmente y para todo el mundo.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El número de licencias incluidas como parte del alcance deberá ser suficientes para las necesidades el Ayuntamiento xx Xxxxxxx de San Xxxx, siendo responsabilidad del adjudicatario dimensionar el número de las mismas para cada elemento software, cada usuario que deba hacer uso de la misma, con los permisos establecidos en cada uno de los roles que se defina en los elementos software afectados.

En el caso de que el licitador oferte soluciones ya existentes basadas en software xx xxxxxxx abiertas, la solución ofertada debe basarse en un software estable, robusto, ampliamente utilizado y con un gran respaldo por una comunidad de usuarios y desarrolladores que garantice su evolución y viabilidad futuras.

El software deberá seguir la legislación vigente, así como las recomendaciones internacionales y estándares de usabilidad y accesibilidad:

• Deberá alcanzar, al menos, un Nivel de Conformidad "AA" (Doble A).

• Tanto las páginas web como las aplicaciones para dispositivos móviles deberán cumplir el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público y el estándar UNE-EN 301549:2019 Requisitos de accesibilidad de productos y servicios de las TIC o equivalente.

2.3.1. REQUISITOS DE NUEVOS DESARROLLOS SOFTWARE

Los nuevos desarrollos software deberán, salvo justificación aceptada por el Ayuntamiento xx Xxxxxxx de San Xxxx, hacer uso de lenguajes de desarrollo estándar, de fácil mantenimiento, ampliamente distribuido y multiplataforma, evitando el uso de desarrollos específicos siempre que sea posible.

Cualquier pieza de código se entregará siguiendo los estándares de calidad y documentación adecuados.

El adjudicatario deberá entregar un listado de todos los módulos/componentes utilizados especificando el origen del módulo, la autoría del mismo y el código de licencia.

El adjudicatario especificará la relación entre los componentes del sistema y el tipo de relación (compilación, ejecución, etc.).

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La sencillez de manejo del entorno deberá ser uno de los principales pilares en el diseño y construcción de las soluciones software destinadas a funcionar sobre explorador. La organización de la información, así como la interfaz gráfica que la compone deberá ser intuitiva y eficaz a la hora de gestionar la información que contenga.

Las aplicaciones deberán ser accesibles vía Internet desde los principales navegadores estándar.

Las aplicaciones deberán ser capaces de adaptarse de manera óptima al tamaño y formato de pantalla del dispositivo del usuario, bien sea de escritorio o móvil.

Las aplicaciones móviles deberán estar disponibles al menos para las dos últimas versiones de los dos sistemas operativos móviles más utilizados (Android e iOS).

2.3.2. REQUISITOS DE NUEVAS INTEGRACIONES

Para la integración de los nuevos componentes software con aplicaciones y servicios ya existentes, el Ayuntamiento xx Xxxxxxx de San Xxxx proporcionará las APIs, web services o conexiones a las bases de datos, los cuales se acompañarán de la información suficiente (descripción xx xxxxxx, documentación de soporte etc.). En caso de que el Ayuntamiento xx Xxxxxxx de San Xxxx no pueda proveer estas conexiones, el adjudicatario realizará en los sistemas que oferta las actuaciones necesarias (desarrollo de web services genéricos, información detallada para la futura integración, etc.) de modo que el Ayuntamiento xx Xxxxxxx de San Xxxx, junto con los proveedores de las soluciones ya implantadas, puedan eventualmente realizar las integraciones con los sistemas objeto de la licitación. No será responsabilidad del adjudicatario realizar actuaciones o modificaciones sobre las soluciones ya implantadas que no sean objeto de esta actuación, excepto que estas actuaciones se indiquen de forma expresa en el Pliego y el

Ayuntamiento xx Xxxxxxx de San Xxxx ponga a disposición la documentación técnica y el código de la aplicación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario desarrollará las integraciones propuestas sobre las APIs y Servicios Web que proporcionen los aplicativos y el acceso a las bases de datos disponibles. No obstante, en caso de que por requerimientos especiales del servicio (por ejemplo, por necesidad de procesamiento en tiempo real) sea conveniente otras soluciones de integración, el adjudicatario realizará un informe sobre la solución tecnológica propuesta y requerirá una aceptación previa por el Ayuntamiento xx Xxxxxxx de San Xxxx para su desarrollo e implantación.

Previo al desarrollo de cualquier integración, el adjudicatario realizará un análisis funcional y técnico detallado del proceso, considerándose esta documentación y su aprobación por parte del Ayuntamiento xx Xxxxxxx de San Xxxx requisito previo para comenzar los trabajos de integración.

2.3.3. REQUISITOS RELATIVOS AL DESARROLLO SEGURO

Para garantizar la seguridad de los desarrollos, el adjudicatario utilizará un Ciclo de Desarrollo de Software Seguro (Secure Development Life Cycle o S-SDLC) o procedimiento similar, incorporando la seguridad como un proceso transversal durante todo el proceso de desarrollo.

Respecto a las validaciones de entrada, el adjudicatario tendrá en cuenta las siguientes prácticas:

• Toda entrada al sistema debe considerarse como maliciosa.

• La validación de datos de entrada debe realizarse en un entorno fiable, normalmente el backend.

• Siempre que sea posible la validación deberá centralizarse en un punto de la aplicación.

• Se validarán rangos y longitudes xx xxxxxx.

• Se validará que los campos concuerdan con lo esperado (cabeceras HTTP con caracteres exclusivamente en ASCII, si se espera un fichero en un formato debe ser ese el formato, etc.).

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Se realizarán controles especiales para caracteres o cadenas que se consideren peligrosos (<, >, %, /, etc.), evitándose su presencia si no son necesarios.

Respecto a las validaciones de salida, el adjudicatario tendrá en cuenta las siguientes prácticas.

• La codificación de datos de salida debe realizarse en un entorno fiable, normalmente el backend.

• De estar disponible se utilizarán librerías y métodos de codificación ampliamente testados y aceptados por la comunidad (p. ej. URL Encoder de Android).

• Los datos de salida serán codificados en base al uso que hará de ellos la aplicación (evitando por ejemplo datos interpretables en HTML para un navegador web o posibles modificaciones a comandos SQL).

Respecto a la autenticación, el adjudicatario seguirá las siguientes prácticas:

• Exceptuando las páginas públicas, el resto requerirán autenticación para ser accedidas.

• Los controles de autenticación se realizarán en un sistema fiable, normalmente el

backend.

• Los controles de autenticación estarán centrados en un único módulo para una aplicación.

• La lógica de la autenticación estará separada de la lógica del recurso al que se accede.

• Las peticiones de autenticación se realizarán a través de conexiones HTTP (post) cifradas convenientemente.

• La validación de los datos de autenticación se debe llevar a cabo cuando todos los datos necesarios hayan sido introducidos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Todas las contraseñas se deben guardar debidamente cifradas a través de una función criptográfica segura, nunca en claro.

• Se deben establecer requisitos mínimos de seguridad para las contraseñas.

• Si se generan contraseñas por defecto deben ser cambiadas en el primer acceso.

• Se desactivarán las cuentas tras un número de intentos fallidos durante un periodo de tiempo para evitar ataques de fuerza bruta.

• Se evitará la utilización de preguntas de seguridad para recuperar contraseñas, de ser necesario se evitarán preguntas cuya respuesta pueda averiguarse con un esfuerzo razonable (p. ej. ¿Cuál era tu colegio?).

• Se enviarán solicitudes de restablecimiento de contraseña exclusivamente a correos electrónicos registrados.

• De ser posible se establecerá un doble factor de autenticación.

Respecto a la gestión de sesiones de usuario se seguirán las siguientes prácticas de seguridad.

• De estar disponible para el control de sesiones se utilizará el control de sesiones que incorpore el framework en el que se desarrolla la aplicación.

• Las sesiones expirarán tras un periodo definido de inactividad.

• Los identificadores de sesión se crearán en un entorno confiable, normalmente el

backend.

• Se evitará exponer la información sobre la sesión a terceros.

Respecto a la gestión de errores, el adjudicatario seguirá las siguientes prácticas de seguridad:

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Ante la aparición de un error se debe evitar revelar información sensible como detalles del sistema, identificadores de sesión o información sobre cuentas.

• La aplicación debería gestionar todos los errores y no depender nunca de los errores por defecto del sistema.

• Ante la aparición de un error, la política por defecto de cara a la tarea que se está realizando debe ser la denegación.

• Los logs deben registrar los sucesos relevantes en el sistema.

o Fallos en la validación de entrada.

o Intentos de autenticación fallidos.

o Intentos de conexión con sesiones expiradas.

o Cambios en la configuración de elementos críticos.

o Excepciones en el sistema y otros errores ocurridos durante la ejecución.

El adjudicatario evitará en todo caso almacenar credenciales en el código fuente de la aplicación o en archivos de configuración.

Los recursos accesibles a través de conexiones seguras no estarán accesibles a través de conexiones que no lo son.

Respecto a los accesos a base de datos se seguirán las siguientes prácticas:

• Los accesos a base de datos se realizarán siempre a través de consultas parametrizadas.

• Los parámetros deben pasar un proceso de codificación y validación.

• Respecto a los accesos se seguirá el criterio del “menor privilegio posible” para acceder a los datos.

• Los roles con distintos niveles de acceso accederán a través de distintos usuarios, cada uno con sus privilegios.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• La conexión con base de datos se mantendrá el tiempo necesario para la ejecución de las tareas.

El adjudicatario realizará una buena gestión de la memoria para evitar vulnerabilidades críticas relacionadas con esta gestión (desbordamiento de buffer, etc.)

El adjudicatario realizará las tareas relacionadas con el sistema operativo a través de las APIs ofrecidas por el mismo.

Todas las variables y fuentes de datos deben ser inicializadas antes de su primer uso.

En caso de que el código permita actualizaciones, el adjudicatario verificará que éste proviene xx xxxxxxx confiables.

2.4. REQUISITOS DE COMUNICACIONES

Todos los sistemas a implantar se integrarán con la red del Ayuntamiento xx Xxxxxxx de San Xxxx, no admitiéndose soluciones de comunicaciones que no permitan esta integración.

El Ayuntamiento xx Xxxxxxx de San Xxxx proporcionará la conectividad necesaria, así como la información técnica que permita la integración con su red.

El adjudicatario deberá habilitar los elementos adecuados para minimizar el coste de las comunicaciones y detectar posibles errores que provoquen envíos continuos de datos no necesarios.

No se admitirán soluciones de comunicación que impliquen gastos recurrentes de distinta tipología a los que asume el Ayuntamiento xx Xxxxxxx de San Xxxx dentro de su contrato de comunicaciones en el momento de la ejecución en el que se requiera.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

2.5. REQUISITOS DE COMPATIBILIDAD

La solución ofertada debe garantizar la total compatibilidad entre todos los elementos así como la compatibilidad con la infraestructura existente en el Ayuntamiento xx Xxxxxxx de San Xxxx.

Los elementos ofertados por el adjudicatario deberán ser totalmente compatibles e integrables con los elementos existentes en el Ayuntamiento xx Xxxxxxx de San Xxxx, descritos en el apartado 1.2 Situación y Entorno Tecnológico Actual, sin requerir para ello ningún equipamiento, software, licencia o prestación que no sea aportada por el adjudicatario; en su defecto, el adjudicatario incluirá en su oferta la sustitución de cualquier elemento incompatible por otro equivalente hasta eliminar cualquier incompatibilidad, de manera que las características, capacidades y funcionalidades hardware y software de la infraestructura resultante sean iguales o superiores a las existentes en la actualidad, sin que esto suponga un aumento de la necesidad de recursos (espacio, suministro eléctrico, etc.).

Toda integración, cambio o sustitución que resulten necesarios, derivados de la no compatibilidad de los sistemas ofertados con los existentes en el Ayuntamiento xx Xxxxxxx de San Xxxx serán responsabilidad del adjudicatario, quien deberá realizar todas las tareas oportunas para conseguir el correcto funcionamiento del entorno final requerido, sin pérdida de la continuidad del servicio que se presta, y sin perjuicio de los plazos establecidos en el apartado 7. Plazos.

El adjudicatario garantizará la compatibilidad de todo componente implantado y software desarrollado, en caso de actualización de versión de los elementos de la arquitectura base que integre la solución.

2.6. REQUISITOS DE SEGURIDAD

2.6.1. REQUISITOS BÁSICOS DE SEGURIDAD

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario deberá cumplir con lo establecido en el Esquema Nacional de Seguridad (ENS), de acuerdo con el Real Decreto 951/2015, de 23 de octubre, de modificación del Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica. De esta forma, la solución aportada por el adjudicatario deberá respetar los principios básicos y requisitos mínimos recogidos en dicha reglamentación a fin de garantizar una adecuada protección de la información.

El adjudicatario deberá definir e implementar la correspondiente securización para todos los componentes y funcionalidades objeto del presente Pliego. Estas políticas de seguridad de cada uno de los componentes deberán quedar recogidas como entregables del proyecto en un documento específico. Este entregable se referenciará como POLÍTICAS DE SEGURIDAD. El documento se actualizará en función de la implementación del proyecto hasta la entrega final, en la cual recogerá las políticas de seguridad implementadas para cada componente. El plazo de la entrega final estará sujeto al plazo descrito en el apartado 7. Plazos.

La arquitectura de seguridad definirá el hardware, software, protocolos y políticas para crear el entorno sobre el que los componentes objeto del presente Pliego funcionen de forma fiable, segura y con alta calidad. Ésta deberá cubrir al menos:

• Autenticación y autorización.

• Seguridad en las comunicaciones y securización de todos los elementos desplegados en los diferentes componentes, en especial la capa de sensorización.

• Monitorización e integridad del sistema.

• Registro de logs centralizado.

• Backup, restoring y duplicado de datos.

La implantación de los diferentes componentes deberá contemplar la correspondiente batería de pruebas de seguridad.

Las políticas de seguridad que se establezcan deberán girar sobre los ejes de confidencialidad, integridad, autenticidad, trazabilidad y disponibilidad:

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Confidencialidad: en cuanto a revelación a personas no autorizadas o que no necesitan conocer la información.

• Integridad: en función de las consecuencias que tendría su modificación por alguien que no está autorizado a modificar la información.

• Autenticidad: en función de las consecuencias que tendría el hecho de que la información que gestionan o contienen no fuera auténtica.

• Trazabilidad: en función de las consecuencias que tendría el no poder rastrear a posteriori quién ha accedido o modificado una cierta información.

• Disponibilidad: en función de las consecuencias que tendría el que una persona autorizada no pudiera acceder a la información cuando la necesita.

2.6.2. GESTIÓN DE USUARIOS Y AUTENTICACIÓN

La gestión de usuarios y roles de acceso de cada componente se realizará de forma centralizada a través del módulo de Gestión de Usuarios de la Plataforma. Se valorará que la solución aportada se integre con la solución de gestión de usuarios actualmente disponible en el Ayuntamiento xx Xxxxxxx de San Xxxx y que se indica en la situación xx xxxxxxx descrita en el apartado Sistema de Autenticación Municipal.

El adjudicatario garantizará que la autenticación en los distintos sistemas desplegados en los componentes sea unificada, instalando o desarrollando para ello los módulos software e integraciones que sean necesarios.

El sistema de autenticación deberá permitir el registro de usuarios en la plataforma, así como que éstos ejerzan su derecho a la eliminación de la cuenta de usuario y el borrado de toda la información de carácter personal que hayan facilitado.

Permitirá operaciones de alta, baja y modificación de usuarios, autenticación de usuarios y consulta de datos de usuarios.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El sistema de autenticación podrá tener configurado un conjunto de roles por defecto con permisos definidos en base a las necesidades de estos usuarios, permitirá la asignación de nuevos permisos a los roles existentes.

El sistema permitirá definir, crear y borrar una estructura de roles/permisos de forma que el usuario pueda autenticarse y tenga acceso a las funcionalidades en las que tenga permiso en base a su perfil.

2.6.3. REGISTRO DE LOGS CENTRALIZADO

La solución presentada por el adjudicatario almacenará los logs de todos los elementos de forma centralizada para el tratamiento por el sistema de monitorización de los eventos registrados. De este modo, los diferentes elementos de las soluciones que conformen cada componente deberán generar logs de cara al control de la seguridad.

Durante la ejecución del presente contrato, el adjudicatario determinará en colaboración con el Ayuntamiento xx Xxxxxxx de San Xxxx el procedimiento más adecuado de gestión de los logs, en cuanto a su almacenamiento, periodo de almacenamiento, eliminación, etc.

De cara a mantener la uniformidad, siempre que sea posible, los relojes de todos los componentes dentro del ámbito del presente expediente se deberán sincronizar con una fuente que proporcione la hora exacta acordada, para asegurar que el sello de fecha/hora refleje la fecha/hora real.

2.6.4. MONITORIZACIÓN E INTEGRIDAD DEL SISTEMA

La solución presentada por el adjudicatario implementará un sistema de monitorización que facilite la consulta del estado de la seguridad y de la información relacionada con los eventos de seguridad.

El sistema de monitorización permitirá la monitorización de los componentes hardware y software desplegados, inspeccionando los logs de los mismos que puedan indicar que el sistema está en riesgo.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El sistema de monitorización deberá tener la capacidad de realizar una monitorización y control de las actividades realizadas por los usuarios, a partir de registros de auditoría, generando informes de actividad y auditorías de las actividades de cada usuario, grupos de usuarios y a nivel estadístico, con diferentes niveles de detalle, en función de la información almacenada en los registros.

Todas estas consultas relativas a la monitorización deben poder realizarse a través de una interfaz que sea amigable y fácilmente utilizable por el Ayuntamiento xx Xxxxxxx de San Xxxx.

Los registros de auditoría deberán incluir toda la información relevante relacionada con las políticas de seguridad, como por ejemplo:

• Identificadores.

• Fechas, horas y detalles de eventos claves.

• Registros de intentos de acceso fallidos y rechazados al sistema, bases de datos y otros recursos.

• Cambios en la configuración del sistema.

• Uso de privilegios.

• Uso de las utilidades y aplicaciones del sistema.

• Alarmas, alertas y mensajes de los dispositivos y sistemas en relación con el acceso.

Cuando los registros de auditoría contengan datos de carácter personal se mantendrán las medidas de protección de privacidad apropiadas de acuerdo a lo establecido en la legislación vigente de protección de datos de datos de carácter personal.

Los administradores del sistema no deberán tener permiso para borrar o desactivar los registros de auditoría de sus propias actividades.

3. REQUISITOS ESPECÍFICOS

3.1. COMPONENTE 1: PLATAFORMA WEB DE DIFUSIÓN TURÍSTICA.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

3.1.1. DESCRIPCIÓN GENERAL

El objetivo del Ayuntamiento xx Xxxxxxx de San Xxxx es posicionarse como un Destino Turístico Inteligente (DTI) de referencia a través de herramientas tecnológicas de última generación, desarrollando una plataforma de difusión modular (en adelante, “la Plataforma”) y altamente escalable, tanto en su propia estructura como en la integración de nuevos canales.

Gracias al alto grado de visibilidad que se puede alcanzar a través de Internet, el aumento de los procesos de información, reserva y adquisición de servicios turísticos a través de este medio ha sido notable en los últimos años. La mayor información a disposición de los usuarios los ha transformado en “visitantes informados” y sobre todo, en elementos de difusión activa para otros usuarios. El DTI debe adaptarse a esta nueva situación turística.

Se plantea el desarrollo de una plataforma tecnológica capaz de aglutinar todas las acciones enfocadas al turismo desde el Ayuntamiento y desde el sector empresarial turístico, incluyendo:

• Mantenimiento de la información turística de forma centralizada mediante un gestor de contenidos.

• Difusión turística a través de un portal web que incorpore numerosas funcionalidades.

• Segmentar los recursos y productos en función de determinados parámetros que sirvan para personalizar la oferta de cara a los usuarios y obtener datos valiosos de sus consultas para mejorar la estrategia de promoción.

• Poder analizar la información turística de visitas, consultas, búsquedas, etc.

• Establecer la base tecnológica para otros desarrollos que permitan al Ayuntamiento xx Xxxxxxx de San Xxxx disponer de un auténtico Centro de Turismo Inteligente.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El Manual de Destinos Turísticos Inteligentes elaborado por Thinktur, recomienda la concepción de los Centros de Turismo Inteligente basada en las siguientes premisas de desarrollo:

• Adhesión a estándares: Utilizar siempre estándares para cualquier aplicación, evitando el uso de soluciones privativas que pueden resultar más onerosas. El uso de estándares facilitará las aportaciones de terceras partes gracias a la interoperabilidad y, en especial, las aportaciones privadas locales.

• Uso de plataformas abiertas (Open Source): El uso de sistemas abiertos, tanto de software como de hardware, facilita enormemente la evolución de las tecnologías y, junto a estándares, la suma de esfuerzos en determinada dirección.

• Sensibilización y educación digital local: Los miembros de la comunidad local deben estar concienciados y debidamente formados, cada uno en su ámbito de actuación, para poder incorporarse efectivamente a las dinámicas de un destino inteligente. Se deberán dar a conocer las posibilidades y facilitar servicios.

Además de estas tres premisas fundamentales, otros factores importantes a tener en cuenta en el desarrollo de plataformas tecnológicas enfocadas a turismo son la escalabilidad (permitir crecer y evolucionar el sistema), la modularidad (implementación por módulos funcionales), y la segmentación de la información por perfiles, intereses, etc.

El desarrollo del nuevo Portal Web de Turismo deberá realizarse sobre un sistema de gestión de contenidos, basado mayoritariamente en componente sujetos a licenciamiento “open source”, que ponga el foco en la difusión de contenidos digitales de última generación, vídeos 360, panoramas, recorridos virtuales, audios… Algunas características que deberá tener esta nueva plataforma web son:

• Capacidad de adaptación. Sobre todo a nuevas tipologías de contenidos que puedan surgir en el futuro, archivos de rutas en kml o tracks, contenidos 360, reproducciones 3D, etc.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Obtención de información de uso. Conocer qué consultan los visitantes, dónde hay que hacer un esfuerzo en promoción, cómo mejorar el portal…

• Segmentación de la oferta. Es importante ofrecer una oferta adecuada a cada tipo de viajero y que estos entiendan que la oferta es personalizada para ellos.

• Integración con funcionalidades existentes. Deberá idearse para adaptarse a los modos de gestión de determinados módulos de Turismo y del propio Ayuntamiento xx Xxxxxxx, como puede ser la agenda de eventos, o las noticias y publicaciones de redes sociales. Permitirá bien mantener el sistema existente o en caso de que así se decida, su sustitución.

• Interoperabilidad. Debe dar servicio a otras soluciones tecnológicas que se plantean como acciones diferentes, pero integradas con la Plataforma de Difusión Turística, como apps, cartelería digital, señalización turística, gamificación…

• Integración con Plataforma de Ciudad Inteligente. La plataforma Web de difusión Turística será interoperable mediante API Rest con la Plataforma de Ciudad Inteligente para el control de los datos y la información procedente de la nueva Plataforma de Turismo, datos analíticos de uso, datos de empresas participantes, datos de productos consultados, etc. El adjudicatario deberá desarrollar una vertical de turismo específico para la importación y el manejo de dichos datos en la Plataforma de Ciudad Inteligente.

La acción deberá comprender al menos las siguientes tareas:

• Análisis, diseño y definición de la Plataforma.

• Recopilación e inventariado de la información turística básica de recursos y empresas.

• Desarrollo del modelo de datos, sistema de gestión de contenidos y permisos de usuario.

• Carga de la información básica turística de los recursos y empresas xx Xxxxxxx.

• Desarrollo del Portal Web de difusión turística y cultural.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Implantación en el entorno del Ayuntamiento xx Xxxxxxx de San Xxxx.

• Integración con la Plataforma de Ciudad Inteligente mediante realización de API Rest en la Plataforma Web de Difusión Turística y desarrollo de vertical de Turismo (incluyendo panel del cuadro de mando e informes) en la Plataforma de Ciudad Inteligente.

• Formación al personal técnico del Ayuntamiento xx Xxxxxxx de San Xxxx.

El Centro de Turismo Inteligente cuenta como principales objetivos:

• La mejora de la percepción del destino por parte del visitante.

• La mejora de la productividad de las empresas del sector.

• Mejoras en la calidad de vida para los residentes.

• Ahorro en los costes de gestión y mejora en la calidad de los recursos, productos y servicios turísticos.

• Mayor control de la información sobre los recursos turísticos y adaptación a la demanda xxx xxxxxxx.

3.1.2. CARACTERÍSTICAS GENERALES

La instalación del entorno de producción de la Plataforma se realizará, en términos generales, On Premises en la infraestructura del Ayuntamiento xx Xxxxxxx de San Xxxx habilitada para tal efecto en el desarrollo del presente pliego; adicionalmente, el entorno de preproducción de la Plataforma se instalará por parte del adjudicatario en modo On

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Cloud en el servidor web dedicado definido en el apartado 1.2.4. En caso de ser necesario debido a la arquitectura de la solución, y previa aceptación por parte del Ayuntamiento xx Xxxxxxx de San Xxxx, la solución podrá tener elementos concretos desplegados en entornos cloud de terceros, en cuyo caso, el acceso a dichos entornos será suministrado por el adjudicatario sin coste alguno adicional para el Ayuntamiento durante el periodo de garantía de la solución contratada.

La Plataforma deberá ser fácilmente instalable y diseñada para su implementación en un entorno de alta disponibilidad. La Plataforma será modular, es decir, con capacidad de ir ampliando elementos y extendiendo funcionalidades mediante la instalación de nuevos módulos.

La Plataforma será robusta y tolerante a fallos, para ello contará con los mecanismos necesarios para hacer frente a incidencias continuando en funcionamiento (a nivel funcional y de carga/rendimiento/desempeño), aplicando el procedimiento adecuado de recuperación y tratamiento de errores, y generando los correspondientes registros y alarmas de la indisponibilidad temporal del sistema.

La Plataforma contará con mecanismos que aseguren la confidencialidad, integridad y fiabilidad de la información almacenada, utilizando mecanismos de autenticación y cifrado que sean reconocidos en el mercado.

La identidad visual de la Plataforma deberá ser homogénea y la gestión de usuarios será única y centralizada para toda la solución.

3.1.3. GESTOR DE CONTENIDOS

El núcleo operativo de la plataforma estará compuesto por un gestor de contenidos que servirá como repositorio de los contenidos que se utilicen en el Portal Web de difusión turística, la aplicación móvil Turismo Xxxxxxx, así como en otros canales de visualización de contenidos existentes y/o futuros (totems, marquesinas, pantalla de visualización, etc) en el Ayuntamiento xx Xxxxxxx de San Xxxx.

El componente constará de todo el software necesario para la operatividad de la solución y para su integración con el resto de componentes.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos actuará como back office unificado para el resto de los componentes con contenidos, soportando la integración con otros repositorios y aplicaciones a través de la capa de interoperabilidad, y permitiendo que el Ayuntamiento xx Xxxxxxx de San Xxxx pueda disponer de contenido turístico actualizado de forma automática y centralizada, garantizando que los contenidos publicados en cada origen estén disponibles a través de los distintos componentes que presentan contenidos al ciudadano y turista.

Las funcionalidades software indicadas en el presente componente podrán estar implementadas indistintamente en un único sistema (panel) de gestión unificado o en varios integrados entre sí, siempre y cuando se dé cumplimiento a todos los requisitos. La puesta en producción de este componente se plantea como una solución llave en mano, que debe incluir:

• Implantación y puesta en producción del gestor de contenidos.

• Migración de los contenidos ya existentes en el Ayuntamiento xx Xxxxxxx de San Xxxx.

El gestor de contenidos permitirá la redifusión y redistribución de contenido web relativo a los recursos disponibles en la Plataforma y aplicaciones externas si existieran.

El gestor de contenidos permitirá la gestión eficiente de los contenidos ofreciendo un sistema de administración, creación y mantenimiento de los mismos, que permitirá como mínimo:

• Gestión de la información de los contenidos turísticos y culturales y cualquier otro tipo de información disponible en la Plataforma Web de Difusión Turística, portales web turístico/culturales y otros canales del Ayuntamiento xx Xxxxxxx de San Xxxx.

• Inserción, edición y modificación de los contenidos a través de formularios y plantillas, con el menor grado de complejidad posible, permitiendo la publicación de contenidos personalizables, accesibles desde diferentes dispositivos (portal web,

aplicaciones móviles, etc.). Se valorará la posibilidad de integración con pantallas interactivas.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Posibilidad de integración con otros repositorios de datos, tanto internos como externos al gestor, facilitando el acceso a la información (por ejemplo, gestión y uso de los contenidos relacionados con puntos de interés como pueden ser municipios, negocios, activos turísticos, etc.). Dichos repositorios de datos podrán tener diferentes formatos y provenir de distintas fuentes: el gestor de contenidos actual, herramientas de CRM, documentos de texto, hojas de cálculo, archivos fotográficos, archivos de vídeo, etc. En particular, deberá estar preparado para integrarse con los repositorios de datos especificados en el Ayuntamiento xx Xxxxxxx de San Xxxx.

• Gestión de usuarios, roles y perfiles de acceso a los contenidos.

El gestor de contenidos permitirá la creación de contenidos mediante editores WYSIWYG (What You See Is What You Get).

El gestor de contenidos verificará que el formato de los contenidos a gestionar es adecuado para su visualización en web, teniendo en cuenta formato, tamaño, etc.

El gestor de contenidos pondrá a disposición, al menos las siguientes herramientas y funcionalidades, que se desarrollan a continuación:

• Gestión de contenidos: puntos de interés turístico, experiencias, etc.

• Directorio de empresas de interés turístico (restauración, hospedaje, actividades turísticas, etc.)

• Integración con motores de búsqueda.

• Geolocalización en mapas.

• Agenda de eventos.

• Social.

• Semántica, tags y palabras clave para los contenidos.

• Rutas turísticas

• Cuadernos de viajes

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos estará basado en software modular, escalable y altamente configurable que permita la gestión de contenidos como artículos, imágenes, archivos y otros contenidos, además de ofrecer servicios añadidos como foros, encuestas, votaciones, blogs, etc.

El gestor de contenidos permitirá organizar la información de forma jerárquica mapeando los niveles de organización que el Ayuntamiento xx Xxxxxxx de San Xxxx determine, ya sea por temas o colecciones, a través de la creación xx xxxxxx de las clases de activos digitales definidas, árboles de categorías y metadatos automáticos.

El acceso al gestor de contenidos web estará protegido mediante usuario y contraseña.

El gestor de contenidos utilizará estándares tecnológicos que permitan separar los datos del aspecto con el que se muestran, permitiendo mostrar contenidos con diseños distintos y en distintos formatos para una misma información creando tan solo diferentes plantillas.

El gestor de contenidos estará diseñado para soportar la carga de peticiones que realicen tanto usuarios internos, como externos.

El gestor de contenidos dispondrá de servicios web y API REST que garanticen el servicio a las aplicaciones ya disponibles en el Ayuntamiento xx Xxxxxxx de San Xxxx y la integración con otros componentes.

El gestor de contenidos dispondrá de capacidad para soportar diferentes modos de acceso a los datos incluyendo modo Push (suscripción y notificación), modo Pull (petición y respuesta) y consultas georreferenciadas, facilitando la integración de los contenidos con los buscadores más usados en internet.

El gestor de contenidos incorporará herramientas de importación y exportación de datos en los formatos estandarizados como CSV, XLS, JSON, etc.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos dispondrá de capacidad para integrarse con herramientas de mensajería y de email marketing que se integre con el repositorio de usuarios de la Plataforma, permitiendo enviar leads a las diferentes listas dentro de la plataforma de email marketing para que desde ésta se pueda realizar por ejemplo el envío de correos electrónicos a grupos de usuarios, generación de newsletters, etc..

El gestor de contenidos dispondrá de un interfaz de administración que permita la gestión integral de los contenidos y usuarios, basado en tecnología web, con diseño responsive que permita su utilización en ordenadores y dispositivos móviles (se valorará la no necesitad de uso de ratón en estos dispositivos), accesible desde los principales navegadores estándar en sus dos últimas versiones disponibles durante la ejecución xxx Xxxxxx.

El gestor de contenidos proveerá de elementos que soporten protección contra los principales tipos de vulnerabilidades más frecuentes en el desarrollo web.

El gestor de contenidos proveerá de un acceso seguro al contenido, requiriendo usuario y contraseña según lo establecido en el apartado 2.6. Requisitos de Seguridad del presente Pliego, permitiendo su integración con los sistemas y mecanismos de autenticación disponibles.

El gestor de contenidos dispondrá de roles predefinidos, permitir la creación de nuevos roles y permitir heredar roles de los usuarios generales de la Plataforma, con objeto de administrar los privilegios de acceso y gestión de contenidos, por ejemplo, que puedan definirse usuarios específicos de sólo acceso a contenidos, usuarios públicos y privados, usuarios administradores y desarrollo, etc.

Como mínimo se definirán los siguientes roles, sin menoscabo de poder definir otros:

• Superusuario: tendrá control sobre toda la información y recursos dentro del BackOffice. Dispondrá de permisos de administración sobre los elementos del BackOffice.

• Oficinas de Turismo: podrán visualizar todo tipo de contenidos que le sean propios.

• Gestores: podrán gestionar todo tipo de contenidos y recursos turísticos y culturales.

El gestor de contenidos generará alarmas de aviso cuando se suban nuevos contenidos que deban ser supervisados por el rol Superusuario.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos dispondrá de un módulo de auditoría que registre todas las operaciones realizadas por los usuarios del gestor de contenidos con un período de vigencia o almacenamiento de la información según lo estipulado en el Esquema Nacional de Seguridad (ENS).

El gestor de contenidos permitirá dar estimación de número y tipología de los contenidos.

El gestor de contenidos ofrecerá información de la navegación de los usuarios de los distintos soportes, orientada a poder realizar informes, como mínimo sobre las categorías más vistas y rutas de navegación usadas.

El gestor de contenidos permitirá la categorización de archivos, tanto de manera manual como automática.

El sistema dispondrá de facilidades para la carga masiva de archivos mediante procesos batch o por lotes.

El gestor de contenidos tendrá la capacidad de guardar un histórico de la actualización de componentes activos digitales, con la posibilidad de acceso al valor del fichero. Al actualizar el fichero asociado a un componente activo digital se creará un histórico con la información asociada al fichero. La herramienta deberá poder diferenciar cada archivo versionado, manteniendo el nombre del objeto seguida de una numeración incremental.

El gestor de contenidos deberá permitir múltiples posibilidades como inserción a través de web, carga de contenidos FTP, carpetas locales y carpetas activas.

El gestor de contenidos proporcionará las herramientas necesarias para la gestión de contenidos (edición, publicación, etc.), contemplando al menos las siguientes funciones, que se desarrollan a continuación:

• Organización de la información: Permitirá la organización de los contenidos de acuerdo con taxonomías, categorías y subcategorías, contemplando un orden jerárquico, ampliamente modificable, tanto en sus atributos como en su orden dentro de la jerarquía.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Tipología de la información: Dispondrá de capacidad para utilizar diferentes modelos de datos y ampliar con tipos de contenidos diferentes, permitiendo una alineación con modelos de datos estandarizados como, por ejemplo:

o Dispositivos/sensores.

o Alarmas/avisos.

o Eventos/ofertas.

o Indicadores.

o Puntos de interés (PDI), en inglés Points Of Interest (POI).

o Artículos, documentación.

o Mapas.

o Plataformas de ciudad.

o Estructuras de navegación.

El gestor de contenidos dispondrá de capacidad para gestionar diferente información asociada a un recurso turístico y cultural, ofreciendo como mínimo y a modo de referencia la siguiente información:

• Descripción del recurso.

• Contenido de geolocalización.

• Capas de recursos cercanos.

• Código QR de acceso directo.

• Contenido multimedia:

o Fotos.

o Vídeos propios o integración con repositorios externos (como YouTube, Vimeo, etc.).

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

o Audioguías, video guías.

o Imágenes panorámicas, 3D, y contenido de realidad aumentada.

o Deberá disponer de capacidades de streaming de vídeo y audio para los formatos más extendidos.

o Deberá tener capacidad de almacenar información en múltiples formatos. Como mínimo se deben considerar: documentos escaneados y gráficos vectoriales.

• Contenido Web 2.1:

o Valoraciones positivas.

o Comentarios anidados con moderación.

o Compartir en redes sociales.

o Añadir a favoritos.

El gestor de contenidos permitirá la gestión multiidioma del contenido, permitiendo seleccionar el tipo de contenido que lo soporta, permitiendo la incorporación de contenido traducido y permitiendo agregar, gestionar y proveer contenidos en varios idiomas.

El gestor de contenidos permitirá la maquetación y diseño del contenido. Dispondrá de elementos predefinidos que permitan un diseño básico (como por ejemplo plantillas) y permitirá la construcción de un diseño personalizado.

El gestor de contenidos permitirá la gestión de la estructura de navegación de los distintos canales, entre otras la gestión de la página inicial, definición de secciones, etc. Como mínimo permitirá la gestión de las siguientes funcionalidades y secciones, sin menoscabo de poder definir otras:

• Carrusel de imágenes de cabecera.

• Carrusel de banners.

• Transición de imágenes mediante “scroll”.

• Secciones/cabeceras de contenidos dinámicos.

• Perfiles de Facebook y Twitter configurables.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Zona de contenidos destacados.

• Lista de enlaces destacados.

• Buzón de sugerencias.

• Organización de las secciones en portadas, páginas, menús, cabeceras, pie de página, plantillas predefinidas, etc.

El gestor de contenidos permitirá la gestión de comentarios asignados a contenidos, permitiendo distintos tipos de gestión (por ejemplo, comentarios libres, moderados, etc.), así como la gestión de permisos de autorización o denegación de comentarios a recursos.

El gestor de contenidos permitirá la integración de la información meteorológica disponible en la Plataforma, con el objeto de proveer al menos la siguiente información, sin perjuicio de poder mostrar otra:

• Información meteorológica de la ubicación donde se encuentre el usuario o de una ubicación que pueda buscar el usuario, adaptada a las especificidades del canal.

• Información en tiempo real de radares de lluvia, facilitada por terceros (AEMET o similar).

• Información de predicciones meteorológicas disponibles y facilitadas por terceros (AEMET o similar).

El gestor de contenidos permitirá la gestión de la información de accesibilidad asociada a los recursos turísticos disponible en la Plataforma, con el objeto de proveer al menos, la información de los criterios de accesibilidad.

El gestor de contenidos permitirá la gestión de Recursos Turísticos y Culturales, contemplando al menos las siguientes funcionalidades, que se desarrollan a continuación:

• Gestión de Catálogo de Recursos Turísticos y Culturales.

• Gestión de las Secciones Turísticas y Culturales.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Respecto a la gestión del Catálogo de Recursos Turísticos y Culturales, cada recurso podrá estar compuesto de los siguientes elementos de información gestionables y publicables, que servirán además para su catalogación y como filtro de las búsquedas:

• Tipo de recurso. A modo de referencia se propone los siguientes: restauración, alojamiento, espacios naturales, actos culturales, conciertos, obras teatrales, actividades deportivas, etc. El Ayuntamiento xx Xxxxxxx de San Xxxx facilitará en tiempo de ejecución la información de los recursos turísticos y culturales.

• Cada tipo podrá tener una tipología propia de segundo nivel, por ejemplo: restaurantes, cafeterías, etc. en el caso de restauración y hoteles, albergues, campings, etc. en el caso de alojamientos.

• Los atributos podrán ser propios de cada tipo, permitiendo fijar criterios asociados al recurso como por ejemplo accesibilidad y calidad, o bien criterios de clasificación (por ejemplo, la categoría en estrellas de un hotel o número de tenedores de un restaurante). En cualquier caso, tipologías y conjunto de atributos deberán ser administrables.

• Geolocalización e información geográfica para mostrar en la herramienta de visualización de mapas.

• Contenido multimedia asociado al recurso.

• Contenidos relacionados, consistentes en enlaces a contenidos de otras webs que resulten de interés para el visitante del recurso turístico.

• Contenidos de los usuarios (Contenido web 2.1):

o Valoraciones (dentro de una escala predefinida, que sirva posteriormente como filtro en los buscadores).

o Comentarios (posibilidad de moderación por parte del administrador del portal).

o Funciones de compartición en redes sociales ya indicadas en los requisitos generales del gestor de contenidos.

• Información descriptiva del recurso, como por ejemplo denominación, descripción del recurso o información de contacto (teléfono, email, Facebook, Twitter, etc.).

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Desde cada recurso se podrá tener acceso a la visualización de una ficha detallada del mismo. Esta ficha contendrá al menos la siguiente información:

o Información ampliada del recurso.

o Mapa de localización de recurso.

o Elementos asociados y/o relacionados con el recurso.

o Archivos multimedia.

• Incorporación de vídeo guías y audio guías. Estas guías podrán estar asociadas a determinados recursos turísticos o estar disponibles de forma independiente, de forma que se pueda disponer de una función de ayuda accesible, breve y con ejemplos para los usuarios que los demanden.

Cada recurso turístico o cultural contemplará al menos los siguientes elementos:

• Accesibilidad: información de accesibilidad al recurso, como por ejemplo sistemas de transporte (rutas, terminales, vehículos, etc.) así como información de accesibilidad para personas con diversidades funcionales.

• Atractivos: naturales, culturales, eventos programados, etc.

• Actividades: prácticas a realizar en diferentes espacios como paseos de diversos tipos, deportes, cursos y talleres, observación de animales, plantas u objetos, visitas a monumentos y lugares especiales, etc.

• Servicios directamente relacionados con la actividad turística: hospedajes, restaurantes, tiendas, servicios higiénicos, lugares para comer y acampar y otros.

• Servicios directamente relacionados con la actividad cultural: publicaciones, bibliotecas, exposiciones y otros.

• Servicios básicos: energía, agua, salud, telecomunicaciones, bancos, seguridad, etc.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Respecto a la gestión de Secciones Turísticas y Culturales, los recursos podrán ser organizados por medio de secciones, que facilitarán al usuario la navegación y consulta por criterios relacionados con actividades, en lugar de criterios exclusivamente geográficos. La lista de secciones se concretará durante la ejecución del proyecto; a título orientativo, se mencionan las siguientes secciones: Xxxxxxx, Qué ver, Planea tu viaje (Cuadernos de Viaje), Cosas que hacer, Agenda cultural.

Deberá ser el administrador, o los usuarios asignados que dispongan de los permisos necesarios, quien defina y gestione dichas secciones, con la posibilidad de seleccionar elementos visuales diferenciales de cada sección, como un color principal y una imagen de fondo para la cabecera de sus páginas o página principal, que las plantillas deberán asumir dinámicamente en la navegación de manera que el usuario tenga una fácil ubicación en la sección que está consultando.

El gestor de contenidos dispondrá de capacidad para utilizar motores de búsqueda, permitiendo la integración con otros motores de búsqueda de forma eficiente y sencilla.

El gestor de contenidos dispondrá de un sistema de búsqueda de contenido como mínimo con la siguiente funcionalidad:

• Simple: búsquedas por texto.

• Avanzado: búsquedas por tags, categorías, etc.

• Posibilidad de refinamiento de los resultados de búsqueda.

• Búsqueda por aproximación de palabras.

• Indexación de palabras clave.

El gestor de contenidos permitirá parametrizar filtros de búsqueda preseleccionados.

El gestor de contenidos permitirá búsqueda por cercanía, presentando los resultados en forma de listado, acompañados con un mapa donde se marca el radio de búsqueda (configurable).

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos permitirá registrar un histórico de las búsquedas realizadas y permitirá el borrado del histórico de búsquedas.

El gestor de contenidos dispondrá de capacidad para gestionar información relativa a la geolocalización en mapas de los recursos disponibles, siempre y cuando sus características lo permitan y estén previamente geolocalizados a través de los canales y componentes disponibles.

El gestor de contenidos dispondrá de herramientas que permitan la gestión de una agenda de eventos, considerando evento cualquier tipo de información u oferta que requiera una gestión temporal de su publicación.

El gestor de contenidos permitirá proveer a las aplicaciones disponibles, agendas de eventos personalizables adaptadas a la especificidad del canal.

Los eventos estarán geolocalizados y categorizados.

La agenda de eventos incluirá información como fecha, lugares en los que ocurre el evento, recursos específicos (foto, video, audio), así como texto formateado e información específica, considerando como mínimo la siguiente información, sin menoscabo de poder añadir otra:

• Descripción del evento.

• Acceso al ofertante.

• Dirección o localización del evento.

• Otros campos de interés del evento.

El gestor de contenidos permitirá la clasificación, la búsqueda y el acceso a los eventos por diferentes criterios, que podrán ser administrables, por ejemplo, por un interés sectorial, por tipo de evento, por la fecha de publicación (más reciente, esta semana, etc...) o bien por su proximidad geográfica, entre otros.

El gestor de contenidos permitirá integrarse con sistemas de notificación y avisos que permitan mantener informado al usuario del canal sobre aquellos eventos que se hayan marcado como favoritos o importantes.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El gestor de contenidos permitirá la integración con sistemas de star rating (por ejemplo, a través de servicios web, plugins, etc.) que permita configurar la valoración de los contenidos publicados desde los canales/aplicaciones disponibles, siempre y cuando estos contenidos cumplan con los requisitos de accesibilidad definidos en el presente pliego.

El gestor de contenidos permitirá la conexión con redes sociales, permitiendo acceder a los contenidos a través de las principales redes sociales, de manera que la información pueda compartirse con otros usuarios desde los canales que dispongan de dicha funcionalidad. Dispondrá de herramientas que permita configurar la integración con Redes Sociales, como por ejemplo la utilización de gadgets en los sitios web, siempre y cuando estos gadgets cumplan con los requisitos de accesibilidad definidos en el presente pliego.

El gestor de contenidos dispondrá de capacidad para integrarse con sistemas de Web Semántica.

El gestor de contenidos proveerá herramientas para la creación y asignación de tags y palabras clave para el contenido.

Los contenidos gestionados se podrán estructurar de acuerdo a una semántica/ontología específica de Turismo o Cultura. Para ello, el Gestor incorporará soluciones que permitirán el tratamiento semántico de los datos. El adjudicatario definirá e implementará una semántica para la información, basada en vocabularios y códigos de referencia existentes para ciudades y destinos turísticos.

El gestor de contenidos permitirá gestionar catálogos de rutas agrupadas por tipologías.

El gestor de contenidos permitirá incluir al menos la siguiente información descriptiva para cada ruta, georreferenciada:

• Incluir una breve descripción de la misma, con información multimedia.

• Identificar los Puntos de Interés Turístico de la ruta, así como información descriptiva de los mismos.

• Incluir información y enlaces sobre servicios de interés cercanos a la ruta, tales como alojamientos, restaurantes, etc.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Identificar el itinerario/recorrido de la ruta.

• Identificar el perfil altimétrico de la ruta.

• Acceder al itinerario a través de los servicios de Google Maps, donde estarán previamente definidas las rutas.

El gestor de contenidos permitirá la asignación de rutas a tipologías de usuario a partir de los catálogos de rutas predefinidas existentes.

El gestor de contenidos dispondrá de capacidad para integrarse con las aplicaciones de mapas estándar tipo Google Maps o similar.

3.1.4. PORTAL WEB TURÍSTICO

Este componente consiste en el desarrollo y puesta en producción de un portal web que proporcione a los turistas información y funcionalidades que faciliten su visita al destino turístico. También contendrá información cultural relacionada con el Ayuntamiento xx Xxxxxxx de San Xxxx.

La gestión de los contenidos del portal se efectuará mediante el gestor de contenidos descrito en el presente Xxxxxx, el cual constituirá el backend de la solución para el portal.

La puesta en marcha de este componente se plantea como una solución llave en mano, que debe incluir:

• Desarrollo y puesta en producción del Portal Web Turístico.

• Desarrollo y puesta en marcha de todos los sistemas necesarios para la operatividad/gestión de la solución, así como su integración con otros sistemas, en particular con el gestor de contenidos descritos en el presente Pliego.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El portal web seguirá la identidad visual del Ayuntamiento xx Xxxxxxx de San Xxxx.

Deberá cumplir los requisitos establecidos en el apartado 2.3 Requisitos de Software del presente Pliego en relación al cumplimiento de estándares, así como en relación a la accesibilidad y al licenciamiento.

La solución tendrá un diseño modular, permitiendo que la información y funcionalidades o servicios a futuro ofrecidos en el portal puedan ser activados/desactivados en función de los requerimientos del Ayuntamiento xx Xxxxxxx de San Xxxx.

La solución seguirá criterios de usabilidad centrados principalmente en la facilidad del aprendizaje, la velocidad por parte de los usuarios finales para el desempeño de las tareas asociadas, la baja tasa de incidencias, los bajos niveles de frustración, la satisfacción subjetiva y la universalidad. De manera que el diseño de navegación propiciará una navegación amigable e intuitiva. El portal web deberá caracterizarse por un manejo sencillo, una estética agradable, pensando en el usuario y en realizar las acciones solicitadas en el menor número de interacciones posibles.

El portal se diseñará y desarrollará atendiendo a las técnicas SEO (Search Engine Optimization) que permitirán optimizar su posicionamiento en buscadores.

El adjudicatario asegurará la plena funcionalidad del portal web.

El diseño deberá ser visualizable en los diferentes tipos de dispositivos y se adaptará al tamaño y formato de estos dispositivos.

La solución dispondrá de un sistema de notificaciones web PUSH a usuarios.

En general, el portal web turístico se implantará en la infraestructura hardware en el Ayuntamiento xx Xxxxxxx de San Xxxx.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El portal web deberá presentar contenidos multiidioma (castellano e inglés, así como los futuros idiomas que se establezcan), siendo el idioma por defecto el castellano y detectando automáticamente el idioma del navegador del usuario para el resto de idiomas. El idioma también podrá ser elegido por el usuario manualmente. El adjudicatario será responsable de realizar las traducciones y adaptaciones necesarias en los menús y opciones del software correspondientes. Este requisito será aplicable igualmente a las notificaciones PUSH. Los contenidos a mostrar en el portal web, proveniente del gestor de contenidos, serán traducidos cuando corresponda siguiendo las indicaciones descritas en el Componente 1 Gestor de contenidos.

El portal web contará con dos módulos diferenciados: frontend, que será la parte pública de acceso a cualquier usuario, y backend, desde donde los administradores podrán gestionar el contenido del mismo. El gestor de contenidos descrito en el presente Pliego constituirá el backend del portal.

La solución estará diseñada y desarrollada de tal forma que un aumento en la carga de usuarios o de información pueda resolverse dimensionando adecuadamente la arquitectura hardware sobre la que se ejecutará.

El portal web mostrará contenidos georreferenciados en mapas. Estos mapas presentarán características y funcionalidades similares a los existentes actualmente en el Ayuntamiento xx Xxxxxxx de San Xxxx.

En el caso de que el usuario pueda publicar contenido, el sistema ofrecerá la posibilidad de moderación de los contenidos de usuario por parte de los responsables del Ayuntamiento xx Xxxxxxx de San Xxxx, es decir, deberán ser autorizados previamente a su publicación a través del backend por un usuario con privilegios suficientes. Como norma general, por defecto, cualquier información introducida por un usuario que sea pública debería poder ser moderada.

El adjudicatario deberá garantizar la seguridad de la solución, implementando mecanismos que permitirán realizar conexiones seguras hacia/desde los servicios que ofrecen los contenidos siempre que sea posible, y sin solicitar más permisos de los

necesarios para que el portal web funcione correctamente, según se indica en el apartado

2.3 Requisitos de Software y 2.6. Requisitos de Seguridad del presente Xxxxxx.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El portal web deberá ofrecer la posibilidad de compartir información contenida en el mismo a través de las principales redes sociales y aplicaciones de mensajería instantánea.

Por defecto, los usuarios del portal web no precisarán de autenticación para acceder al frontend del portal web turístico, teniendo acceso a toda la información disponible en modo consulta, si bien dispondrán de la opción de registrarse que será necesaria para algunas funcionalidades como edición del perfil, cuadernos de viaje, etc.

Para los usuarios que carezcan de credenciales de usuario, deberá implementarse un procedimiento de registro para dotarles de las misma. Los usuarios que se hayan dado de alta en la aplicación móvil podrán utilizar su usuario y contraseña para acceder al portal web turístico y cultural como usuario registrado. Asimismo, los usuarios que se registren a través del portal web podrán utilizar ese usuario y contraseña para acceder a la aplicación móvil.

El registro de usuarios a través del portal web turístico permitirá el alta, baja y modificación de los datos e información de usuario. Permitirá asimismo que los usuarios registrados en el portal ejerzan su derecho a la eliminación de su cuenta de usuario y el borrado de toda la información de carácter personal que hayan facilitado.

El portal web deberá permitir configurar mediante el backend el uso y/o acceso a las diferentes funcionalidades y contenidos dependiendo del tipo de usuario, esto es, si para una determinada funcionalidad o un determinado contenido solo pueden acceder usuarios registrados, o cualquier usuario sin necesidad de registro.

El portal web ofrecerá la posibilidad de obtener estadísticas de visitas a las distintas secciones del mismo.

Los nombres de las diferentes secciones o funcionalidades indicados en este Pliego son orientativos, pudiendo considerarse otras opciones de nomenclatura y darse variaciones en la estructura indicada durante la ejecución del proyecto.

El portal web turístico dará acceso a la información almacenada en el gestor de contenidos, entre otra:

• Recursos e información turística y cultural

• Agenda de eventos

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Social

• Rutas turísticas

El portal web turístico mostrará información proveniente de los distintos componentes de la iniciativa, la cual será gestionada a través del gestor de contenidos definido en el presente Pliego.

El portal web turístico estará preparado para integrar, cuando estén disponibles, funcionalidades en tiempo real con relación a información recuperada de los diversos componentes del presente Xxxxxx. Adicionalmente, presentará en mapas, cuando esté disponible, información y funcionalidades basadas en la localización, que serán proporcionadas por el Ayuntamiento xx Xxxxxxx de San Xxxx. Cuando sea posible y pertinente, la información geolocalizada se ofrecerá en tiempo real. A título orientativo, se mencionan los siguientes ejemplos:

• Ubicación de autobuses

• Cálculo del tiempo restante para la llegada de autobuses

• Aparcamientos y número de plazas libres en los mismos

• Cálculo y presentación de la ruta óptima para llegar al aparcamiento más cercano con plazas libres

• Indicadores meteorológicos y medioambientales

• Medidas de calidad del aire provenientes de las unidades medioambientales

• Incidencias en los servicios

La información que se indica en el requisito anterior se actualizará de forma dinámica, siendo el adjudicatario responsable de desarrollar los mecanismos automáticos de actualización de dicha información.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El portal web turístico permitirá a los ciudadanos y turistas cumplimentar o responder encuestas para medir su grado de satisfacción, esta información se recogerá y analizará mediante el Panel de Captación de Datos Turísticos.

El portal web incorporará un buscador general y buscadores específicos que permitan al usuario conocer y localizar todas las funcionalidades definidas en el portal, así como la información legal y condiciones del servicio.

El portal web incorporará un mapa del sitio web con la representación jerárquica de las secciones y contenidos para facilitar la navegación.

3.1.5. INFRAESTRUCTURA HARDWARE

Para que la Plataforma Web de Difusión turística tenga cabida en la infraestructura definida en el apartado 1.2.1 Infraestructura, es necesario aumentar dicha infraestructura con un nuevo servidor físico que le provea de la capacidad de computación necesaria para albergar dicha Plataforma.

Respecto al servidor físico, para asegurar la completa compatibilidad de la solución ofertada con la tecnología de servidores y de virtualización actualmente desplegada en el Ayuntamiento xx Xxxxxxx de San Xxxx junto con los planes de evolución previstos para estas tecnologías, el nuevo servidor que se proporcione deberá tener las siguientes características técnicas mínimas:

• Servidor Lenovo ThinkSystem SR630

◦ 2 Ud. Procesador Intel Xeon Silver 4214R 12C 100 W 2,4 GHz

◦ 8 Ud. Memoria RDIMM ThinkSystem 32 GB TruDDR4 2933 MHz (2Rx4 1,2 V)

◦ 1 Ud. ThinkSystem M.2 con placa de habilitación con mirroring

◦ 2 Ud. Disco Duro SSD ThinkSystem M.2 128 GB SATA 6 Gbps sin intercambio en caliente.

◦ 2 Ud. HBA de puerto dual Emulex 16 Gb Gen6 FC

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

◦ 2 Ud. Fuente de alimentación de intercambio en caliente de platino ThinkSystem 750 W (230/115 V)

◦ 1 Ud. ThinkSystem 10Gb 4-port Base-T LOM

◦ 1 Ud. ThinkSystem 1Gb 4-port RJ45 LOM

◦ Garantía 3 Años

◦ Essential Service - 3Yr 24x7 24Hr CSR + YDYD SR630

Para la integración del servidor físico con la infraestructura actual el Ayuntamiento proporcionará la correspondiente licencia de VMware ESXi para el servidor.

Adicionalmente, y con el objeto de disponer de la infraestructura para poder desplegar y mantener con facilidad la Plataforma Web objeto del contrato, el adjudicatario proveerá al Ayuntamiento de una suscripción valida durante el periodo de garantía aplicable al software del proyecto (dos años a partir de la fecha de firma del Acta de Recepción por parte del Ayuntamiento del proyecto) a los siguientes productos:

• Panel Parallels® Plesk Web Pro con capacidad para 30 dominios

• Extensión ImunifyAV+ para Panel Parallels® Plesk Web Pro

3.1.6. ACTUACIONES A REALIZAR

La implantación se plantea como una actuación llave en mano, en la que se deberán realizar todas aquellas actuaciones que permitan la prestación del servicio buscado para los turistas y visitantes del Ayuntamiento xx Xxxxxxx de San Xxxx. Para la puesta en producción, el adjudicatario deberá considerar los requisitos generales y de implantación

que se describen en el presente Xxxxxx. En concreto, será necesario realizar como mínimo las siguientes actuaciones:

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

a) Análisis y diseño de la solución: el adjudicatario deberá realizar una propuesta específica del componente, contemplando la instalación de los elementos que lo componen, las funcionalidades requeridas y las integraciones a realizar con otros sistemas. En su propuesta, el adjudicatario contemplará los contenidos existentes en la actualidad y una propuesta de parrillas a emitir en los diferentes canales. Para el diseño del frontend del portal web el adjudicatario seguirá el siguiente flujo de trabajo:

1. Diseño del wireframe (prototipo) del portal web.

2. Diseño del mockup (montaje) del portal web.

3. Implementación del portal web.

b) Suministro e implantación de la infraestructura hardware: el adjudicatario deberá realizar la implantación completa en producción del nuevo servidor y de la cabina de almacenamiento, todo ello dentro de la infraestructura VMware ESXi 7 actualmente en producción en el Ayuntamiento. Asimismo, dentro de dicha infraestructura y ubicada a nivel de red dentro de la DMZ municipal, el adjudicatario desplegará una maquina virtual con Sistema Operativo Linux y con la instalación apropiada del Panel Parallels® Plesk Web Pro junto con las extensiones adquiridas.

c) Puesta en producción de la solución: Suministro e implantación del componente completo en la infraestructura adquirida. Esta implantación se realizará en los dos entornos municipales: el entorno de producción para la Plataforma Web de Difusión Turística se ubicará en la nueva infraestructura suministrada en el presente contrato; el entorno de preproducción se ubicará en el servidor dedicado definido en el apartado 1.2.4. Esta actuación incluirá como mínimo:

• Carga inicial de los siguientes contenidos, en todos los idiomas en los que aplique:

• Contenidos generales (a mostrar en diferentes canales) generados en el marco del presente Pliego, incluidos los contenidos digitales y contenidos de realidad aumentada y virtual existentes en el Ayuntamiento xx Xxxxxxx de San Xxxx.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Contenidos específicos para el portal web generados en el marco del presente Pliego.

• Contenidos específicos para la aplicación móvil generados en el marco del presente Xxxxxx.

• Migración de los siguientes contenidos existentes, entre otros, en todos los idiomas en los que se encuentren disponibles:

▪ Activos digitales de los recursos turísticos y culturales: imágenes, vídeos, archivos de audio, documentos interactivos, folletos, etc.

▪ Contenidos provenientes de las webs actuales del Ayuntamiento xx Xxxxxxx de San Xxxx.

• xxx.xxxxxxxxxxxxxx.xx

• xxx.xxxxxxxxxxxxxxxxxxxxxxx.xxx

• Traducción de los contenidos existentes al inglés. Todos los contenidos a migrar al gestor de contenidos deberán ser traducidos por el adjudicatario a los idiomas anteriores siempre que los contenidos no se encuentren ya en esos idiomas. Se estima que estos contenidos pueden suponer un total de 40.000 palabras a traducir en cada uno de los idiomas.

• Desarrollo de todas las tareas necesarias para garantizar la correcta integración del componente con la Plataforma y resto de componentes con los que se integra.

• Labores de soporte a la implantación y configuración en los diferentes entornos.

• Pruebas de la solución implementada con el resto de los componentes de la iniciativa con los que interactúa.

• Impartición de capacitación asociada al componente, según lo especificado en el apartado 4.5 Gestión del Cambio, Capacitación y Plan de Sostenibilidad del Proyecto del presente Pliego.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

3.1.7. INTEGRACIONES

La solución estará preparada para integrarse mediante servicios web (API REST) con la Plataforma de Ciudad Inteligente para recuperar información proveniente de los diversos componentes de la iniciativa, así como otros verticales y fuentes que se hayan integrado en dicha Plataforma. Adicionalmente, los datos recibidos del portal y la información registrada de navegación de los usuarios se emplearán como una de las fuentes de datos de la Plataforma de Ciudad Inteligente, de tal modo que se obtendrán indicadores de utilidad para el destino turístico y cultural con relación al uso de la web.

La solución dispondrá de servicios web (API REST) para su integración con sistemas terceros, tales como servicios de información meteorológica (p. ej.: AEMET), Google Maps para la geolocalización de contenidos, YouTube para embeber vídeos, Google Analytics para realizar el seguimiento del uso y del tráfico del portal web u otros que permitan prestar las funcionalidades de las utilidades en el frontend.

La solución deberá integrarse con la Aplicación Móvil Turística definida en el presente Pliego.

La solución deberá ser capaz de integrarse mediante servicios WMS (Web Map Services), servicios WFS (Web Feature Services) y/o una API REST con cualquier Sistema de Información Geográfica que el Ayuntamiento xx Xxxxxxx de San Xxxx pudiese disponer a fecha de la adjudicación o en un futuro.

La solución deberá incorporar contenidos y bases de datos existentes en la actualidad.

La solución deberá poder incorporar contenidos procedentes xx xxxxxxx de datos externas.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

3.1.8. ENTREGABLES

El adjudicatario deberá generar los siguientes entregables:

• Documento de Análisis y Diseño de la solución software propuesta. Debe incluir como mínimo: análisis, diseño de la solución, arquitectura, modelo de datos, detalle de elementos, plan de pruebas, integraciones, chequeo de requisitos de protección de datos y otras normativas a aplicar.

Respecto a la implantación (suministro, instalación, pruebas y capacitación) del software y del hardware, el adjudicatario deberá generar al menos los entregables especificados en el apartado 6.1 Entregables.

3.2. COMPONENTE 2: APLICACIÓN MÓVIL TURISMO XXXXXXX

3.2.1. DESCRIPCIÓN GENERAL

El objetivo a lograr con este componente es posicionar al Ayuntamiento xx Xxxxxxx de San Xxxx como un Destino Turístico Inteligente (DTI) de referencia a través de herramientas tecnológicas de última generación, desarrollando una aplicación móvil que permita su uso durante todas las fases del viaje, idea, planificación, reserva, disfrute y promoción.

La aplicación móvil de Turismo xx Xxxxxxx se desarrollará como un elemento vinculado con la Plataforma de Difusión Turística, ya que deberá recoger de ella toda la información para los usuarios a través de servicios web. De este modo se evitarán duplicidades en la gestión y mantenimiento de la información.

Del mismo modo se integrará también con la Plataforma de Ciudad inteligente definida en el apartado 1.2.5 para facilitar la consulta de los datos y la información procedente del uso de la aplicación móvil.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El planteamiento para el desarrollo de este nuevo canal de difusión partirá de una estrategia de adaptación y cambio, permitiendo introducir imágenes de alto valor promocional a los técnicos de Turismo, y modificarlas en función de sus necesidades. Un ejemplo de esta imagen puede ser el “splash” de inicio, que permita presentar la aplicación móvil o en una determinada época del año sustituirla por un cartel promocional de un evento relevante.

Se concebirá como una app con toda la información para los visitantes y con múltiples funcionalidades, como directorio de recursos turísticos, servicios turísticos, rutas, agenda de eventos culturales y turísticos, notificaciones PUSH, lectura de señalización inteligente, gamificación, etc.

Deberá solicitar información al usuario (por ejemplo, frecuencia de visita, visita en familia, en pareja o en solitario; gustos turísticos/cultural/gastronómicos/deportivos; etc) en los primeros pasos de instalación, a través de un breve cuestionario paso a paso que permita definir el perfil. Esta segmentación se podrá utilizar a efectos estadísticos, así como para ofrecer información personalizada al usuario a través de las distintas secciones.

Deberá incorporar distintas secciones que permitan al turista obtener toda la información de interés de una forma rápida y visual, e integrar funcionalidades de redes sociales que permitan a los usuarios compartir sus experiencias, imágenes, vídeos, comentarios, valoraciones…

Todos los contenidos generados por los usuarios aportan un valor cada vez más en alza para el turista actual, ya que son opiniones independientes exentas de interés promocional. Cuidar esta vía de comunicación y facilitar mecanismos y animar a los usuarios a que generen sus propios contenidos y los compartan a través de las Redes Sociales resulta actualmente esencial para la promoción turística.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

En el proceso de definición funcional de las aplicaciones móviles se deberán decidir las secciones más relevantes que se implementarán, priorizando aquellas que ofrezcan un valor añadido a los usuarios frente a aquellas que se puedan obtener desde cualquier aplicación generalista. El diseño gráfico de las aplicaciones también debe ofrecer algo distinto, que potencie la marca de Turismo xx Xxxxxxx al tiempo que da una imagen de modernidad tecnológica.

A continuación se enumeran algunos de los módulos con que debería contar la aplicación de Turismo xx Xxxxxxx, con el objetivo de no quedarse únicamente en una app para promoción de destino, sino para aportar valor también al ciudadano:

• Planificador turístico (Cuadernos de viaje).

• Catálogo de Recursos y Servicios Turísticos/Culturales.

• Agenda de eventos interactiva y con avisos.

• Recepción de notificaciones “PUSH”.

• Rutas e itinerarios turísticos (p. ej. ruta de la tapa).

• Directorio de empresas de interés turístico (restauración, hospedaje, actividades turísticas, etc.)

• Posibilidad de integración de funcionalidades de “gamificación” (yincanas, juegos, pasaporte turístico…) mediante Webview.

• Posibilidad de Integración con futura Tarjeta turística digital (para promociones y descuentos).

• Funcionamiento offline (bajo demanda) y online en función de los apartados y recursos de la App. Recarga automática mientras la App está abierta y recarga inicial al abrir la App.

• Información de destino, funciones Web 2.0, redes sociales…

Adicionalmente, se valorará que la aplicación cuente con los siguientes módulos:

• Segmentación de la oferta por perfiles de usuario.

• Transporte público (marquesinas inteligentes) y parkings.

• Lectura de “balizas turísticas”, señalización inteligente.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Otros servicios municipales de interés.

Este componente consiste en el desarrollo y puesta en producción de una aplicación móvil que facilite a los turistas información y funcionalidades que faciliten su visita al destino turístico. La puesta en marcha de este componente se plantea como una solución llave en mano, que debe incluir:

• Desarrollo y puesta en producción de la aplicación móvil, incluyendo frontend y backend (se valorará la opción de tener una backend unificado para la plataforma web y para la App).

• Desarrollo y puesta en producción de todos los sistemas necesarios para la operatividad/gestión de la solución, así como su integración en la Plataforma de Destino Turístico Inteligente descrita en el presente Pliego.

La aplicación móvil turística que el adjudicatario deberá desarrollar incluirá un módulo de lanzadera, que consistirá en un contenedor o catálogo de aplicaciones móviles, permitiendo al usuario la elección de la aplicación o aplicaciones de su interés, y su invocación o descarga. La solución permitirá la inclusión tanto de aplicaciones propias como de aplicaciones de terceros que el Ayuntamiento xx Xxxxxxx de San Xxxx quiera promocionar o recomendar a sus ciudadanos y visitantes.

3.2.2. REQUISITOS

El adjudicatario desarrollará y pondrá en producción una aplicación móvil turística con las siguientes características mínimas:

• La aplicación móvil deberá estar disponible al menos para las dos últimas versiones de los 2 sistemas operativos móviles más utilizados.

• Deberá basar su desarrollo en estándares de fácil mantenimiento que permitan la creación, distribución y gestión de contenidos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Deberá seguir las especificaciones relativas a usabilidad y accesibilidad especificadas en el apartado 2.3 Requisitos de software del presente pliego.

• La aplicación deberá cumplir la norma UNE 178503 “Destinos turísticos inteligentes. Semántica aplicada al turismo” (o equivalente), debiendo el modelo de datos estructurarse conforme a lo especificado en dicha norma.

• La solución tendrá un diseño modular, permitiendo que la información y funcionalidades o servicios a futuro ofrecidos en la aplicación puedan ser activados/desactivados sin necesidad de recompilación de la aplicación desde el entorno de gestión.

• Se deberá asegurar la plena funcionalidad de la aplicación móvil, sin que ello suponga, en ningún momento, la adquisición por parte del Ayuntamiento xx Xxxxxxx de San Xxxx de licencias, componentes o aplicaciones adicionales, fuera de los obtenidos en el presente proyecto.

• La aplicación y sus actualizaciones serán publicadas en los diferentes markets (Google Play Store, Apple Store, etc.) bajo las credenciales del Ayuntamiento xx Xxxxxxx de San Xxxx, acorde a los procedimientos estandarizados en cada market.

• La aplicación móvil seguirá la identidad visual del Ayuntamiento xx Xxxxxxx de San Xxxx.

• La solución debe buscar unos criterios mínimos de usabilidad centrados principalmente en la facilidad del aprendizaje, la velocidad por parte de los usuarios finales para el desempeño de las tareas asociadas, la baja tasa de incidencias, los bajos niveles de frustración, la satisfacción subjetiva y la universalidad.

• El diseño de navegación propiciará una navegación amigable e intuitiva. La aplicación deberá caracterizarse por un manejo sencillo y una estética agradable.

• El diseño deberá ser visualizable en los diferentes tipos de dispositivos y se adaptará al tamaño y formato de estos dispositivos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• La solución permitirá el funcionamiento online y offline: incorporará un mecanismo de caché local a varios niveles y paquetes de contenidos iniciales. Al descargarse, la aplicación incluirá una serie de contenidos por defecto, que permitirán su uso incluso si tras la descarga el terminal no dispone de conexión a Internet por falta de cobertura u otras cuestiones.

• La solución dispondrá de un sistema de notificaciones PUSH a usuarios.

• La solución se implantará, preferentemente, en la infraestructura existente en el Ayuntamiento xx Xxxxxxx de San Xxxx. En caso de ser necesario debido a la arquitectura de la solución, y previa aceptación por parte del Ayuntamiento xx Xxxxxxx de San Xxxx, la solución podrá tener elementos concretos desplegados en entornos cloud de terceros, en cuyo caso, el acceso a dichos entornos será suministrado por el adjudicatario sin coste alguno adicional para el Ayuntamiento durante el periodo de garantía de la solución contratada.

• Todos los interfaces de usuario de la aplicación móvil deberán proporcionarse en castellano. Los interfaces de usuario tendrán la capacidad de visualizar, almacenar y gestionar contenido en varios idiomas, al menos en castellano e inglés. Este requisito será aplicable igualmente a las notificaciones PUSH.

• La aplicación permitirá definir el idioma que se mostrará por defecto al usuario cuando su dispositivo móvil esté configurado en una lengua no disponible, es decir, distinta xx xxxxxxxxxx e inglés. La aplicación detectará de forma automática el idioma del dispositivo móvil y mostrará los menús y demás contenidos en el idioma del usuario, si es posible, o en el idioma configurado por defecto, en caso contrario.

• La aplicación móvil incluirá una opción de lectura de códigos QR/BIDI, para la lectura del código mediante librerías estándar y el acceso al recurso correspondiente.

• La aplicación móvil dispondrá de un tutorial inicial de sencilla comprensión para explicar su uso y sus principales funcionalidades.

• La aplicación móvil dispondrá de una opción de Ayuda online que permita al usuario conocer todas las funcionalidades definidas en la misma, así como la información legal y condiciones del servicio.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• La aplicación móvil contará con dos módulos diferenciados: frontend y backend, desde donde los administradores podrán gestionar el contenido de la misma.

• La aplicación móvil deberá permitir a cada usuario configurar la aplicación según sus preferencias. La lista completa de opciones a configurar se determinará en la ejecución durante las fases de análisis y diseño.

• La solución deberá estar basada en la georreferenciación utilizando estándares de intercambio de información geográfica como pueden ser: geojson, kml, wms, etc.

• La aplicación móvil mostrará contenidos georreferenciados en mapas. Estos mapas presentarán características y funcionalidades similares a los existentes actualmente en los portales del Ayuntamiento xx Xxxxxxx de San Xxxx.

• La aplicación móvil dispondrá de un módulo de accesibilidad que implemente la funcionalidad TTS (Text-to-Speech) en los distintos idiomas soportados. En caso de ser necesario suscribirse a un módulo de pago de un tercero, el adjudicatario proporcionará, sin coste adicional para el Ayuntamiento, dicho modulo durante todo el periodo de garantía de la solución.

• La aplicación móvil tendrá que registrar la actividad de navegación y de descarga por parte de los usuarios, siempre con su consentimiento explícito en el momento de la descarga de la aplicación, ajustándose a la normativa vigente respecto a protección de datos de carácter personal.

• La aplicación móvil dispondrá de una pantalla de bienvenida personalizable desde el backend, desde la cual se navegará a las distintas opciones y funcionalidades de la aplicación.

• En el caso de que el usuario pueda publicar contenido, el sistema ofrecerá la posibilidad de moderación de los contenidos de usuario por parte de los responsables del Ayuntamiento xx Xxxxxxx de San Xxxx, es decir, deberán ser

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

autorizados previamente a su publicación a través del backend por un usuario con privilegios suficientes. De esta forma, se deberán poder configurar los contenidos (comentarios, fotografías, vídeos, cuadernos de viaje, etc.) para que éstos puedan estar sujetos a moderación o no. Como norma general, por defecto, cualquier información introducida por un usuario que sea pública debería poder ser moderada.

• La solución estará diseñada y desarrollada de tal forma que un aumento en la carga de usuarios o de información pueda resolverse dimensionando adecuadamente la arquitectura hardware sobre la que se ejecutará.

• La solución a implementar debe garantizar el correcto funcionamiento y sin exhibición de errores en la aplicación, independientemente de la cantidad de solicitudes que realicen los usuarios.

• El adjudicatario deberá garantizar la seguridad de la solución, implementando mecanismos que permitirán realizar conexiones seguras hacia/desde los servicios que ofrecen los contenidos siempre que sea posible, y sin solicitar más permisos de los necesarios para que la aplicación funcione correctamente.

• El diseño de la solución deberá garantizar las funciones básicas de confidencialidad, integridad y disponibilidad de la información, y para ello, el sistema de gestión deberá contar con herramientas de backup, recuperación, exportación e importación de datos, y registrar un log de auditorías para consulta e informe de los accesos y las acciones de los diferentes usuarios, según lo establecido en el presente Pliego.

• La aplicación móvil deberá contar con capacidades de búsqueda de contenido por los principales parámetros de cada apartado.

• La aplicación móvil deberá ofrecer la posibilidad de compartir información contenida en la misma a través de las principales redes sociales y aplicaciones de mensajería instantánea.

• Por defecto, los usuarios de la aplicación móvil no precisarán de autenticación para acceder al frontend de la aplicación, teniendo acceso a toda la información

disponible en modo consulta, si bien dispondrán de la opción de registrarse. Los usuarios administradores de la aplicación móvil deberán autenticarse para acceder al backend de la aplicación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Para los usuarios que carezcan de credenciales de usuario, deberá implementarse un procedimiento de registro para dotarles de las mismas. Los usuarios que se hayan dado de alta en el portal web turístico podrán utilizar su usuario y contraseña para acceder a la aplicación móvil como usuario registrado. Asimismo, los usuarios que se registren a través de la aplicación móvil podrán utilizar ese usuario y contraseña para acceder al portal web.

• El registro de usuarios a través de la aplicación móvil permitirá el alta, baja y modificación de los datos e información de usuario. Permitirá asimismo que los usuarios registrados en la aplicación móvil ejerzan su derecho a la eliminación de su cuenta de usuario y el borrado de toda la información de carácter personal que hayan facilitado.

• El usuario que lo desee se podrá dar de baja de la aplicación, lo que supondrá la eliminación de los registros asociados al uso de la misma.

• La autenticación se realizará conforme a lo solicitado en los requisitos generales establecidos en el apartado 2.6 Requisitos de Seguridad del presente Xxxxxx.

• La aplicación móvil deberá permitir configurar mediante el backend el uso y/o acceso a las diferentes funcionalidades y contenidos dependiendo del tipo de usuario, esto es, si para una determinada funcionalidad o un determinado contenido solo pueden acceder usuarios registrados, o cualquier usuario sin necesidad de registro.

Respecto al Frontend, la aplicación móvil dispondrá de los siguientes apartados principales:

• Información turística y cultural

• Utilidades

Adicionalmente, la aplicación móvil estará en disposición de soportar las siguientes herramientas:

• Señalización inteligente (beacons y geofencing)

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Visor de realidad aumentada

• Lanzadera de aplicaciones móviles

3.2.3. FUNCIONALIDADES

Los nombres de los diferentes apartados o funcionalidades indicados en este pliego son orientativos, pudiendo considerarse otras opciones de nomenclatura durante la ejecución del proyecto.

A continuación, se desarrolla la funcionalidad orientativa de cada uno de estos apartados:

3.2.3.1. Información de Destino Turístico y Cultural

La aplicación móvil deberá mostrar los contenidos turísticos y culturales publicados en el Portal Web Turístico, (presentados en la propia aplicación móvil y con opción de recibir nuevas entradas mediante notificación PUSH).

Dispondrá de un buscador de recursos turísticos y culturales, que al menos presente opción de búsqueda por tipo y atributos de los recursos. Las búsquedas mostrarán de inicio unos resultados basados en la ubicación geográfica del dispositivo.

La aplicación móvil permitirá seleccionar el detalle del recurso, presentando al menos las siguientes funcionalidades:

• Visualización del recurso sobre un mapa.

• Acceso a la ficha del recurso con la información que exista sobre él (incluyendo fotos, vídeos y audio guías, según su disponibilidad).

• Compartición del recurso a través de la funcionalidad nativa de compartición de datos entre aplicaciones del sistema operativo móvil

• Navegación desde la posición actual hasta el recurso.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La aplicación dispondrá de un área específica donde se mostrará la agenda de eventos. La agenda de eventos incluirá información como fecha, lugares en los que ocurre el evento, recursos específicos (foto, video, audio), así como texto formateado e información específica (p. ej., precio de entrada). Si el evento dispone de la posibilidad de compra de entradas, puede indicarse un enlace al mismo.

Entre los contenidos disponibles para el usuario existirá una colección de experiencias recomendadas. Dichas experiencias recomendadas podrán consultarse dentro de una sección o categoría específica en las aplicaciones en movilidad. Este contenido asociará una serie de lugares (o uno único) junto a una descripción detallada de la experiencia, recursos gráficos propios y la posibilidad de fijar una fecha o período de validez de la experiencia. La aplicación permitirá filtrar la experiencia en función de determinados parámetros, tales como fecha, temática o nivel de dificultad.

3.2.3.2. Rutas Turísticas

La aplicación móvil deberá mostrar la información de rutas turísticas publicadas en el Portal Web Turístico del presente Pliego, con visualización en la propia aplicación móvil y con opción de recibir nuevas entradas mediante notificación PUSH.

La aplicación móvil presentará las rutas con al menos las siguientes funciones:

• Listado de rutas disponibles, ordenado por proximidad a la ubicación del dispositivo.

• Mapa de visualización de la ruta seleccionada, con cambio entre modo mapa y modo lista, acceso a la pantalla de descripción de cada ruta y visualización de la misma sobre un mapa en el dispositivo móvil.

• Compartición del recurso a través de la funcionalidad nativa de compartición de datos entre aplicaciones del sistema operativo móvil

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Vista y seguimiento de rutas, permitiendo realizar check-in en lugares según esté establecido en la ruta. Este check-in indicará a la ruta los lugares visitados de la misma, quedando reflejados los lugares pendientes.

La aplicación mostrará de forma atractiva el conjunto de experiencias disponibles presentándolas de modo que el usuario pueda seleccionar entre ellas. Se valorará que el usuario pueda descargar a su dispositivo el contenido de la experiencia seleccionada con el fin de permitir su uso en modo offline.

La aplicación incluirá un calendario en el que usuario podrá seleccionar la fecha prevista para la visita a determinados recursos turísticos de la ruta, especialmente en el caso de monumentos, museos o centros de interpretación del patrimonio.

La aplicación mostrará el nivel de dificultad de la ruta o del acceso al recurso seleccionado, la longitud y duración aproximada del recorrido, así como el grado de accesibilidad para que pueda ser catalogado como itinerario de turismo accesible.

La aplicación estará preparada para integrase con un sistema futuro de guiado mediante realidad aumentada que muestre el itinerario a seguir a lo largo de la ruta.

Mediante un sistema de Beacons o georeferencia el sistema de navegación de la aplicación avisará con vibración y/o alerta sonora cuando el usuario se encuentre a corta distancia de un punto de interés o información de la ruta o recurso. Igualmente, mostrará en pantalla algún símbolo de forma que, presionando sobre el mismo, se pueda acceder a los contenidos de la ficha técnica correspondiente.

La aplicación permitirá mostrar una ficha técnica de los recursos turísticos, con información y contenidos sobre el mismo (imágenes, vídeos, textos, animaciones, mapas, esquemas o locuciones para una mayor accesibilidad por parte de personas invidentes). La aplicación informará además sobre las recomendaciones de uso o conservación de determinados recursos o rutas a visitar.

Se valorará que en el transcurso de la ruta, la aplicación permitirá el acceso, en cualquier momento, a la información sobre la distancia recorrida, distancia restante o distancia al siguiente punto de interés del itinerario.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La aplicación dispondrá de un sistema de reinicio del guiado para que, en caso de pérdida momentánea de cobertura GPS, se pueda volver a posicionar correctamente al usuario en la ruta.

La aplicación móvil permitirá almacenar las rutas o visitas realizadas, así como otras seleccionadas para realizar en un futuro. El usuario podrá compartir esta información con otros usuarios, invitándoles a realizar esas rutas o visitas.

3.2.3.3. Cuadernos de viaje de usuario

La aplicación móvil accederá a la información de Cuadernos de Viaje (Planea tu Viaje) publicados en el Portal Web Turístico presentándolos en la propia aplicación móvil y con opción de sincronización con dicho Portal.

La versión móvil de los cuadernos de viaje de usuario:

• Permitirá múltiples cuadernos por usuario.

• Opción de añadir al cuaderno de viaje recursos turísticos desde la correspondiente pantalla de visualización de estos recursos.

• Selección por parte del usuario del número de días de la visita y el orden.

• Visualización en mapa e invocación a la aplicación de mapas nativa del sistema operativo del dispositivo móvil para funciones adicionales.

• Compartición del recurso a través de la funcionalidad nativa de compartición de datos entre aplicaciones del sistema operativo móvil.

La aplicación móvil dispondrá de una funcionalidad que dará la posibilidad al usuario de crear sus propios planes personalizados. Podrá crear un plan indicando un nombre, el

número de días del plan, y el tipo de plan. Podrá asignar a cada plan eventos, rutas y lugares de entre los contenidos disponibles. Estos planes podrán compartirse en redes sociales o enviarse a los contactos del usuario.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La aplicación móvil ofrecerá la posibilidad de crear un espacio personal y la gestión de contenidos Favoritos. El usuario podrá seleccionar contenidos como favoritos y asociarles comentarios privados. En cada contenido, el usuario dispondrá de un botón “Favorito” que permitirá almacenar dicho contenido como favorito, asociándolo a un nombre y comentario. Desde las principales vistas de las aplicaciones el usuario podrá acceder al listado de favoritos.

3.2.3.4. Utilidades

Desde el apartado de Utilidades se proporcionará información de utilidad sobre el destino al visitante, tales como:

• Información meteorológica

• Servicios de emergencia, médicos y farmacias

• Gasolineras

• Otros datos accesibles de la Plataforma de Destino Turístico Inteligente

• Convertidor de moneda

• Traductor

• Contacto

3.2.3.5. Información meteorológica

La aplicación móvil mostrará la información meteorológica de la ubicación donde se encuentre el usuario y/o del municipio xx Xxxxxxx de San Xxxx. Para ello se integrará con sistemas públicos y gratuitos de información meteorológica que no impliquen ningún coste para el Ayuntamiento xx Xxxxxxx de San Xxxx (ni durante la ejecución del proyecto, ni a futuro tras su finalización).

3.2.3.6. Servicios de emergencia, médicos y farmacias

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La aplicación móvil deberá mostrar los contenidos publicados en el Portal Web Turístico del presente Pliego en relación a los servicios de emergencia, médicos, farmacias y otros equivalentes, presentando en la propia aplicación móvil y con opción de recibir nuevas entradas mediante notificación PUSH.

La aplicación móvil seleccionará automáticamente mediante el sistema de localización del dispositivo móvil los puntos de interés más cercanos a su ubicación geográfica. En el caso que se localice más de uno cerca de la localización del dispositivo se mostrará una lista para que el usuario seleccione el que prefiera.

Dispondrá de una versión básica del buscador que al menos presente opción de búsqueda por tipo y atributos de los recursos disponibles dentro de este conjunto de datos. Las búsquedas mostrarán de inicio unos resultados, sin necesidad de interacción del usuario, basados en la ubicación geográfica del dispositivo.

La aplicación móvil presentará la oferta de servicios con al menos las siguientes funciones:

• Listado de servicios disponibles ordenados por proximidad a la ubicación del dispositivo.

• Acceso a la ficha del servicio seleccionada con la información que exista sobre él (ubicación, datos de contacto, horarios, etc.).

3.2.3.7. Contacto

La aplicación presentará un canal de comunicación con los usuarios. Para ello, incluirá un formulario que permitirá a los usuarios enviar de forma directa al Ayuntamiento xx Xxxxxxx de San Xxxx preguntas, sugerencias o recomendaciones incluyendo un correo electrónico de contacto para poder ser atendidos, en caso necesario, de manera individual y directa.

La aplicación incluirá una sencilla encuesta de valoración de la experiencia por parte del usuario, de modo que se pueda recibir un feedback directo que ayude a mejorar la experiencia.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La aplicación móvil constituirá, gracias a estas funcionalidades, uno de los canales de comunicación para recoger información tanto de ciudadanos como de organizaciones, así como de la actividad que éstos realizan en su interacción a través de la aplicación móvil, para poder luego evaluar y medir diferentes indicadores y poder tomar decisiones dirigidas a mejorar el nivel de satisfacción de los mismos.

3.2.3.8. Lanzadera de aplicaciones móviles

El objeto de la presente funcionalidad es ofrecer un acceso unificado a las aplicaciones móviles que el Ayuntamiento xx Xxxxxxx de San Xxxx considere que debe promocionar a modo de catálogo de aplicaciones.

Esta funcionalidad ofrecerá navegación por las listas, diferenciadas, de aplicaciones móviles del Ayuntamiento xx Xxxxxxx de San Xxxx y aplicaciones móviles recomendadas o de terceros. El listado de dichas aplicaciones a incluir será proporcionado por el Ayuntamiento xx Xxxxxxx de San Xxxx en tiempo de ejecución del proyecto. Se estima que el número aproximado de aplicaciones móviles a incluir será de un máximo de 6.

Para cada aplicación en dicha lista se mostrará el detalle o ficha de cada aplicación, con el contenido explicativo o promocional mantenido por personal técnico del Ayuntamiento xx Xxxxxxx de San Xxxx a través del backend.

La invocación de la aplicación desde su ficha y/o desde la lista provocará las siguientes acciones:

• Si la aplicación móvil ya ha sido instalada se abrirá de la forma habitual.

• Si no está instalada se invocará la ficha de la aplicación móvil en la tienda de aplicaciones correspondiente (APP Store, Play Store, etc.).

Ofrecerá la posibilidad de generar y emitir notificaciones PUSH para indicar las nuevas aplicaciones incorporadas al catálogo.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Contará con una vista principal, vista única que mostrará el catálogo de aplicaciones disponibles, con un control tipo pestañas para cambiar entre la lista de aplicaciones móviles propias y la lista de aplicaciones móviles de terceros o recomendadas.

3.2.4. BACKEND

Como backend se utilizará preferentemente el gestor de contenidos descrito en el apartado 3.1.3 del presente Xxxxxx.

El backend facilitará la administración de todas las funcionalidades de la aplicación móvil.

El backend será accesible mediante un entorno web.

Para cada una de las funcionalidades incluidas en la aplicación móvil, el backend permitirá realizar las funciones de administración necesarias para su correcto funcionamiento, principalmente, alta, baja y modificación de módulos o aplicaciones incluidas.

El backend proporcionará acceso al módulo de administración de usuarios para gestionar el listado y los permisos de los mismos.

El backend incorporará una funcionalidad de alta masiva de usuarios, así como funcionalidad para verificar y aprobar los usuarios cargados de esta forma (individualmente o en grupos de usuarios).

El backend dispondrá de un módulo de auditoría que registre todas las operaciones realizadas por los usuarios del gestor de contenidos con un período de vigencia o almacenamiento de la información según lo estipulado en el Esquema Nacional de Seguridad (ENS).

Desde el backend se podrán gestionar y configurar directamente los datos a visualizar en el frontend, indicando su origen, permitiendo indicar si los campos se mostrarán o no,

la asignación de permisos función del perfil, etc. El conjunto de condiciones de configuración se determinará durante la fase de análisis y diseño, y deberá estar orientado a reducir o eliminar la necesidad de programación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Desde el backend se podrán gestionar los datos y comportamiento del interfaz de usuario por defecto, siendo posible definirlos al menos por tipo de perfil.

El adjudicatario desarrollará servicios web de forma que la información de la aplicación pueda ser explotada en otras aplicaciones externas o del propio Ayuntamiento xx Xxxxxxx de San Xxxx.

3.2.5. INFRAESTRUCTURA HARDWARE

Para que el backend de la App Turística (tanto si es único como si es propio de la App) tenga cabida en la infraestructura definida en el apartado 1.2.1 Infraestructura, es necesario aumentar dicha infraestructura con una nueva cabina de almacenamiento que permita ampliar el espacio de almacenamiento necesario para los elementos de la aplicación móvil Turismo Xxxxxxx que sea necesario albergar en las infraestructuras municipales; dicha cabina se reutilizará también para albergar la información propia de la Plataforma Web así como la del Panel de captación de datos turísticos.

Para asegurar la completa compatibilidad de la solución ofertada con la tecnología de servidores y de virtualización actualmente desplegada en el Ayuntamiento xx Xxxxxxx de San Xxxx junto con los planes de evolución previstos para estas tecnologías, la nueva cabina de almacenamiento que se proporcione por parte del adjudicatario deberá tener las siguientes características técnicas mínimas:

• IBM FlashSystem 5200 NVMe Cache 64 GB

◦ 1 Ud. IBM FlashSystem 5200 NVMe Control Enclosure

◦ 2 Ud. Tarjeta Adaptador 4 Puertos 16 Gb Fibre Channel

◦ 4 Ud. Puerto Ethernet 10Gigabit

◦ 4 Ud. NVMe Flash Core Module 9.6 TB

◦ Expert Care Advanced for FS5200 durante 3 años

◦ Cable Alimentación PDU

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La cabina de almacenamiento se suministrará con las licencias necesarias para su completa integración con la infraestructura actual.

3.2.6. ACTUACIONES A REALIZAR

La implantación se plantea como una actuación llave en mano, en la que se deberán realizar todas aquellas actuaciones que permitan garantizar el correcto funcionamiento de la solución. Para la puesta en producción, el adjudicatario deberá considerar los requisitos generales y de implantación que se describen en el presente Xxxxxx. En concreto, será necesario realizar como mínimo las siguientes actuaciones:

• Desarrollo, prueba y puesta en producción de la aplicación móvil, frontend y

backend.

• Integración con el resto de los componentes con los que interactúa la aplicación móvil, según lo especificado en el apartado INTEGRACIONES de este componente.

• Traducción de todos los contenidos propios de la App así como de su interfaz al idioma inglés. Se estima que la interfaz y que estos contenidos propios pueden suponer un total de 5.000 palabras a traducir en cada uno de los idiomas.

• Suministro e implantación de la infraestructura hardware: el adjudicatario deberá realizar la implantación completa en producción de la cabina de almacenamiento, todo ello dentro de la infraestructura VMware ESXi 7 actualmente en uso en el Ayuntamiento.

• Integración con la Plataforma de Ciudad Inteligente mediante realización de API Rest para recuperar la información de la Aplicación Móvil TurismoAlcazar y desarrollo de

vertical de Turismo (incluyendo panel del cuadro de mando e informes) en la Plataforma de Ciudad Inteligente.

• Para el diseño del frontend el adjudicatario seguirá el siguiente flujo de trabajo:

1) Diseño del wireframe de la aplicación móvil.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

2) Diseño del mockup de la aplicación móvil.

3) Implementación de la aplicación móvil.

El adjudicatario realizará una carga inicial y diseñará los procesos de actualización de los contenidos necesarios para que todas las secciones definidas en la aplicación móvil dispongan de información funcional, válida y completa. Entre otros, el adjudicatario cargará la información existente en el Ayuntamiento xx Xxxxxxx de San Xxxx, así como los contenidos a desarrollar por el adjudicatario.

El adjudicatario realizará una entrega totalmente funcional de los desarrollos en producción. Esto implica que todas las secciones desarrolladas deberán tener contenidos. En caso de no disponer de los mismos para alguna de las secciones, deberán ser solicitados al Ayuntamiento xx Xxxxxxx de San Xxxx.

El adjudicatario impartirá la capacitación asociada al componente, según lo especificado en el presente Xxxxxx.

3.2.7. INTEGRACIONES

La aplicación móvil deberá integrarse con el resto de componentes con los que interactúa. En particular, se integrará con:

• La Plataforma de Ciudad Inteligente: Los datos recibidos de la aplicación y la información registrada de navegación de los usuarios se emplearán como una de las fuentes de datos de dicha Plataforma, de tal modo que en el Cuadro de Mando de la misma se obtendrán indicadores de utilidad para el destino turístico. Esto se

realizará mediante la API Rest que deberá tener la Plataforma Web de Difusión Turística.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• El gestor de contenidos, descrito en el Componente 1 del presente Pliego. La aplicación accederá a los contenidos y servicios del gestor de contenidos para presentarlos a los usuarios en sus dispositivos móviles.

• El Portal Web Turístico, descrito en el Componente 1 del presente Xxxxxx. En particular, la aplicación móvil accederá a los contenidos y servicios de las secciones recomendador turístico, información turística y rutas turísticas, entre otros.

La aplicación móvil deberá integrarse con sistemas de terceros, tales como la agenda cultural, los servicios de información meteorológica u otros que permitan prestar las funcionalidades de las Utilidades en el frontend.

3.2.8. ENTREGABLES

El adjudicatario deberá generar los siguientes entregables:

3.3. COMPONENTE 3: PANEL DE CAPTACIÓN DE DATOS TURÍSTICOS

3.3.1. DESCRIPCIÓN GENERAL

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El objetivo de esta actuación es la puesta en producción de una herramienta para la creación, gestión y monitorización de encuestas principalmente dirigidas a conocer los patrones de uso de las TIC y los hábitos digitales de los visitantes x Xxxxxxx de San Xxxx, así como a analizar parámetros de comportamiento del visitante en el territorio.

Los resultados de las encuestas realizadas con esta herramienta se emplearán, principalmente, para la definición de la estrategia digital del Ayuntamiento xx Xxxxxxx de San Xxxx.

Esta actuación se plantea como un proyecto integral de análisis, diseño, implantación y configuración de los elementos software necesarios para la puesta en producción de un Panel de Captación de Datos Turísticos.

El objetivo de este componente es mejorar la capacidad de recogida y procesamiento de la información turística mediante la implantación de una herramienta tecnológica, integrada con la Plataforma de Difusión Turística, fácil de utilizar y con inmediatez en el tratamiento de los datos recogidos.

Las oficinas de información turística deben convertirse en puntos de captación de datos de los visitantes, sin penalizar el trabajo de promoción e información que se realice desde estos puntos.

Generalmente se recopilan en papel una serie de datos turísticos que posteriormente se procesan de forma manual, transformándolos a formato de hoja de calculo, y se envían a los responsables de turismo, para ayudar en la toma de decisiones o la evaluación de las estrategias de difusión y promoción del destino. Esta información se suele limitar fundamentalmente a registrar el día de la visita, el perfil del visitante, la procedencia y el número de personas.

De forma adicional, para evaluar la calidad de la atención recibida en la oficina de información turística, se pueden realizan encuestas aleatorias a los visitantes, que se

recogen también a través de un cuestionario en papel, y que permiten generar informes periódicos de calidad y satisfacción.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Para ello es importante disponer de herramientas tecnológicas adecuadas, y sobre todo, que se integren con el resto de componentes del Centro de Turismo Inteligente. Como principales premisas de las herramientas de captación de datos se podrían citar las siguientes:

• El proceso de captación debe ser rápido e inmediato. De esta forma no se penalizan otras tareas por parte de los responsables de la oficina de información, ni se hace esperar al visitante.

• Los datos se deben gestionar de forma automática. Almacenados en una Base de Datos desde el momento que se finaliza la captación. Además se registrará automáticamente datos como la fecha, hora, responsable…

• El procesado de la información debe ser automático. En muchas oficinas continúan gestionando los datos a través de una tabla en papel que obliga a un procesado posterior para generar los informes estadísticos, con una gran pérdida de tiempo.

• La extracción de informes turísticos deberá ser en tiempo real. Se deberán configurar modelos de informes que se puedan filtrar por un rango de fechas, de forma que se pueda conocer el alcance de una campaña, una temporada, una anualidad, o incluso comparar distintas anualidades.

Esta captación de datos podría hacerse extensiva a recursos turísticos, alojamientos y restaurantes, facilitándoles un medio Web para que el turista facilite los datos a través de formularios similares o personalizados para cada uso, incluso se puede realizar una herramienta de importación de datos que cargue toda la información que se facilite según una plantilla determinada en formato de hoja de calculo (mediante fichero CSV), facilitando al máximo la colaboración de las empresas.

Aunque se trataría de una aplicación restringida a responsables de información turística, que no estaría en ningún caso a disposición del público, desde el gestor de

contenidos de la Plataforma de Difusión se definirían los roles, usuarios y contraseñas para el acceso a la aplicación, así como los puntos de registro.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

De esta forma, además de constituir una medida de seguridad adicional, se podrá almacenar de forma automática la persona que ha realizado cada uno de los registros de información, el punto de captación, y la fecha y hora.

En caso de ser usada a través de la aplicación móvil TurismoAlcazar, la herramienta de captación deberá funcionar de forma independiente y sin necesidad de que los dispositivos tengan conexión a internet, para lo que almacenará la información en el dispositivo móvil hasta disponer de una conexión. En ese momento se sincronizará con la base de datos de la plataforma almacenando los nuevos registros.

3.3.2. REQUISITOS TÉCNICOS

La herramienta deberá cumplir con los siguientes requisitos:

• La herramienta permitirá la captación de datos en las instalaciones turísticas habilitadas para ello presentará en su frontend (una interfaz web) formularios definidos en su backend para que los operarios turísticos puedan captar los datos básicos de los visitantes (como por ejemplo: numero de visitantes en grupo, edad, Origen del grupo, etc)

• El sistema no impondrá ningún tipo de limitaciones en cuanto a la cantidad de encuestas a realizar.

• Capacidad de creación y edición sencilla de formularios de encuestas, sin necesidad de programación.

• La herramienta contará con formularios predefinidos permitiendo su creación, modificación y eliminación, y ofreciendo la posibilidad de personalizar el diseño de los mismos.

• El diseño de las encuestas permitirá la segmentación de las mismas en páginas y/o secciones.

• El administrador de la herramienta tendrá la posibilidad de programar la publicación de encuestas definiendo fecha de publicación y fecha de finalización.

• Para la adquisición de información, la herramienta permitirá la recogida de datos:

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

o Cuantitativos: Puntuación sobre calificadores (al menos selección múltiple, checkboxes, lista desplegable, escala lineal, rejilla de selección múltiple, fecha, hora).

o Cualitativos: Mediante texto libre.

• La herramienta permitirá, a partir de las respuestas obtenidas, realizar un análisis avanzado de resultados, permitiendo presentar la información en gráficas de distintos formatos en función del resultado de las captaciones y de las encuestas.

• La herramienta permitirá la presentación de los resultados de la captación y de las encuestas a través de un panel de control o cuadro de mando. Esta presentación se realizará de forma numérica o gráfica pudiendo el usuario elegir entre distintos tipos de presentaciones.

• La herramienta permitirá la posibilidad de generar informes de resultados de las captaciones y encuestas ejecutadas.

• La herramienta realizará una evaluación automática mediante fórmulas de las respuestas cuantitativas de los encuestados.

• Deberá seguir las especificaciones relativas a usabilidad, accesibilidad y licenciamiento especificadas en el apartado 2.3 Requisitos de Software del presente Pliego.

• El diseño de las captaciones y encuestas generadas deberá ser responsive, de forma que sean visualizables en los diferentes tipos de dispositivos y se adapten al tamaño y formato de estos dispositivos sin requerir de la instalación de ningún software adicional.

• La herramienta permitirá la exportación de datos en diferentes formatos (CSV, XLS, HTML, XML y PDF), incluyendo la exportación de datos por medio de API para la integración en la Plataforma de Ciudad Inteligente.

• En caso de ser necesario, la herramienta incluirá mecanismos para el control del

Spam.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• El adjudicatario deberá instalar la herramienta en el hardware existente en el Ayuntamiento xx Xxxxxxx de San Xxxx a la finalización del presente proyecto, garantizando su funcionamiento y compatibilidad.

3.3.3. ACTUACIONES A REALIZAR

Esta implantación se realizará en los dos entornos municipales: el entorno de producción para el Panel de Captación de Datos Turísticos se ubicará en la nueva infraestructura suministrada en el presente contrato; el entorno de preproducción se ubicará en el servidor dedicado definido en el apartado 1.2.4.

En concreto, será necesario realizar como mínimo las siguientes actuaciones:

• Toma de requisitos, análisis y presentación de una propuesta tecnológica para la implementación del Panel de Captación de Datos Turísticos del Ayuntamiento xx Xxxxxxx de San Xxxx. Asimismo, incluirá el plan de pruebas necesario para validar la correcta implementación de las funcionalidades solicitadas.

• Implementación y publicación del Panel de Captación de Datos Turísticos. Una vez validada la propuesta tecnológica, el adjudicatario será el responsable de todos los trabajos necesarios para la implementación, configuración, parametrización y puesta en producción de la solución propuesta.

• Integración con la Plataforma de Ciudad Inteligente mediante realización de API Rest en el Panel de Captación de Datos Turísticos y desarrollo de vertical de Turismo (incluyendo panel del cuadro de mando e informes) en la Plataforma de Ciudad Inteligente.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Impartición de la capacitación asociada al componente.

3.3.4. INTEGRACIONES

El Panel de Captación de Datos Turísticos deberá integrarse con la Plataforma Web de Difusión Turística y la App Turística Móvil. Además, se integrará con la Plataforma de Ciudad Inteligente mediante la realización de una API Rest que permita por parte de la Plataforma descargar la información del Panel.

Los formularios de captación de datos y las encuestas deberán visualizarse correctamente en diferentes tipos de dispositivos, adaptándose a su tamaño y formato, sin requerir la instalación de ningún software adicional.

3.3.5. ENTREGABLES

El adjudicatario deberá generar los siguientes entregables:

Respecto a la implantación (suministro, instalación, pruebas y capacitación) del software, el adjudicatario deberá generar al menos los entregables especificados en el apartado 6.1 Entregables.

4. REQUISITOS DE IMPLANTACIÓN

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

La implantación consiste en la realización de todos los trabajos indicados en cada uno de los componentes descritos en el presente Xxxxxx, incluyendo la realización de las pruebas necesarias para asegurar su correcta ejecución, la capacitación en aquellos que hubiera sido requerida, así como las prestaciones y entrega de la documentación asociada.

El adjudicatario deberá disponer de todas las herramientas, aparatos, equipos de medida y otros materiales, así como del personal técnico adecuado con la preparación y experiencia necesarias para llevar a cabo todas las tareas requeridas para la ejecución del contrato.

4.1. PLANIFICACIÓN Y SEGUIMIENTO

4.1.1. INTERLOCUCIÓN Y SEGUIMIENTO DEL PROYECTO

El adjudicatario designará un Jefe de Proyecto, como interlocutor principal con el Ayuntamiento xx Xxxxxxx de San Xxxx durante la ejecución de las actuaciones.

El Jefe de Proyecto junto con su equipo realizará un seguimiento continuo de la evolución del proyecto y asistirá junto con los técnicos que se estime conveniente a las reuniones de seguimiento y revisiones técnicas que convoque el Ayuntamiento xx Xxxxxxx de San Xxxx, con la periodicidad que designe, para llevar a cabo tareas de seguimiento, coordinación y dirección del proyecto.

El Ayuntamiento xx Xxxxxxx de San Xxxx se reserva el derecho a solicitar el cambio de interlocutor en cualquier momento de la ejecución del proyecto, siendo responsabilidad del adjudicatario la presentación de un sustituto en un plazo no superior a una semana. Si durante la ejecución del contrato, la empresa adjudicataria propusiera el cambio del Jefe de Proyecto, esta circunstancia ha de ser comunicada al Ayuntamiento xx Xxxxxxx de San Xxxx con una antelación de 15 días.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Adicionalmente, se celebrará una reunión entre el equipo de trabajo del Ayuntamiento xx Xxxxxxx de San Xxxx y el adjudicatario con periodicidad mensual, en la que se repasará el estado de las actuaciones y se formalizarán los acuerdos y decisiones tomadas en el transcurso del mes anterior, incluyendo las desviaciones con respecto a la planificación de las entregas e instalación de los diferentes elementos.

4.1.2. METODOLOGÍA DE PROYECTO

El adjudicatario deberá adecuar su actuación en todo momento a la metodología de gestión de proyectos que determine el Ayuntamiento xx Xxxxxxx de San Xxxx. El adjudicatario se compromete a generar toda la documentación que el Ayuntamiento xx Xxxxxxx de San Xxxx solicite para el seguimiento de los trabajos realizados, de acuerdo con los criterios que establezca en cada caso.

Al comienzo de los trabajos, en la reunión de lanzamiento del proyecto, el adjudicatario presentará una propuesta completa de gestión del proyecto, que incluya al menos: mecanismos de gestión y coordinación, planificación (plan de proyecto), plazos, hitos intermedios, dependencias de actuaciones, mecanismos de control y de aseguramiento de la calidad, evaluación de riesgos y propuesta de mitigación, recursos humanos destinados a la gestión del proyecto, roles y responsabilidades. Esta propuesta deberá ajustarse a las condiciones y requisitos de obligado cumplimiento que marca el presente Xxxxxx.

4.1.3. OBLIGACIÓN DE INFORMACIÓN Y DOCUMENTACIÓN

Durante la ejecución de los trabajos objeto del Contrato, el adjudicatario se compromete en todo momento a facilitar a los responsables designados por el Ayuntamiento xx Xxxxxxx de San Xxxx la información y documentación que éstos soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizados para resolverlos.

Adicionalmente, como parte de las tareas objeto del Contrato, el adjudicatario generará la documentación de los trabajos realizados, según lo especificado en el apartado 6.1 Entregables.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario aportará en castellano aquella documentación elaborada expresamente para el proyecto. El resto de documentación se podrá aportar en castellano o en inglés.

El adjudicatario redactará las actas de las reuniones de seguimiento del proyecto mantenidas con el Ayuntamiento xx Xxxxxxx de San Xxxx en relación con la ejecución del proyecto.

La documentación no contendrá ningún tipo de rectificación o tachón, siendo esto motivo suficiente para su devolución y no contabilizando como entregada hasta que no se reciba la documentación correcta. La documentación no podrá ser elaborada a mano, con la única excepción de los datos que deban ser recabados en el momento de entrega del equipamiento (datos del firmante del documento, etc.).

El adjudicatario proporcionará la documentación acreditativa de la solicitud y obtención de permisos cuando éstos hayan sido necesarios para las instalaciones.

El adjudicatario entregará antes de la finalización del proyecto:

• Una memoria/dossier del proyecto, que recoja de forma detallada las actuaciones efectuadas y la solución implantada, detallada para cada uno de los componentes.

• Una presentación ejecutiva que, recogiendo información equivalente a la de la memoria/dossier del proyecto, se pueda utilizar a efectos divulgativos y de comunicación.

Si el Ayuntamiento xx Xxxxxxx de San Xxxx lo considera oportuno, el adjudicatario entregará antes de la finalización del proyecto un dispositivo de almacenamiento (tipo memoria USB o equivalente) con la recopilación de los entregables, actas, diseños, código fuente de desarrollos y cualquier otra información generada en el marco del proyecto.

4.2. SUMINISTRO

4.2.1. GENERALES

Como parte de cualquier suministro requerido como parte de los trabajos solicitados en el presente Xxxxxx o lo adicionalmente ofertado, el adjudicatario deberá:

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Cumplir los requisitos mínimos aplicables al suministro indicados en el apartado Elementos Software que se desarrolla a continuación.

• Cumplimentar un Acta de Suministro que deberá acompañar al hardware y/o productos software suministrados en el momento de la entrega, para su verificación y posterior firma por parte de la persona designada a tal efecto.

• El suministro incluye todo el hardware, software, accesorios, licencias y materiales que sean necesarios para la implantación de los elementos suministrados y la solución propuesta por el adjudicatario, así como para su utilización y corrección de incidencias.

4.2.2. ELEMENTOS SOFTWARE

El adjudicatario deberá proporcionar cada producto software requerido y/u ofertado a través de aquellos medios físicos o mecanismos que, a criterio del Ayuntamiento xx Xxxxxxx de San Xxxx, mejor se adecúen a las características del software a suministrar y sus modos de distribución. En caso de existir varias alternativas de suministro, el adjudicatario podrá plantear las mismas al Ayuntamiento xx Xxxxxxx de San Xxxx que determinará la finalmente aceptada.

El adjudicatario deberá proporcionar toda la documentación asociada a cada producto

software suministrado, según lo indicado en el apartado 6.1 Entregables.

4.2.3. ELEMENTOS HARDWARE

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario será el responsable de realizar el suministro y entrega de los equipos en la ubicación o ubicaciones finales que el Ayuntamiento xx Xxxxxxx de San Xxxx designe, conforme a los plazos que hubieran sido establecidos para dichos trabajos en el apartado 8. Plazos.

El embalaje de los elementos suministrados deberá cumplir los siguientes requisitos:

• Posibilitará una perfecta protección durante todo el proceso de transporte y almacenaje del material.

• Deberán inmovilizarse interiormente aquellos bultos en los que puedan producirse desplazamientos interiores de los elementos.

• Deberá minimizarse el volumen y peso de los bultos resultantes. En cuanto la forma, se tendrá en cuenta la facilidad de apilamiento.

• El adjudicatario llevará a cabo el desembalaje de los equipos y elementos de la solución técnica, retirará los embalajes y demás materiales de desecho tras la instalación, y realizará su tratamiento correspondiente como residuos.

• Todo el material del embalaje deberá ser depositado en un punto destinado a tal efecto, bien sea del propio centro destinatario o no.

4.3. INSTALACIÓN

4.3.1. GENERALES

Como parte de cualquier servicio de instalación requerido dentro de los trabajos solicitados en el presente Pliego o lo adicionalmente ofertado, el adjudicatario:

• Antes del inicio de cualquier instalación, el adjudicatario elaborará un documento de instalación y configuración que deberá ser aprobado por el Ayuntamiento xx Xxxxxxx de San Xxxx. En dicho documento deberá garantizarse que los servicios que se estuvieran prestando actualmente y pudieran verse afectados como

consecuencia de los trabajos de instalación a acometer, no queden sin cubrir en ningún momento, salvo los periodos de paradas programadas que se establezcan de acuerdo con el Ayuntamiento xx Xxxxxxx de San Xxxx.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• El adjudicatario cumplirá con los requisitos mínimos aplicables a los servicios de instalación indicados en el presente Pliego.

• El adjudicatario cumplimentará correctamente el Acta de Instalación asociada a cada uno de los trabajos que habrá de entregar para su verificación y posterior firma por parte del responsable autorizado en el beneficiario y del propio adjudicatario.

4.3.2. ELEMENTOS SOFTWARE

El adjudicatario garantizará el correcto funcionamiento de las soluciones software que se instalen. Las funcionalidades solicitadas en los diferentes componentes objeto de la licitación y que se describen en este Pliego, deberán estar operativas en el momento de la entrega debiéndose comprobar por el adjudicatario su correcto funcionamiento.

El adjudicatario tendrá un entorno de desarrollo propio, y un entorno de integración, donde se realizarán todas las pruebas de las soluciones a implantar previo a la instalación en el entorno final de explotación. Asimismo, se deberá verificar el correcto resultado de, al menos, las siguientes pruebas en el entorno de pre-producción, antes de la instalación en el entorno final de explotación: pruebas de funcionamiento del software (de carga y estrés, de rendimiento, de navegación, de regresión, de comportamiento, etc.) y pruebas de funcionamiento de los sistemas de interoperabilidad entre los diferentes componentes.

Las subidas a producción se realizarán en el horario que el Ayuntamiento xx Xxxxxxx de San Xxxx estime que menos impacto causa al entorno del proyecto.

Cualquier solución software requerirá de una fase de diseño y prototipado por parte del adjudicatario previo a su desarrollo definitivo. La estructura y organización de los contenidos se definirá durante la ejecución, siendo el diseño final consensuado entre el adjudicatario y la Dirección Técnica del proyecto designada a tal efecto por el Ayuntamiento xx Xxxxxxx de San Xxxx.

El adjudicatario entregará una guía de estilos y diseño de las soluciones software (web, aplicaciones móviles, etc.) para su validación por parte del Ayuntamiento xx Xxxxxxx de San Xxxx y posterior aplicación en los desarrollos. Esta guía de estilos y diseño deberá seguir la identidad visual del Ayuntamiento xx Xxxxxxx de San Xxxx, la cual será entregada al adjudicatario al inicio de los trabajos.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario garantizará en todo momento la calidad de los productos implantados y desarrollados y su correcta entrega para la puesta en servicio en el entorno de producción del Ayuntamiento xx Xxxxxxx de San Xxxx. Para asegurar la calidad de los productos desarrollados, el Ayuntamiento xx Xxxxxxx de San Xxxx se reserva el derecho a realizar un proceso de certificación de los productos entregados. En el caso de que en dicho proceso se detectasen incidencias, el adjudicatario deberá asumir la resolución de las mismas, sin que esto suponga una modificación a los plazos descritos en este Pliego.

El adjudicatario llevará a cabo la instalación física y configuración del software sobre la infraestructura, sistemas y entornos correspondientes.

El adjudicatario realizará la actualización y entrega de la documentación de los elementos instalados, según lo indicado en el apartado 6.1 Entregables.

Adicionalmente aquellas tareas que se consideren necesarias para que los diferentes elementos queden plenamente operativos y en funcionamiento.

4.3.3. ELEMENTOS HARDWARE

El transporte desde el lugar de suministro a lugar de la instalación correrá a cargo del adjudicatario.

El adjudicatario realizará el desembalaje, ensamblado de todos los componentes internos, anclaje, si procede, en el armario y/o el chasis suministrado/existente y entrega de los elementos auxiliares que corresponda para su puesta en servicio (soportes del software de base, licencias, etc.). El adjudicatario llevará a cabo la retirada del embalaje y material sobrante del lugar de la instalación.

El adjudicatario realizará el conexionado, instalación, actualización de firmware, configuración e integración de todos los elementos entregados con la infraestructura existente.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Los elementos de conexionado (cables de pares, fibra u otros equivalentes) serán suministrados por el adjudicatario en número suficiente para cumplir con los requisitos del presente Pliego.

El adjudicatario realizará la instalación física y configuración del conjunto hardware en cada ubicación especificada incluyendo, si así se requiere, su enracado y conexionado a las diferentes redes.

Previa solicitud y coordinadamente con el responsable del lugar donde se instalen los equipos, el adjudicatario comprobará el encendido de los equipos.

El adjudicatario realizará pruebas de verificación de la instalación y montajes efectuados. El protocolo de pruebas debe incluir, además de aquellos otros aspectos que proponga el licitador, los siguientes:

• Correcto encendido y apagado de los equipos.

• Verificación de las funcionalidades y características requeridas así como de las ofertadas adicionalmente.

Salvo indicación expresa del Ayuntamiento xx Xxxxxxx de San Xxxx, el cableado se instalará canalizado, cumpliendo los siguientes requisitos:

• El adjudicatario proporcionará las canalizaciones, pasamuros, caja y demás elementos necesarios para las rutas de cableado para la conexión de todos los elementos de los componentes.

• Las canalizaciones se realizarán con cualquiera de los medios permitidos en la normativa y reglamentos aplicables (bandeja, canaleta, etc.), acordes en todo caso a la estética y las soluciones existentes en la ubicación, de tamaños adecuados al volumen de cables que deben albergar más un espacio libre de al menos el 30%

de la sección del elemento de canalización. Las transiciones entre distintos tipos de canalización se realizarán en cajas de registro y/o derivación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Si existiese en la ubicación canalización ya instalada con espacio libre suficiente para albergar dicho cableado, se podrá hacer uso de la misma bajo autorización del Ayuntamiento xx Xxxxxxx de San Xxxx. En este caso el adjudicatario garantizará la inexistencia de interferencias entre los cableados, tanto para los ya existentes como los de nueva instalación. En los casos en los que se encuentre disponible un acceso para operadores propiedad del edificio, consistente en una canalización o acometida desde la vía pública al RITI o cuarto de comunicaciones de la sede, se utilizará esta canalización o acometida si el último tramo del servicio de conectividad de acceso desde la vía pública hasta el edificio es cableado.

• Los materiales empleados en la ejecución del proyecto deberán ser conformes con las especificaciones técnicas incluidas en el Reglamento regulador de las infraestructuras comunes de telecomunicaciones, y con el resto de las normas en vigor que les sean de aplicación, especialmente las contenidas en el Código Técnico de la Edificación en materia de seguridad contra incendios y de resistencia frente al fuego. En particular, los tubos serán conformes a lo establecido en la parte correspondiente de la norma UNE EN 50086 (o equivalente) o UNE EN 61386 (o equivalente) y las canales serán conformes a lo establecido en la serie de normas UNE EN 50085 (o equivalente), y sus características mínimas serán las especificadas en ambos casos en el citado reglamento. En el caso de los tubos y canales serán además libres de halógenos.

Adicionalmente, el adjudicatario realizará aquellas tareas que sean necesarias para que los diferentes elementos queden plenamente operativos y en funcionamiento.

4.4. PRUEBAS

Para la realización de las pruebas necesarias para asegurar la correcta ejecución de los trabajos del presente Xxxxxx o lo adicionalmente ofertado, el adjudicatario deberá:

• Elaborar un plan de pruebas específico que permita verificar el cumplimiento de los requisitos solicitados y ofertados para cada Componente (total o parcial) a probar. Dicho plan deberá ser aprobado por el Ayuntamiento xx Xxxxxxx de San Xxxx con carácter previo al inicio de estas.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• El plan de pruebas deberá permitir la verificación del correcto funcionamiento e integración de todos los elementos (hardware, conectividad, productos software y/o desarrollos software, etc.) objeto de prueba, tanto desde el punto de vista individual, como desde el punto de vista de integración de la solución. La propuesta incluirá un conjunto de casos de prueba relativos a, como mínimo, pruebas funcionales, de diseño, carga, rendimiento, seguridad, e integración. Cada uno de los casos de prueba contendrá al menos los siguientes apartados:

o El objeto del caso (elemento, parámetro o funcionalidad a comprobar).

o Las condiciones previas.

o La descripción detallada de los pasos para realizar la prueba.

o El resultado esperado del caso.

o El resultado obtenido del caso.

• Tras la ejecución de las pruebas, el adjudicatario entregará un Informe de Resultados de las Pruebas en el que se especifiquen los resultados de las pruebas realizadas, con una estructura acorde al plan de pruebas acordado. Las pruebas podrán darse por finalizadas una vez evidencien la ejecución exitosa de las mismas.

• El Ayuntamiento xx Xxxxxxx de San Xxxx se reserva el derecho de no ejecutar alguna de las pruebas incluidas en el plan de pruebas cuando las condiciones de ejecución de estas lo desaconsejen, y podrá solicitar al adjudicatario la inclusión de pruebas adicionales en el plan de pruebas con la antelación suficiente.

• Para la realización de las pruebas el adjudicatario deberá utilizar equipamiento de medición y personal propio sin que ello pueda representar coste adicional alguno para el proyecto.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

• Las pruebas se realizarán en coordinación con el Ayuntamiento xx Xxxxxxx de San Xxxx y en los horarios que éste permita para minimizar el posible impacto de estas en su operativa, así como en los servicios que presta. El plan de pruebas deberá prever y garantizar que los servicios que se están prestando actualmente no se vean afectados por el desarrollo de las pruebas, salvo, si fuese imprescindible, en aquellos periodos que se establezcan de acuerdo con el Ayuntamiento xx Xxxxxxx de San Xxxx.

4.5. GESTIÓN DEL CAMBIO, CAPACITACIÓN Y PLAN DE SOSTENIBILIDAD DEL PROYECTO

4.5.1. GESTIÓN DEL CAMBIO

El adjudicatario deberá desarrollar de forma específica acciones concretas para la gestión del cambio asociadas al suministro, que se incluirán en la estrategia de gestión del cambio que se debe desarrollar para la iniciativa con el objeto de que los técnicos del Ayuntamiento xx Xxxxxxx de San Xxxx encargados de definir las campañas y los mensajes conozcan la ubicación y posibilidades de la solución implantada. Estas actuaciones de gestión del cambio acompañarán a las actuaciones de capacitación e incluirá a los departamentos implicados que utilicen los distintos componentes. Será necesario desarrollar un continuo proceso de gestión del cambio a medida que se van desarrollando las diferentes actuaciones. El desarrollo de la iniciativa debe entenderse como una oportunidad para innovar en todos los aspectos de la gestión del Ayuntamiento xx Xxxxxxx de San Xxxx.

4.5.2. CAPACITACIÓN

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El adjudicatario deberá impartir al menos dos sesiones de capacitación para el perfil de usuario/técnico de operación y una sesión para el perfil de administrador para cada componente, salvo que el Ayuntamiento xx Xxxxxxx de San Xxxx determine expresamente que no es preciso para componentes concretos. La capacitación deberá cubrir la utilización, administración y mantenimiento del componente. La duración mínima de la capacitación para cada uno de los componentes y para cada tipo de perfil será al menos de 5 horas. La duración y número de sesiones de capacitación debe entenderse como un mínimo, siendo el adjudicatario el que deberá proponer el plan de capacitación más adecuado para conseguir el mayor grado de independencia de los técnicos del Ayuntamiento xx Xxxxxxx de San Xxxx en la gestión y uso de las soluciones implantadas para los diferentes perfiles implicados, correspondiendo al Ayuntamiento xx Xxxxxxx de San Xxxx la validación de la propuesta. En caso de existir necesidades específicas de capacitación en algunos componentes, se describirá en el apartado correspondiente.

La capacitación deberá garantizar que los usuarios administradores puedan realizar todas las tareas de administración, gestión y explotación de los diferentes sistemas instalados de modo que sean autónomos en el uso, configuración y mantenimiento. De igual forma, los perfiles usuarios deberán adquirir las competencias suficientes para la utilización de las herramientas implantadas.

La capacitación de cada componente será presencial, en dependencias del Ayuntamiento xx Xxxxxxx de San Xxxx, dimensionada para un máximo de 10 alumnos. No obstante y a petición del Ayuntamiento xx Xxxxxxx de San Xxxx, podrán realizarse en las instalaciones del adjudicatario. En el caso de que se realicen en las instalaciones del Ayuntamiento xx Xxxxxxx de San Xxxx, será éste el que proporcione las aulas y equipamiento necesario para la impartición de la capacitación (ordenadores, proyector y/o pizarra digital, etc.). El adjudicatario deberá realizar las tareas de coordinación y soporte que correspondan con el Ayuntamiento xx Xxxxxxx de San Xxxx y que permitan garantizar la correcta configuración de los equipos a utilizar en las sesiones de capacitación.

El personal asistente a la capacitación será designado por el Ayuntamiento xx Xxxxxxx de San Xxxx.

Los contenidos del curso serán entregados previamente por el adjudicatario al Ayuntamiento xx Xxxxxxx de San Xxxx en formato electrónico para su validación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Los horarios y fechas de impartición de cada acción de capacitación solicitada serán determinados por el Ayuntamiento xx Xxxxxxx de San Xxxx, dentro del periodo de la vigencia del contrato. El horario de capacitación se adaptará a las necesidades del Ayuntamiento xx Xxxxxxx de San Xxxx y se planificará en el tiempo de manera que coincida, preferiblemente, con el periodo inmediatamente anterior o posterior a la puesta en marcha de cada uno de los componentes.

La capacitación deberá ser impartida en castellano.

La capacitación deberá tener en cuenta el nivel de conocimiento previo de los usuarios, desarrollando capacitación específica y documentación adecuada y adaptada a los asistentes.

El adjudicatario elaborará la documentación necesaria para el desarrollo de la capacitación de cada componente (plan de capacitación, documentación para los asistentes, acta de capacitación y cuestionario de evaluación), según lo indicado en el apartado 6.1 Entregables.

4.6. INVENTARIO DE ELEMENTOS

Es responsabilidad del adjudicatario proporcionar la información de inventario necesaria para el correcto seguimiento de todos los activos, identificando los elementos hardware y software, tanto durante el suministro e instalación como durante la garantía, incluyendo números de serie, marcas y modelos, fechas y lugares de suministro e instalación, identificación de albaranes o actas de recepción y otros datos que especifique el Ayuntamiento xx Xxxxxxx de San Xxxx asociados a la entrega y aceptación.

La información de activos se considera parte de la entrega de los mismos, y es necesaria para su aceptación.

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

El soporte y formato de dicha información será especificado por el Ayuntamiento xx Xxxxxxx de San Xxxx para todos los activos y sus elementos, tanto hardware como software.

5. REQUISITOS DE EJECUCIÓN

5.1. SUSTITUCIÓN Y AUSENCIA DE MEDIOS PERSONALES

Documento firmado electrónicamente con CSV: 14164364022232421155 verificable en xxxxx://xxxx.xxxxxxxxxxxxxxxx.xx/xxxxxx/xxxx

Tanto el Ayuntamiento xx Xxxxxxx de San Xxxx como el adjudicatario podrán requerir la sustitución de los medios personales por otros de igual categoría durante la ejecución del proyecto.

Si durante la ejecución del contrato, la empresa adjudicataria propusiera el cambio de alguno de los medios personales, la sustitución requerirá, en todo caso, el cumplimiento de las siguientes condiciones:

• Aviso o solicitud del cambio realizado con antelación de 15 días naturales.

• Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.

• Presentación de posibles candidatos con un perfil acorde al medio personal que se pretende sustituir.

• Aceptación del candidato por parte del Ayuntamiento xx Xxxxxxx de San Xxxx, una vez verificado el cumplimiento de los requisitos solicitados en el presente Pliego de Prescripciones Técnicas.

Tanto si la solicitud de sustitución de medios personales procede del Ayuntamiento xx Xxxxxxx de San Xxxx como del adjudicatario, este último deberá prever y establecer las medidas adecuadas para que no se produzca interrupción en la ejecución del proyecto. En concreto, el adjudicatario se encargará de que los medios personales entrantes y salientes cuenten con un periodo de solapamiento, dirigido a realizar el traspaso de conocimiento de uno a otro, sin que tenga una consideración especial a efectos de cómputo de horas.

De conformidad con lo establecido en el artículo 76.2 de la Ley 9/2017, de 8 de noviembre, de Contratos del Sector Público, los licitadores se comprometerán a dedicar o

Document Metadata

Table of Contents

contrato mixto (Servicios- Suministro) de “PLATAFORMA WEB DE DIFUSIÓN TURÍSTICA, APLICACIÓN MÓVIL TURISMO DE ALCÁZAR Y PANEL DE CAPTACIÓN DE DATOS TURÍSTICOS”

Document Metadata